Proxmox 6.4.x - immer noch mega stabil & geil - ich will kein Update ...

Hmm, ich habe einen gewissen Trackrecord im Updaten von Proxmox Clustern, tlw über mehrere Versionen, wenn ich beim Kunden verwahrloste ungepflegte Systeme updaten musste. Von daher mal ein bisschen best practice:

- Wenn man sich Streng an die extrem gute Dokumentation im Proxmox wiki hält kann da eigentlich nichts schief gehen.
- Idealerweise sollte man schon genau wissen, was man vorher an den Hostsystemen verändert hat und das auch verstanden haben, um einzuschätzen ob das mit dem Update kollidiert.

- Bevor etwas upgedated wird, jeden Host mal evakurieren und durchbooten, um zu schauen ob die Netzwerkconfig passt.

- Vom Modus her kann man eigentlich immer ein Rolling pool upgrade machen, allerdings sollte man beachten, daß bei grossen Versionssprüngen (von QEMU zB) auch der Gast mal gebooted werden sollte, aber das sollte er bei entsprechenden Betriebssystem updates ja sowieso.

- Wenn es wirklich wirklich wichtig ist, hat man eine identisch Version der Hostsysteme zB in ein paar Virtualbox VMs laufen und macht dort einen Probelauf der updates.

- Wie bereits von anderen Personen erwähnt empfehle, ich dringend die Hostsysteme so unangetastet wie möglich zu lassen, dann verlieren Cluster updates auch ihren Schrecken.

vg
 
Hmm, ich habe einen gewissen Trackrecord im Updaten von Proxmox Clustern, tlw über mehrere Versionen, wenn ich beim Kunden verwahrloste ungepflegte Systeme updaten musste. Von daher mal ein bisschen best practice:

- Wenn man sich Streng an die extrem gute Dokumentation im Proxmox wiki hält kann da eigentlich nichts schief gehen.
- Idealerweise sollte man schon genau wissen, was man vorher an den Hostsystemen verändert hat und das auch verstanden haben, um einzuschätzen ob das mit dem Update kollidiert.

- Bevor etwas upgedated wird, jeden Host mal evakurieren und durchbooten, um zu schauen ob die Netzwerkconfig passt.

- Vom Modus her kann man eigentlich immer ein Rolling pool upgrade machen, allerdings sollte man beachten, daß bei grossen Versionssprüngen (von QEMU zB) auch der Gast mal gebooted werden sollte, aber das sollte er bei entsprechenden Betriebssystem updates ja sowieso.

- Wenn es wirklich wirklich wichtig ist, hat man eine identisch Version der Hostsysteme zB in ein paar Virtualbox VMs laufen und macht dort einen Probelauf der updates.

- Wie bereits von anderen Personen erwähnt empfehle, ich dringend die Hostsysteme so unangetastet wie möglich zu lassen, dann verlieren Cluster updates auch ihren Schrecken.

vg
Danke für Deine Rückmeldung und Darstellung.

Eine Frage zum Update allgemein. In einem Cluster mit mehreren PVEs unter 6.4, was würde dagegensprechen z.B 2x PVE mit v7.x upzugraden und parallel laufen zu lassen mit 1oder 2 TestVM's für 2 Wochen?

Corosync hat sich doch nicht geändert?
VG
 
Danke für Deine Rückmeldung und Darstellung.

Eine Frage zum Update allgemein. In einem Cluster mit mehreren PVEs unter 6.4, was würde dagegensprechen z.B 2x PVE mit v7.x upzugraden und parallel laufen zu lassen mit 1oder 2 TestVM's für 2 Wochen?

Corosync hat sich doch nicht geändert?
VG

Du meinst den Cluster im "mixed mode" zu betreiben? Es ist halt nicht recommended, und ich habe das bislang noch nicht gemacht. Ich kann mir schon vorstellen, daß es dort ungetestete Szenarien gibt, in denen es krachen könnte, und ich bemühe mich immer das Rolling pool upgrade so schnell wie möglich durch zu bekommen. Wie gesagt, bei allzuhohen Versionssprüngen von QEMU ist es eh empfohlen die VMs mal zu booten.

Ich habe mir für solche Fälle (allerdings für Ceph basierte cluster) ein bisschen tooling geschrieben, um VMs online in einen zweiten Cluster zu replizieren um es dort zu testen und dann optional mit minimaler Downtime in einen neuen Cluster zu migrieren (https://github.com/lephisto/crossover/). Geht halt nur mit Ceph weil es hart auf RBD export/import basiert.
 
Last edited:
Mixed Mode mal 2 Tage laufen lassen kann man schon mal, aber oft hat man mehr issues mit dem Mix als das rolling Upgrade.

Wenn man einen zweiten Cluster hat, kann man auch im laufenden Betrieb migrieren, soweit die CPU Kompatibilität mitspielt.
 
Mixed Mode mal 2 Tage laufen lassen kann man schon mal, aber oft hat man mehr issues mit dem Mix als das rolling Upgrade.

Wenn man einen zweiten Cluster hat, kann man auch im laufenden Betrieb migrieren, soweit die CPU Kompatibilität mitspielt.

Wie machst Du das? Ich war der Auffassung dass livemigration über clustergrenzen hinweg so nicht möglich ist.
 
Last edited:
Mixed Mode mal 2 Tage laufen lassen kann man schon mal, aber oft hat man mehr issues mit dem Mix als das rolling Upgrade.

Wenn man einen zweiten Cluster hat, kann man auch im laufenden Betrieb migrieren, soweit die CPU Kompatibilität mitspielt.
Bei mir haben die VMs immer neu gebootet, CPU Kompatibilität war also gar nicht so nötig.


Wie machst Du das? Ich war der Auffassung dass livemigration über clustergrenzen hinweg so nicht möglich ist.
Live war die VM nur bis zum Zeitpunkt wo alles drüben war und dann kam der Reboot. ;)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!