Proxmox 3 vs Proxmox 4 inkl. Upgradeanleitung

Leider etwas verspätet aber dennoch hier nun der Artikel zum Upgrade auf Proxmox 4.

Ich gehe von meinen Erfahrungen während des Upgrades aus und gebe diese hier nur weiter.

Die größte Veränderung ist wohl der Wegfall von OpenVZ und ein Switch zu LXC Container. Das bringt ein paar Vorteile aber auch einige Nachteile mit sich die den Konfigurationsaufwand deutlich erhöhen. Es ist allerdings alles lösbar und durch den höheren Aufwand sollte man sich nicht abschrecken lassen.

Ein Vorteil ist ganz klar das LXC mehr Möglichkeiten bietet die Performance zu steigern. Die Container laufen mit deutlich weniger Ressourcen und „gefühlt“ schneller als mit OpenVZ und natürlich die Aktualität des Hostsystems.

Die AppArmor Integration dient zudem der erhöhten Sicherheit für die Hostsysteme. (Ohne diese Integration könnte man von einem Container sogar das Hostsystem rebooten. App Armor ist per Default integriert)

Ein weiterer Vorteil ist, dass LXC keinen besonderen Kernel benötigt und ziemlich jeden Mainstream Kernel unterstützt. OpenVZ hingegen arbeitet noch mit dem dem 2.6 Kernel aus dem Jahre 2009. Damit wäre es unmöglich Proxmox 3 auf einem Debian 8 System zum Laufen zu bringen.

Zu guter letzt ist auch die Entwicklung von LXC deutlich schneller als bei OpenVZ. Das wird in Zukunft schnellere Fixes und auch neue Features mit sich bringen.

Nichtsdestotrotz gibt es auch ein paar „Nachteile“ oder Umgewöhnungen.

Proxmox 4 kann, dem Umstieg auf LXC bedingt, kein „venet“ mehr. Es ist also immer eine Bridge notwendig. Das wiederum unterstützt nicht jeder Hoster. Eine Lösung dafür gibt es aber dennoch und diese findet ihr hier: LXC Netzwerkkonfiguration

Ein weiterer Nacheil sind die höheren Load Werte des Hostsystems. Ich habe 2 Systeme am Laufen, eins mit Proxmox 3 und eins mit Proxmox 4. Beide haben die identischen Container gestartet. der Proxmox 3 Host weist dabei einen Load von ca 3-4 auf. Der Proxmox 4 Host ist da bereits bei 4-5. 

Wieso? Das weiß wohl niemand so genau. Eine Vermutung ist jedoch das Filesystem der Container. Diese werden als RAW gespeichert und nicht mehr als reine chroot Umgebung.

Das wäre manuell jedoch änderbar. Allerdings ein riesen Aufwand.

Ein weiterer Nacheil ist, dass LXC die Hardware nicht komplett abschirmt. Wenn man also einem Container 1 CPU Kern zuweist, sich in den Container einloggt und mittels „top“ die CPU und den Load des Containers sehen möchte, so sieht man immer die CPU des Hosts und auch dessen Load. Aber auch das lässt sich mit einem Workaround lösen.

Für die Eigennutzung völlig egal aber für „Bezahlprodukte“ eher ungeeignet, da so natürlich niemand gern ein Upgrade vornimmt.

Die Zuweisung der Hardware funktioniert jedoch bestens. Jeder Container kann wirklich nur die Ressourcen nutzen die zugewiesen wurden.

 

Alles in allem ist Proxmox 4 jedoch eine sehr gute Weiterentwicklung und es bleibt weiterhin eine ideale und kostengünstige Virtualisierungslösung. Es ist nicht mehr so einfach zu handhaben und es werden mehr Linux Kenntnisse erforderlich aber das sollte kein Grund sein kein Upgrade durchzuführen.

Upgrade auf Proxmox 4 

Kommen wir also zum eigentlichen Upgrade. Ich gehe davon aus, dass bereits Proxmox 3 installiert ist und die Container alle migriert werden sollen. Dabei gibt es 2 Wege.

1. Proxmox 4 auf einem neuen Hostsystem aufsetzen
2. Proxmox 3 auf Proxmox 4 Upgrade ohne Neuinstallation des Servers

Variante 1 mit Neuinstallation auf einem anderen Hostserver

Proxmox auf einem neuen System aufzusetzen ist der deutlich bessere Weg. Man hat dabei keine Downtimes, hat ein sauberes System, kann die migrierten Container ausgiebig testen und zur Not den Container auch neu aufsetzen. Dies war bei mir notwendig da die Migration eines Tomcat Containers nicht wirklich laufen wollte bzw. das System nach der Migration einige Probleme machte (Tomcat stürzte ab, lange Reaktionszeiten, Load jenseits von gut und böse durch die migrierte Applikation usw).

Ich beschreibe hier die Variante 1.

Es muss also auf einem neuen System Proxmox 4 frisch installiert werden.

Das ist relativ easy. Einfach die Proxmox Repos hinzufügen, APT updaten und Proxmox installieren.

Sieht in der Konsole dann so aus:

