Serwer domowy z Proxmox VE (wirtualizacja) cz. 2

Jest to kontynuacja poprzedniego wpisu na temat tworzenia serwera domowego z Proxmoxem od zera (Serwer domowy z Proxmox (wirtualizacja) cz. 1). Tematem tego wpisu jest instalacja Proxmoxa i jego konfiguracja, a także przykładowo opiszę jak utworzyć wirtualną maszynę. Opisałem tutaj właściwie tylko podstawy tworzenia wirtualnych maszyn bez zagłębiania się w większe szczegóły obsługi i możliwości Proxmoxa, a te są naprawdę duże i warto się tym zainteresować. Nie opisałem tutaj tworzenia kontenerów, ale jak zajdzie taka potrzeba to mogę to zrobić (natomiast raczej jeżeli ktoś się interesuje kontenerami w Proxmoxie to znajdzie wiele informacji na ten temat w Google. Samo tworzenie kontenerów nie jest jakoś mocno skomplikowane). Zapraszam do lektury.

Spis treści:
1. Instalacja Proxmox
2. Utworzenie wirtualnej maszyny
3. Podsumowanie

 


1. Instalacja Proxmox VE
Logujemy się na serwer (z uprawnieniami root) i edytujemy plik /etc/hosts. Wprowadzamy tutaj własną nazwę hosta. Czyli wydajemy komendę:

nano /etc/hosts

Jak plik powinien wyglądać:

127.0.0.1       localhost.localdomain localhost
192.168.0.10    nazwa_hosta.nazwadomeny.com nazwa_hosta pvelocalhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Czyli przykładowo zamiast nazwa_hosta.nazwadomeny.com wprowadzamy swoje dane (nazwa domeny może być wymyślona jeżeli takiej nie posiadamy). Dla przykładu zastosowałem nazwę srvproxmox żeby było wiadomo o co chodzi. Nie testowałem czy Proxmox prawidłowo działa bez podania nazwy hosta z domeną. Teoretycznie powinien.

127.0.0.1 localhost.localdomain localhost
192.168.0.10 srvproxmox.wiblo.pl srvproxmox pvelocalhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

127.0.0.1 localhost.localdomain localhost – to lokalna adresacja loopback
192.168.0.10 srvproxmox.wiblo.pl srvproxmox pvelocalhost – to adres IP naszego serwera i nazwa hosta w domenie (możemy wpisać cokolwiek wymyślonego np. mojserwer.mojserwer.pl) oraz sama nazwa hosta. Są to nazwy, które użyte bezpośrednio na serwerze będą kierować na adres IP serwera. Nazwa pvelocalhost czyli ostatnia wynika z dokumentacji Proxmox.

Jeżeli mamy już ustawione co trzeba to zapisujemy konfigurację i testujemy

hostname --ip-address

Powinniśmy dostać wynik z adresem IP naszego serwera.

Teraz czas na instalację Proxmoxa. Najpierw musimy dodać repozytorium czyli

echo "deb http://download.proxmox.com/debian/pve stretch pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list

Następnie dodajemy klucz repozytorium Proxmoxa

wget http://download.proxmox.com/debian/proxmox-ve-release-5.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg

Kolejny krok to aktualizacja systemu

apt-get update && apt-get dist-upgrade -y

Gdy już wszystko skończy się wykonywać przechodzimy do instalacji pakietów Proxmoxa.

apt-get install proxmox-ve postfix open-iscsi -y

W trakcie instalacji zostaniemy zapytani o konfigurację Postfixa. Najlepiej wybrać opcję local only.

Kolejne okienko, które się pojawi będzie SMTP Relay. Tutaj powinno być już domyślnie wpisane to co w hosts czyli wg. przykładu srvproxmox.wiblo.pl (nazwa domenowa naszego serwera). Jeżeli tak nie będzie to wpisujemy taką nazwę sami.

Jak tylko instalacja zostanie zakończona restartujemy system (uruchamiamy ponownie). Czyli polecenie

reboot

Gdy już serwer się uruchomi ponownie to zalecane jest odinstalowanie os-probera. Os-prober służy do konfiguracji dual-boot. Tutaj nie jest to nam potrzebne i nie używamy innych systemów równolegle na jednym dysku więc usuwamy to:

apt-get remove os-prober -y

