Hallo zusammen,
vor ziemlich genau einem Jahr habe ich in einer "Großaktion" mein gesamtes Homelab (>50 VMs) von ESXi auf Proxmox migriert. Ein Schritt, mit dem ich nach wie vor superglücklich bin.
Da ich aber noch keine Ahnung bezüglich der möglichen "Stolperfallen" und des Zeitpunktes habe, an dem ich ein superstabiles 8.4-Cluster auf 9 upgrade, würde ich gerne mal die Meinung und Erfahrung der "älteren Hasen" hier einsammeln, die sowas schon hinter sich haben.
Mein Cluster besteht aus 3 aktiven Nodes (2x Dell R730, 1x Dell R330) sowie zwei "Cold Spares" (Dell R720). Alles jeweils lokale Datastores (Local-LVMs auf Hardware-RAID-Arrays).
"Produktives" Homelab heißt, ich verdiene damit kein Geld aber es laufen halt sehr viele "privat kritische" VMs für uns hier zu Hause sowie meinen Sportverein. Nextclouds, TV-Server, Router, Homeassistant, FreePBX, und so weiter.
Ich kann nicht immer alles auf einen Reservehost schieben und zurück, alleine so eine Nextcloud-VM mit 4TB braucht dafür über einen halben Tag pro Weg ... und da ich das live machen muss, ist der Zielhost erst einmal lange kaum verwendbar, weil Proxmox ja erstmal mit irrsinninger I/O-Last die kompletten 4TB auf dem Zielhost "aufbläst".
Sprich: Die superkritischen, kleineren VMs (pfSense, Homeassistant, TV-Server etc.) würde ich vor dem Host-Update auf einen anderen Host "rüberschieben", aber der Großteil bleibt auf dem Host. Heißt dann: Geht das Upgrade von 8.4 auf 9 in die Hose, muss ich wohl komplett alles aus den Backups wiederherstellen, was in der Gesamtsumme Tage dauern dürfte.
Meine konkreten Fragen:
Gruß,
Marco
vor ziemlich genau einem Jahr habe ich in einer "Großaktion" mein gesamtes Homelab (>50 VMs) von ESXi auf Proxmox migriert. Ein Schritt, mit dem ich nach wie vor superglücklich bin.
Da ich aber noch keine Ahnung bezüglich der möglichen "Stolperfallen" und des Zeitpunktes habe, an dem ich ein superstabiles 8.4-Cluster auf 9 upgrade, würde ich gerne mal die Meinung und Erfahrung der "älteren Hasen" hier einsammeln, die sowas schon hinter sich haben.
Mein Cluster besteht aus 3 aktiven Nodes (2x Dell R730, 1x Dell R330) sowie zwei "Cold Spares" (Dell R720). Alles jeweils lokale Datastores (Local-LVMs auf Hardware-RAID-Arrays).
"Produktives" Homelab heißt, ich verdiene damit kein Geld aber es laufen halt sehr viele "privat kritische" VMs für uns hier zu Hause sowie meinen Sportverein. Nextclouds, TV-Server, Router, Homeassistant, FreePBX, und so weiter.
Ich kann nicht immer alles auf einen Reservehost schieben und zurück, alleine so eine Nextcloud-VM mit 4TB braucht dafür über einen halben Tag pro Weg ... und da ich das live machen muss, ist der Zielhost erst einmal lange kaum verwendbar, weil Proxmox ja erstmal mit irrsinninger I/O-Last die kompletten 4TB auf dem Zielhost "aufbläst".
Sprich: Die superkritischen, kleineren VMs (pfSense, Homeassistant, TV-Server etc.) würde ich vor dem Host-Update auf einen anderen Host "rüberschieben", aber der Großteil bleibt auf dem Host. Heißt dann: Geht das Upgrade von 8.4 auf 9 in die Hose, muss ich wohl komplett alles aus den Backups wiederherstellen, was in der Gesamtsumme Tage dauern dürfte.
Meine konkreten Fragen:
- Ab wann betrachtet man PVE9 als wirklich "stabil". Das erste Release ist 3 Monate her, aber wir sind noch nicht bei 9.1. Oder warte ich mit dem Upgrade besser bis 9.1?
- Wie ist eure Erfahrung mit dem Upgrade? Schmerzfrei, oder doch ein gewisses Risiko dass der Host nach dem Update nicht mehr hochkommt oder die VMs nicht mehr laufen?
- Die beiden "Haupt-Hosts" (R730) haben die Proxmox-Bootpartition auf einer eigenen RAID-1-VD, getrennt von den Datastores der VMs. Kann ich die Proxmox-Konfig komplett sichern und, wenn das Upgrade schieflaufen würde, irgendwie wieder zurück auf 8.4, ohne dass die VM's auf den anderen Arrays "kaputt-" oder verlorengehen?
- Vertragen sich PVE9-Hosts und PVE8.4-Hosts bedingungslos in einem Cluster? Dann würde ich die Reserve-Hosts mal zuerst upgraden, ein paar kritische VMs dahin rüberschieben, die anderen Hosts danach upgraden und die VMs wieder zurückschieben?
Gruß,
Marco
