Windows VMs booten nicht

[Heidegeist]

Hallo allerseits,

nach einem Bedienungs-/Konfigurationsfehler meinerseits booten einige Windows-VMs in die "Automatische Reparatur".
Die folgende Beschreibung ist vielleicht etwas schwammig und wenig spezifisch, aber vielleicht kann mir jemand erklären, was da passiert sein kann.

Ich habe seit ca 6 Monaten einen 2-Node-Cluster mit Ceph und HA, der bis hierhin gefühlt super lief.
Am Donnerstag letzter Woche wollte ich einen dritten Node hinzufügen.
Ich habe PVE installiert und (voreilig) den Cluster-Join über das Web-GUI durchgeführt. Aber keine VMs migriert, nichts!

Am nächsten Tag fiel mir dann ein, dass ich doch noch Änderungen am Storage des dritten Nodes außerhalb von PVE machen muss.
Also habe ich, wohl wieder etwas voreilig, per Konsolenbefehl pvecm delnode node3 den Node entfernt.
Mir fiel auf:
Im verbleibenden Cluster (Node1 + Node2) tauchte Node 3 nicht mehr auf.
In der GUI von Node3 waren Node1 und Node2 jedoch noch immer gelistet.

Dann das Desaster:
Einige - nicht alle - VMs liefen nicht mehr und kamen beim Reboot-Versuch nur noch bis in die "Automatische Reparatur" von Windows.
Im GUI von Node3 sind ALLE VMs gelistet, als wenn sie auf diesem Node laufen würden. Was nicht sein kann, denn ich habe nichts migriert.

Bis auf eine habe ich die betroffenen VMs aus Backup-Images wiederherstellen können.
Node3 ist jetzt im Labor und netzwerktechnisch getrennt vom LAN. PVE läuft aber noch und nach wie vor sind alle Nodes und VMs dort gelistet. Als hätte er nicht mitbekommen, dass er nicht mehr mitspielen darf.

Was ist da also passiert, warum hat es die VMs zerlegt, als ich den Node entfernt habe?

Danke und Gruß
Andreas

 

[itNGO]

Wenn du einen Node aus dem Cluster mit "pvecm delnode node X" entfernst, hat dieser Node "NICHT" wieder zu kommen im Netz.
Siehe WIKI https://pve.proxmox.com/wiki/Cluster_Manager -
"At this point, you must power off hp4 and ensure that it will not power on again (in the network) with its current configuration."

As mentioned above, it is critical to power off the node before removal, and make sure that it will not power on again (in the existing cluster network) with its current configuration. If you power on the node as it is, the cluster could end up broken, and it could be difficult to restore it to a functioning state.

Wenn dieser Node wieder mit dem Cluster spielen soll, sollte/muss der auch neu Installiert werden.

Und für Änderungen am Storage oder der Hardware "ausserhalb" von Proxmox ist ein "evict" auch nicht notwendig. Da warst du meiner Meinung nach etwas voreilig....

Sicherste Variante nun, um "Kartei-Leichen" im Cluster zu vermeiden.... Backup der VMs... Cluster ein mal neu.... alles andere "kann" klappen.... "kann" aber auch schief gehen... nicht heute, nicht morgen..... irgendwann aber evtl....

 

[Heidegeist]

Ja, ich war wirklich zu unbedacht. Das sollte eine Lehre gewesen sein.
Trotzdem bleibt die Frage, was da technisch genau passiert ist?
Auf dem Node war ja noch nichts. Ceph war installiert, aber noch keine OSDs angelegt.
Warum hat es mir die VMs zerlegt, als ich den Node - ja, unsachgemäß - entfernt habe?

Nach meinem rudimentären Verständnis sollten die VMs doch nur auf dem Ceph gelebt haben, dass über node1 und node2 verteilt war/ist. Trotzdem hat es das Dateisystem nahezu aller VMs schwer beschädigt (chkdsk...), als node3 nicht mehr da war.

 

[itNGO]

Ja, ich war wirklich zu unbedacht. Das sollte eine Lehre gewesen sein.
Trotzdem bleibt die Frage, was da technisch genau passiert ist?
Auf dem Node war ja noch nichts. Ceph war installiert, aber noch keine OSDs angelegt.
Warum hat es mir die VMs zerlegt, als ich den Node - ja, unsachgemäß - entfernt habe?

Nach meinem rudimentären Verständnis sollten die VMs doch nur auf dem Ceph gelebt haben, dass über node1 und node2 verteilt war/ist. Trotzdem hat es das Dateisystem nahezu aller VMs schwer beschädigt (chkdsk...), als node3 nicht mehr da war.

Du hast Node3 entfernt, während er noch online und mit dem Rest des Clusters verbunden war.
Das kann dazu führen das der Node "buchstäblich" Schrott in den Cluster geschickt hat..... Deswegen steht ja in der Anleitung auch "power off the node before removal".

 

[Heidegeist]

Hm, OK. Kann ich denn davon ausgehen, dass der jetzige Zustand stabil bleibt? Oder herrscht jetzt eine Art Entropie, die den Laden Bit für Bit auseinanderbaut? Ich weiß, Du hast geraten, den ganzen Cluster neu aufzusetzen. Ist aber etwas schwierig, denn ich habe u.a. eine VM mit ca. 40TB Nutzdaten. Da würde ich Backup/Restore/Migration etc gern vermeiden...

 

[itNGO]

Hm, OK. Kann ich denn davon ausgehen, dass der jetzige Zustand stabil bleibt? Oder herrscht jetzt eine Art Entropie, die den Laden Bit für Bit auseinanderbaut? Ich weiß, Du hast geraten, den ganzen Cluster neu aufzusetzen. Ist aber etwas schwierig, denn ich habe u.a. eine VM mit ca. 40TB Nutzdaten. Da würde ich Backup/Restore/Migration etc gern vermeiden...

Ist am Ende des Tages natürlich deine Entscheidung. Es ist halt ein Risiko. Ob es ein kalkulierbares ist, kann ich nicht sagen. Im DataCenter und Kunden-Bereich machen wir solche Späße nicht. Wenn es dort "so" kracht durch Anwenderfehler, dann gibt es da nur: Einmal grüne Wiese. Allerdings haben wir für solche Fälle auch immer einen Ersatz-Zoo für Datacenter oder Kunde parat und müssen ja im Nachgang für die Konfiguration auch grade stehen....

 

[itNGO]

Ggf. macht in so einem Fall aber der Erwerb einer Subskription mit Support sinn, damit man die Profis dazu direkt "befragen" kann, ob man das "so lassen" kann.... Bei einem Cluster sollte das eh mit Subscription laufen. Kann ja immer mal was "richtig" schief gehen....