Kiedy to wszystko już wykonamy przechodzimy do panelu Proxmox VE. Uruchamiamy przeglądarkę i wpisujemy w pasku adresu (uwaga stosujemy HTTPS):

https://adres_ip_serwera:8006

Czyli zgodnie z tym przykładem

https://192.168.0.10:8006

Akceptujemy certyfikat (przeglądarka wyświetli ostrzeżenie ponieważ certyfikat jest self-signed) i pojawia się ekran logowania. Wpisujemy login root i hasło użytkownika root takie jakie mamy w systemie (logowanie jest przy użyciu użytkownika systemowego).

Pojawi się komunikat, że nie mamy płatnej subskrypcji (komunikat można wyłączyć w plikach Proxmox. Proxmox jest darmowy i nie wymaga płatnej subskrypcji aby z niego korzystać). Subskrypcja płatna nie jest nam potrzebna ponieważ nie będziemy korzystać ze wsparcia technicznego twórców Proxmoxa. Czyli klikamy OK.

Na moim przykładzie w panelu Proxmox serwer (node) nazywa się Beos. Każdy tutaj zobaczy własną nazwę noda jaką ustawił wcześniej.

Musimy ustawić mostek dla Proxmoxa, którego będą używać wirtualne maszyny. Klikamy na nazwę naszego serwera i wybieramy z opcji system -> network. Zobaczymy listę kart sieciowych.

Edytujemy naszą kartę sieciową (zaznaczamy i klikamy edit) i usuwamy wszystko co jest w niej zapisane tak aby były puste pola

Następnie wybieramy Create -> Linux Bridge

Uzupełniamy dane w okienku. Nazwa mostka to vmbr0, podajemy adres IP naszego serwera, maskę, adres bramy (routera z internetem) oraz nazwę karty sieciowej, która ma być przypisana do mostka (z widocznej listy kart sieciowych w tym przypadku jest to enp2s0). Klikamy Create.

Po tym zabiegu restartujemy serwer czyli klikamy przycisk Reboot, a następnie potwierdzamy przyciskiem Yes.

Gdy serwer się uruchomi to ponownie wchodzimy do panelu Proxmox, wybieramy naszego noda (serwer), następnie rozwijamy system (domyślnie tak sekcja powinna być rozwinięta) i przechodzimy do network. Przy mostku, który został utworzony w kolumnie Active powinno być Yes. Czyli widok jak poniżej.

 


2. Utworzenie wirtualnej maszyny
Zanim utworzymy wirtualną maszynę wypadałoby wgrać obraz płyty z system, który będziemy instalować. Powiedzmy, że potrzebujemy wirtualnej maszyny z Debianem. Trzeba z jakiegoś obrazu płyty (ISO) ten system zainstalować. Klikamy 2x lewym przyciskiem myszy na nazwie naszego serwera lub klikamy na znaczek strzałkę/znaczek > przy naszym serwerze. Pod nodem powinno się pojawić coś takiego jak “local” (nazwa serwera). Jest to domyślny magazyn na którym są przechowywane pliki ISO, wirtualne dyski itd. Wybieramy local i przechodzimy do sekcji “Content”

Jak widać mamy tutaj przycisk “Template” oraz “Upload”. “Template” pozwala nam ściągnąć szablony systemów, które można wykorzystać przy tworzeniu kontenerów (parawirtualizacja). Tego tutaj nie opisałem więc zachęcam do zgłębienia wiedzy na temat Proxmoxa i tworzenie kontenerów (nie jest to trudne, ale jak zajdzie taka potrzeba to mogę opisać jak stworzyć kontener). Klikamy na przycisk upload. Pojawi się okienko, w którym domyślnie będzie ustawione Content na ISO image. Teraz klikamy Select file i wybieramy plik ISO z naszego lokalnego komputera z instalacją systemu (u mnie to jest obraz Debiana netinst, ale jak ktoś ma i chce to może wgrać obraz płyty z instalacją Windows i utworzyć wirtualną maszynę z Windowsem). Jak to już zrobimy klikamy przycisk Upload.

Postęp ładowania obrazu na serwer:

Gdy plik zostanie już skopiowany na serwer to pojawi się na liście