[su_note note_color=“#c1c1b6″]

nano /etc/apt/sources.list

[/su_note]

Dort dann das Repo zur Installation hinzufügen

[su_note note_color=“#c1c1b6″]

deb http://download.proxmox.com/debian jessie pve-no-subscription

[/su_note]

Das Enterprise Repo wird automatisch hinzugefügt sobald ein valider Key eingegeben wurde.

Dann den APT Key hinzufügen

[su_note note_color=“#c1c1b6″]

wget -O- "http://download.proxmox.com/debian/key.asc" | apt-key add -

[/su_note]

Danach einfach das APT Update ausführen und Proxmox installieren

[su_note note_color=“#c1c1b6″]

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

[/su_note]

[su_note note_color=“#c1c1b6″]

apt-get install proxmox-ve ntp ssh postfix ksm-control-daemon open-iscsi systemd-sysv

[/su_note]

Jetzt kurz testen ob das Webinterface funktioniert indem man sich dort einloggt https://server_ip.com:8006 . Die IP oder Domain muss natürlich ersetzt werden (ggf. funktioniert das Webinterface erst nach einem Reboot).

Nun im Webinteface einfach eine Bridge erstellen. Alternativ kann dies auch direkt in „/etc/network/interfaces“ gemacht werden.

Um den neuen Kernel zu nutzen und um die Grub config zu testen, einmal den Server Rebooten.

Nach einem Reboot sollte mittels uname -r ein Proxmox Kernel gebootet sein. Die Kernel haben alle die Endung -pve und zum Zeitpunkt des Artikels war es die 4.2.8-1-pve

Nun brauchen wir von jedem Container des Proxmox 3 Hosts ein aktuelles Backup. Das kann einfach über das Webinterface angelegt werden.

Die Backups können einfach mittels wget oder rsync auf den neuen Host übertragen werden. Wer viel Zeit und eine gute Leitung hat kann diese auch herunterladen und auf den neuen Server hochladen.

Hat man die Backups auf dem neuen Host, kann man diese mit „pct restore ID“ ins LXC Format konvertieren und wiederherstellen.

[su_note note_color=“#c1c1b6″]

pct restore 100 /pfad/zum/backup.tar.gz

[/su_note]

Sieht in der Konsole insgesamt so aus

Die Meldung dass alles konvertiert und wiederhergestellt wurde bestätigt den Vorgang am Ende.

Nun muss lediglich im Webinterface eine neue IP hinzugefügt werden.

Die Anleitung dazu findet Ihr hier: LXC Netzwerkkonfiguration

Danach sollte der Container problemlos starten und mit der entsprechenden IP erreichbar sein.

[su_box title=“Tipp“ style=“glass“ box_color=“#e15908″]Ihr solltet am Ende wirklich alle Container einzeln starten und die Auslastung des Hosts vergleichen. Sollte sich der Mittelwert der Auslastung vom alten und dem neuen Hosts extrem unterscheiden, solltet Ihr den Container lieber neu aufsetzen und die Inhalte manuell auf den neu erstellten Container migrieren (Ich beschrieb oben dieses Problem mit den extremen Load Werten mit einem Tomcat Container).[/su_box]

 

Variante 2 Upgrade auf einem bestehenden Host ohne Neuinstallation des Servers

[su_box title=“Tipp“ style=“glass“ box_color=“#e15908″]Von dieser Variante Rate ich absolut ab. Die Probleme bei einem Upgrade sind teilweise so massiv, dass die Downtimes absolut nicht tragbar sind. Weiterhin ist eine Downtime, so kurz sie im Idealfall auch sein könnte, meistens untragbar. Es sollte auch klar sein, dass ein Rollback nicht möglich ist.[/su_box]

Aus diesem Grund gehe ich auch nicht zu sehr ins Detail, will es aber dennoch erwähnen.

Hier muss zwingend als erstes ein Backup jedes Containers gemacht werden. Das kann man normal im Webinterface anstoßen.

Hat man dies getan, kann man das alte Proxmox deinstallieren.

[su_note note_color=“#c1c1b6″]

apt-get remove proxmox-ve-2.6.32 pve-manager corosync-pve openais-pve redhat-cluster-pve pve-cluster pve-firmware 

[/su_note]

Nun in allen APT Sources in „/etc/apt/*“ in den Dateien „wheezy“ durch „jessie“  ersetzen.

Jetzt ein Update und Upgrade auf Jessie durchführen.

[su_note note_color=“#c1c1b6″]

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

[/su_note]

Anschließend den neuen Kernel und Proxmox installieren

[su_note note_color=“#c1c1b6″]

apt-get install pve-kernel-4.2.8-1-pve pve-firmware

[/su_note]

Jetzt kurz Rebooten und Proxmox anschließend installieren

[su_note note_color=“#c1c1b6″]

apt-get install proxmox-ve

[/su_note]

Jetzt entfernen wir die Reste von vzctl und dem Cluster

[su_note note_color=“#c1c1b6″]

dpkg --purge vzctl
dpkg --purge redhat-cluster-pve

[/su_note]

Und nun noch die alten configs und Dateien des Proxmox 3

[su_note note_color=“#c1c1b6″]

rm -f /etc/pve/openvz/<ct-id>.conf
rm -R <speicher-pfad>/private/*

[/su_note]

Sollte das Webinterface jetzt eine weiße Seite oder SSL Fehler liefern, einfach mal den Cache löschen und dann erneut aufrufen.

Nun kann mit dem normalen Restore der Container fortgefahren werden. Diesen findet Ihr ab dieser Stelle: Migration der OpenVZ Container auf LXC

Ich rate von diesem Weg aber wirklich ab. Die Downtime im Idealfall liegt bei ca einer Stunde. Da darf dann allerdings nix schief gehen.