VM in seltsamen Zustand nach Watchdog getriggertem Reboot

[Björn Lässig]

Hallo,
nach der großen Überraschung, dass bei einem Upate, wenn 'watchdog-mux' restartet wird (by needrestart)
und dem Reboot zweier (von drei) Proxmox Cluster Servern, ist eine VM(#201) in seltsamen Zustand:

Die VM ist definiert auf dem Node "Holodeck12". Der local Storage der VM liegt aber noch auf dem Node "Holodeck11".
Die VM sollte eigentlich ausschließlich und nicht migrierbar auf "Holodeck11" laufen. Ich weiß nicht, wie sie nach Holodeck12 gekommen ist und warum "ihr storage" dabei vergessen wurde.

Wie bekomme ich die VM-definition jetzt dahin, wo ihr Storage liegt?

Der Cluster besteht aus 3• EPYC 7401P + 256G RAM (genannt holodeck11, holodeck12 und holodeck13)

Wenn ich versuche im Webinterface die VM dahin zu migrieren, wo der storage schon liegt,

2022-11-24 12:22:22 starting migration of VM 201 to node 'holodeck11' (xxxx:xxxx:0:xxxx:1d::3a)
2022-11-24 12:22:22 found local disk 'local-ssd:vm-201-disk-0' (in current VM config)
2022-11-24 12:22:22 copying local disk images
Use of uninitialized value $target_storeid in string eq at /usr/share/perl5/PVE/Storage.pm line 778.
Use of uninitialized value $targetsid in concatenation (.) or string at /usr/share/perl5/PVE/QemuMigrate.pm line 678.
2022-11-24 12:22:22 ERROR: storage migration for 'local-ssd:vm-201-disk-0' to storage '' failed - no storage ID specified
2022-11-24 12:22:22 aborting phase 1 - cleanup resources
2022-11-24 12:22:22 ERROR: migration aborted (duration 00:00:01): storage migration for 'local-ssd:vm-201-disk-0' to storage '' failed - no storage ID specified
TASK ERROR: migration aborted

Der Cluster ist ansonsten komplett auf dem stand pve-manager/7.3-3/c3928077 (running kernel: 5.15.74-1-pve).

 

[Björn Lässig]

Ich habe das Problem jetzt gelöst, indem ich:

/etc/pve/nodes/holodeck12/qemu-server/201.conf nach /etc/pve/nodes/holodeck11/qemu-server/ verschoben habe.

Also einfach die VM Definition verschoben. Dann konnte ich auf der Maschine, wo noch der passende Storage war, die VM auch starten.

 

[ITT]

Ich verwende "Needrestart" nur als Anzeige, nie als "restarter".
Das hat mich die Erfahrung gelehrt (im Cluster)

 

[Björn Lässig]

Ich verwende "Needrestart" nur als Anzeige, nie als "restarter".
Das hat mich die Erfahrung gelehrt (im Cluster)

Ich blackliste für needrestart alles was nicht restarted werden darf. Das was übrig bleibt mache ich dann ansible gesteuert in Wellen, je nach clusterservice.

 

[UdoB]

Ich verwende "Needrestart" nur als Anzeige, nie als "restarter".

In diesem Fall hatte aber "nur anzeigen lassen und dann manuell ausführen" in dieselbe Falle geführt, sofern man das Verhalten vom watchdog-mux nicht kannte...
Mein Standardaufruf sieht übrigens so aus: ~# apt full-upgrade 2>&1 | tee -a /var/log/apt/apt_$(date +%F).log && apt --purge autoremove && apt clean && needrestart -rl -l