W celu utworzenia wirtualnej maszyny klikamy przycisk “Create VM” (Create CT tworzy kontener), który jest widoczny w górnym pasku z prawej strony. Pojawi się okienko konfiguracji nowej maszyny. Domyślnie wybrany node to nasz serwer (mamy tutaj tylko jeden node więc nie ma wyboru). VM ID możemy zmieniać jakie chcemy od 100 w górę, ale Proxmox sam będzie ustawiać kolejne numery przy nowych maszynach więc nie musimy się tym przejmować. Name to nazwa naszej wirtualki (wyświetlana w panelu Proxmox w celu identyfikacji). W polu name wpisujemy co chcemy np. TestVM i klikamy przycisk Next.

Kolejne okno to wybór systemu oraz wskazanie nośnika z jakiego będzie wykonywana instalacja. Mamy do wyboru storage na serwerze, fizyczny napęd lub brak jakiegokolwiek nośnika. W tym przypadku używamy lokalny storage nazwany local, na którym jest obraz z instalacją systemu Debian. Wybieramy z listy ISO Image obraz, który wgraliśmy na serwer. Pole Type to w tym przypadku Linux. Jeżeli ktoś instaluje Windowsa to musi tutaj wybrać Windows. Version w tym przypadku to 4.X/3.X/2.6 Kernel. Jeżeli ktoś instaluje Windowsa to w Version będzie musiał wybrać wersję Windowsa (np. Windows 7), którą będzie instalować. Klikamy next i przechodzimy dalej

Kolejne okno to ustawienia dysku twardego. Tutaj ustawiamy Bus/Device najlepiej w tym przypadku na VirtIO Block (jak ktoś instaluje Windowsa to może z tym być różnie i lepszym wyjściem czasem będzie SCSI/IDE lub SATA ponieważ Windows może nie mieć sterowników do VirtIO i nie wykryje dysku. Jeżeli taka sytuacja się pojawi to po prostu trzeba będzie edytować wirtualną maszynę/dodać dysk wirtualny na innej szynie lub dograć sterowniki VirtIO jeżeli będą do danego Windowsa). Rozmiar dysku ustawiamy jaki chcemy. Należy brać pod uwagę dostępne miejsce na fizycznym dysku na serwerze żeby nie okazało się, że jak wirtualne maszyny zaczną wykorzystywać już swoje wirtualne dyski to zabraknie miejsca na serwerze, bo wtedy wszystko zacznie działać nie tak jak powinno. Teoretycznie z góry określamy, że dany system i usługi powinny się np. zmieścić na 128GB, że np. Windows z usługami 128GB itd. Zawsze też możemy później dodawać kolejne dyski do już istniejących wirtualnych maszyn (takim sposobem jedna wirtualna maszyna może mieć kilka wirtualnych dysków). Cache nie będziemy ustawiać i używać. Czasem może to przyspieszyć działanie wirtualnej maszyny, a czasem może po prostu przysporzyć niepotrzebnych problemów. Jak już wszystko ustawimy to klikamy Next.

Następne okno to ustawienia CPU czyli procesora. Tutaj ustawiamy ile socketów przypisujemy do danej maszyny, ile rdzeni i jaki typ procesora ma być emulowany. Domyślnie jest to KVM64, ale już spotkałem się z przypadkami gdzie wirtualna maszyna działała poprawnie (mogła zainstalować system) dopiero z emulacją procesora ustawioną na type Core2Duo/IvyBridge czyli inny niż KVM64. Czyli jeżeli mamy problem z instalacją/bootowaniem livecd systemu pod wirtualną maszyną z powodu jakiegoś dziwnego błędu (lub braku błędu, ale “zawieszaniem się ładowania systemu” wewnątrz wirtualki) to możliwe, że chodzi właśnie o wybrany typ emulowanego procesora i należy go zmienić. Na poniższym przykładzie ustawiłem 1 socket (bo mam tylko jeden procesor) i 4 rdzenie (tyle rdzeni ma mój CPU, ale możemy przydzielić np. tylko 1 rdzeń). Przechodzimy dalej czyli klikamy Next.

Kolejny etap to ustawienia pamięci RAM. Możemy przypisać na sztywno ilość RAM lub wybrać opcję automatyczną. W sumie raczej wolę pierwszy typ czyli na sztywno przypisana ilość RAM do wybranej maszyny. Przechodzimy dalej czyli Next.

Następne okno to ustawienia sieci. Mamy do wyboru “Bridge mode”, “NAT mode” oraz “no network device”. W przypadku maszyn wirtualnych to w 99% przypadków będziemy używać Bridge mode (jaka jest między nimi różnica to odsyłam do Wiki Proxmoxa i Google, ale w skrócie NAT jest najprostszą możliwością dostępu z systemu wirtualnej maszyny do zewnętrznej sieci/internetu. Dostęp z zewnątrz do wirtualnej maszyny (usług na tej maszynie) nie jest możliwy, w trybie Bridge wirtualna maszyna otrzymuje bezpośredni dostęp do sieci, do której podłączony jest host i funkcjonuje/jest widoczna tak jak fizyczny komputer (mamy dostęp do usług wirtualnej maszyny czyli na serwer to właściwie tylko ta opcja)). Pole Bridge to vmbr0 czyli utworzony wcześniej mostek (powinien być wybrany domyślnie). Model karty to będzie domyślnie VirtIO. W przypadku kiedy ktoś instaluje Windowsa to możliwe, że będzie musiał doinstalować w systemie Windows sterowniki do karty VirtIO lub po prostu będzie musiał zmienić model karty na np. Intel E1000, bo może coś być nie tak z wydajnością emulowanej karty pod Windowsem. Klikamy przycisk Next.

Kolejne okno to podsumowanie tego co ustawiliśmy. Możemy ostatecznie zweryfikować czy wszystko jest tak jak chcemy. Jeżeli jest OK to klikamy Finish.

Po kliknięciu przycisku finish, host skonfiguruje i utworzy wirtualną maszynę, które po chwili powinna się pojawić na liście pod naszym nodem (serwerem). Będzie ona “szara” ze względu na to, że nie jest uruchomiona. Klikamy na naszą maszynę.

Żeby uruchomić taką maszynę należy na nią kliknąć i wybrać z górnego paska opcję “START”. Zanim to jednak zrobimy to zmienimy ustawienia autostartu tej maszyny. W końcu chcemy aby wirtualna maszyna była uruchamiana automatycznie po restarcie serwera (chyba, że ktoś za każdym razem chce sam klikać START to nie ma problemu). W tym celu wchodzimy w sekcję “Options” i klikamy “Start at boot”, a następnie przycisk Edit na pasku, który jest powyżej.

Zaznaczamy opcję Start at boot i klikamy OK. Opcja “Start at boot” zmieni się na “Yes”.

Jak widzimy na powyższych screenach mamy tutaj sporo opcji umożliwiających zmianę ustawień wybranej wirtualnej maszyny. Przykładowo w sekcji hardware mamy ustawienia na temat sprzętu tej konkretnej wirtualnej maszyny (dyski, CD/DVD/zamontowane ISO, kolejność boot itd.). Możemy tutaj modyfikować i zmieniać wszelkie opcje związane z wybraną maszyną (zmiana ustawień może wymagać zatrzymania wirtualnej maszyny i uruchomienia jej ponownie aby dane ustawienia zostały wdrożone).

Skoro już wszystko ustawiliśmy to pozostaje kliknąć przycisk Start czyli uruchomić wirtualną maszynę. Na dole w logu pojawi się informacja o tym co się dzieje. Jeżeli maszyna zostanie poprawnie uruchomiona to zobaczymy w kolumnie status danej maszyny napis OK.

Teraz musimy wiedzieć co się dzieje na tej maszynie, bo w końcu jakoś trzeba zainstalować system. Naszym “monitorem” jest okno VNC, które uruchamiamy klikając na przycisk “console”. Pojawi się okienko VNC, które pokaże wszystko co się dzieje na wirtualnej maszynie tak jakbyśmy mieli podpięty monitor bezpośrednio do komputera.

W tym momencie chyba już jest jasne jak tworzyć wirtualne maszyny i jak je konfigurować w Proxmoxie.
Po instalacji systemu w opcjach wirtualnej maszyny możemy “odmontować” podłączony obraz instalacyjny systemu. W tym celu przechodzimy do sekcji hardware, wybieramy CD/DVD Driver, a następnie przycisk edit lub 2x klikamy LPM na CD/DVD driver. W okienku ustawiamy “Do not use any media” i OK. Czasem żeby ustawienia weszły w życie trzeba będzie zatrzymać maszynę i wystartować ją ponownie. Jeżeli chcemy podłączyć do wirtualnej maszyny inny obraz płyty to wgrywamy obraz na serwer tak jak to zostało opisane wcześniej i wtedy w sekcji hardware, CD/DVD Driver wybieramy obraz, który chcemy aby był podmontowany wewnątrz naszej wirtualnej maszyny.

Jeżeli kogoś interesują backupu/snapshoty to musi tego szukać w wybranej maszynie wirtualnej w sekcji Backup. Dodatkowo jeżeli klikniemy na “Datacenter” i wejdziemy w opcję Backup to możemy ustawić cały harmonogram dla poszczególnych wirtualnych maszyn jeżeli chodzi o kopie zapasowe (kiedy mają się wykonywać, jak mają być pakowane itd). Możemy np. podłączyć dodatkowy dysk (lub nawet dysk USB) do serwera i wykorzystać go do przechowywania kopii zapasowych wirtualnych maszyn.
Wcześniej jednak należy w sekcji storage dodać odpowiednie katalogi/zasoby z odpowiednimi opcjami możemy np. edytować aktualny storage “local” i w content zaznaczyć VZDump backup file, żeby była możliwość przechowywania/tworzenia backupów na storage nazwanym “local” (inaczej przy konfiguracji backupu pole storage będzie puste i nie będzie co wybrać).


3. Podsumowanie
Przedstawiłem tutaj trochę wiedzy na temat Proxmoxa i w sumie opisałem ledwo podstawę tworzenia wirtualnych maszyn. Takie podstawy powinny wystarczyć na początek aby samodzielnie zacząć zgłębiać tajniki wirtualizacji, obsługi Proxmoxa itd. To czego tutaj nie opisałem to tworzenie kontenerów LXC, ale to chyba już każdy ogarnie we własnym zakresie. Skupiłem się tutaj głównie na pełnej wirtualizacji, a nie parawirtualizacji (kontenery).

Wirtualizacja/parawirtualizacja na pewno jest przydatna w wielu miejscach ponieważ pozwala zaoszczędzić czas (w przypadku awarii, migracji na nowy sprzęt itp.), pieniądze i posiadane zasoby w postaci sprzętu, bo jedna fizyczna maszyna zamiast być serwerem dla jakiejś jednej usługi, która nie wykorzystuje w całości zasobów maszyny może zostać wykorzystana do hostowania wirtualnych maszyn, które z kolei hostują wiele różnych usług co pozwala lepiej wykorzystać zasoby fizycznej maszyny, a także poprawić bezpieczeństwo i dostęp do konkretnych usług (jeżeli np. jakaś aktualizacja popsuje daną wirtualną maszynę/usługę to nadal działają pozostałe). Wirtualne maszyny/kontenery pozwalają także na praktycznie bezstresowe testowanie programów, ustawień itp. przed wdrożeniem czegoś na produkcję lub po prostu w celach edukacyjnych (tworzymy nową maszynę/kontener i bawimy się do woli, a jak coś popsujemy to przywracamy wirtualną maszynę z backupu do poprzedniego stanu i bawimy się dalej). Dodatkowo na pewno bardziej opłacalny jest zakup jednego lub dwóch fizycznych komputerów z odpowiednimi parametrami i uruchomienie na nich kilku wirtualnych maszyn/kontenerów na konkretne usługi niż zakup kilku/kilkunastu komputerów żeby rozdzielić usługi na konkretne fizyczne maszyny. Umożliwia to także stworzenie środowiska gdzie jeden host z wirtualnymi maszynami ma klona w postaci drugiej fizycznej maszyny i tylko replikują się wirtualne maszyny z jednego hosta na drugiego i w razie awarii sprzętowej po prostu ustawia się zapasową maszynę jako główną i wszystko nadal działa jak działało, a w międzyczasie można naprawić uszkodzony sprzęt bez stresu, że ktoś nie może pracować albo nie ma dostępu do danych usług, ale tutaj wchodzimy już w tematy wysokiej dostępności, load balancing, faileover.

Możliwości budowania środowisk pod wirtualizację jest naprawdę bardzo wiele tak jak jest bardzo wiele możliwości wykorzystania takich środowisk. Popularne teraz cloudy/chmury to przede wszystkim wirtualizacja/parawirtualizacja. Są środowiska gdzie rozdzielane są wszelkie usługi na mniejsze maszyny/kontenery, nowy webserwis to nowy kontener/wirtualna maszyna, nowa usługa to nowa maszyna itd. Wszystko ma swoje plusy i minusy i trzeba to brać pod uwagę, bo czasem może się zdarzyć, że wpychanie wszędzie na siłę wirtualizacji może powodować pewne problemy (chociażby w momencie kiedy jakaś aplikacja potrzebuje bezpośredniego dostępu do jakiegoś fizycznego sprzętu/zasobu).

Mam nadzieję, że komuś się przydadzą te opisy, które przygotowałem. Pozostaje mi życzyć powodzenie zainteresowanym, którzy zaczynają swoją przygodę z wirtualizacją więc życzę powodzenia (oraz wytrwałości).

You can leave a response, or trackback from your own site.

2 komentarze to “Serwer domowy z Proxmox VE (wirtualizacja) cz. 2”

  1. ukasz pisze:

    dzięki za podzielenie się swoją wiedzą

  2. Doctorek pisze:

    Dzień dobry. Podczas instalacji w dokładnych krokach wyskoczył mi błąd:

    root@alpha01:/home/delta# apt remove os-prober -y
    Czytanie list pakietów… Gotowe
    Budowanie drzewa zależności
    Odczyt informacji o stanie… Gotowe
    Pakiet “os-prober” nie jest zainstalowany, więc nie zostanie usunięty
    Następujące pakiety zostały zainstalowane automatycznie i nie są już więcej wymagane:
    courier-authdaemon courier-authlib courier-authlib-userdb
    courier-base expect libcourier-unicode1 libfam0 libtk8.6 libxss1
    tcl-expect tk8.6
    Aby je usunąć należy użyć “apt autoremove”.
    0 aktualizowanych, 0 nowo instalowanych, 0 usuwanych i 0 nieaktualizowanych.
    6 nie w pełni zainstalowanych lub usuniętych.
    Po tej operacji zostanie dodatkowo użyte 0 B miejsca na dysku.
    Konfigurowanie pakietu pve-firewall (3.0-5) …
    Job for pve-firewall.service failed because the control process exited with error code.
    See “systemctl status pve-firewall.service” and “journalctl -xe” for details.
    dpkg: błąd przetwarzania pakietu pve-firewall (–configure):
    podproces zainstalowany skrypt post-installation zwrócił kod błędu 1
    dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie pakietu qemu-server:
    qemu-server zależy od pve-firewall; jednakże:
    Pakiet pve-firewall nie jest jeszcze skonfigurowany.

    dpkg: błąd przetwarzania pakietu qemu-server (–configure):
    problemy z zależnościami – pozostawianie nieskonfigurowanego
    dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie pakietu proxmox-ve:
    proxmox-ve zależy od qemu-server; jednakże:
    Pakiet qemu-server nie jest jeszcze skonfigurowany.

    dpkg: błąd przetwarzania pakietu proxmox-ve (–configure):
    problemy z zależnościami – pozostawianie nieskonfigurowanego
    dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie pakietu pve-manager:
    pve-manager zależy od pve-firewall; jednakże:
    Pakiet pve-firewall nie jest jeszcze skonfigurowany.
    pve-manager zależy od qemu-server (>= 1.1-1); jednakże:
    Pakiet qemu-server nie jest jeszcze skonfigurowany.

    dpkg: błąd przetwarzania pakietu pve-manager (–configure):
    problemy z zależnościami – pozostawianie nieskonfigurowanego
    dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie pakietu pve-ha-manager:
    pve-ha-manager zależy od qemu-server; jednakże:
    Pakiet qemu-server nie jest jeszcze skonfigurowany.

    dpkg: błąd przetwarzania pakietu pve-ha-manager (–configure):
    problemy z zależnościami – pozostawianie nieskonfigurowanego
    dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie pakietu pve-container:
    pve-container zależy od pve-ha-manager; jednakże:
    Pakiet pve-ha-manager nie jest jeszcze skonfigurowany.

    dpkg: błąd przetwarzania pakietu pve-container (–configure):
    problemy z zależnościami – pozostawianie nieskonfigurowanego
    Wystąpiły błędy podczas przetwarzania:
    pve-firewall
    qemu-server
    proxmox-ve
    pve-manager
    pve-ha-manager
    pve-container
    E: Sub-process /usr/bin/dpkg returned an error code (1)

    Czy może wiązać się to z tym, że wcześniej na tym serwerze był zainstalowany postfix ?

Leave a Reply to Doctorek

You must be logged in to post a comment.

Powered by WordPress | Designed by: NewWpThemes | Provided by Free WordPress Themes