Lost in Transaction

[uka]

Hallo zusammen,

Was kann hier falsch gelaufen sein, außer das "Etwas" im laufenden Betrieb selektiv die drei Volume-Dateien der VM gelöscht hat? Hab nie probiert, ob das überhaupt geht...

Nach einem kompletten Shutdown (Strom aus) der Firma startet die VM nicht. VM 701 hat drei Volumes, keines ist mehr vorhanden.
Image-Sicherung (Windows Backup der VM) des Vorabends hat mit Fehlern abgebrochen.

Danke euch im Voraus und Grüße!

Historie:
Januar 2024
Aufsetzen der VM auf Server A
2. Februar:
Einrichtung Server B mit PROXMOX VE 7
8. Februar:
Live-Migration der Volumes von Server A auf ein gemeinsames NFS
Kopie der Konfiguration nach Server B
Shutdown der VM auf Server A, Start der VM auf Server B
Live-Migration der Volumes vom gemeinsamen NFS auf das lokale RAID6 des Servers B
Entfernen der Konfiguration von Server A
Backup der VM vom RAID6 auf ein RAID1 des Servers (LZO)
(starting new backup job: vzdump 701 --compress lzo --mode snapshot --notes-template '{{guestname}}' --remove 0 --node pvesrv --storage local)
Backup abgebrochen wegen Last (besser nachts...)
Backup gelöscht
Clone der VM vom RAID6 auf ein RAID1
Erweiterung der VM um ein Volume
Reboot der VM
9. Februar:
Clone gelöscht
Clone der VM vom RAID6 auf ein RAID1, Task OK
Clone gelöscht
25. Februar
Reboot der VM
4. April:
Reboot der VM
2. Mai:
Reboot der VM
9. Mai
Reboot der VM
12. Juli
Shutdown/Reboot des Host
VM startet nicht, keines der drei Volumes vorhanden

Auszug Syslog (Shutdown des Hosts):

Jul 12 10:04:06 pvesrv pvedaemon[2963331]: <root@pam>    starting task    UPID:pvesrv:002D8157:20B08A4A:6690E376:qmshutdown:701:root@pam:
Jul 12 10:04:06 pvesrv pvedaemon[2982231]: shutdown VM 701:    UPID:pvesrv:002D8157:20B08A4A:6690E376:qmshutdown:701:root@pam:
Jul 12 10:04:11 pvesrv kernel: [5484444.941002] vmbr0: port    5(tap701i0) entered disabled state
Jul 12 10:04:11 pvesrv qmeventd[2954834]: read: Connection reset    by peer
Jul 12 10:04:11 pvesrv pvedaemon[2963331]:      VM 701 qmp command failed - VM 701 not running
Jul 12 10:04:11 pvesrv pvestatd[2180]: VM 701 qmp command      failed - VM 701 not running
Jul 12 10:04:11 pvesrv systemd[1]: 701.scope: Succeeded.
Jul 12 10:04:11 pvesrv systemd[1]: 701.scope: Consumed 1d 7h    32min 57.106s CPU time.
Jul 12 10:04:11 pvesrv qmeventd[2982260]: Starting cleanup for    701
Jul 12 10:04:11 pvesrv qmeventd[2982260]: trying to acquire    lock...
Jul 12 10:04:12 pvesrv qmeventd[2982260]:  OK
Jul 12 10:04:12 pvesrv qmeventd[2982260]: Finished cleanup for    701
Jul 12 10:04:12 pvesrv pvedaemon[2963331]: <root@pam> end    task    UPID:pvesrv:002D8157:20B08A4A:6690E376:qmshutdown:701:root@pam:    OK

# pveversion --verbose

proxmox-ve: 7.4-1 (running kernel: 5.15.158-1-pve)
pve-manager: 7.4-18 (running version: 7.4-18/b1f94095)
pve-kernel-5.15: 7.4-14
pve-kernel-5.15.158-1-pve: 5.15.158-1
pve-kernel-5.15.149-1-pve: 5.15.149-1
pve-kernel-5.15.143-1-pve: 5.15.143-1
pve-kernel-5.15.136-1-pve: 5.15.136-1
ceph-fuse: 14.2.21-1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx4
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.4
libproxmox-backup-qemu0: 1.3.1-1
libproxmox-rs-perl: 0.2.1
libpve-access-control: 7.4.3
libpve-apiclient-perl: 3.2-2
libpve-common-perl: 7.4-2
libpve-guest-common-perl: 4.2-4
libpve-http-server-perl: 4.2-3
libpve-rs-perl: 0.7.7
libpve-storage-perl: 7.4-3
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-2
lxcfs: 5.0.3-pve1
novnc-pve: 1.4.0-1
proxmox-backup-client: 2.4.7-1
proxmox-backup-file-restore: 2.4.7-1
proxmox-kernel-helper: 7.4-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.2
proxmox-widget-toolkit: 3.7.4
pve-cluster: 7.3-3
pve-container: 4.4-7
pve-docs: 7.4-2
pve-edk2-firmware: 3.20230228-4~bpo11+3
pve-firewall: 4.3-5
pve-firmware: 3.6-6
pve-ha-manager: 3.6.1
pve-i18n: 2.12-1
pve-qemu-kvm: 7.2.10-1
pve-xtermjs: 4.16.0-2
qemu-server: 7.4-6
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+3
vncterm: 1.7-1
zfsutils-linux: 2.1.15-pve1

 

[Falk R.]

Ganz klar ist mir nicht was du mit der ganzen klonerei bezweckt hast.
Wie sieht denn die VM Konfiguration aus?
Was siehst du denn auf dem Datastore wo die VM Disks liegen sollten?

 

[uka]

Das waren sozusagen Lasttests, der Server ist neu. Der Store enthält noch das Verzeichnis 701, das ist aber leer.
Ich versuche gerade, aus den Logfiles eine Historie der 701 zu generieren, aber es steht einfach bis zum Fehler nix da. Creepy!

/etc/pve/local/qemu-server# cat 701.conf

balloon: 0
boot: c
bootdisk: scsi0
cores: 4
cpu: host
ide0: none,media=cdrom
memory: 8192
name: testsrv
net0: virtio=12:A2:EC:A9:4F:D5,bridge=vmbr0
numa: 0
onboot: 1
ostype: win11
scsi0: local-opt:701/vm-701-disk-1.raw,cache=none,format=raw,size=256G
scsi1: local-opt:701/vm-701-disk-2.raw,cache=none,format=raw,size=256G
scsi2: local-opt:701/vm-701-disk-3.raw,cache=none,format=raw,size=256G
scsihw: virtio-scsi-pci
smbios1: uuid=ec66b464-679c-4857-8718-cf1209dc930b
sockets: 1
startup: order=701,up=30,down=300
tablet: 0

local-opt zeigt auf /opt/vz
/dev/sda1 30T 2,3T 27T 8% /opt (xfs)

 

[Falk R.]

Was zeigt dir der PVE im Datastore an? Sind da VM-Disks sichtbar?

 

[uka]

Klar, ich sehe alle, die da hingehören außer den drei Volumes der 701.

# pvesm list local-opt

Volid                           Format  Type               Size VMID
local-opt:207/vm-207-disk-1.raw raw     images     137438953472 207
local-opt:403/vm-403-disk-0.raw raw     images     274877906944 403
local-opt:403/vm-403-disk-1.raw raw     images    1099511627776 403
local-opt:403/vm-403-disk-2.raw raw     images    1099511627776 403
local-opt:409/vm-409-disk-0.raw raw     images     137438953472 409
local-opt:807/vm-807-disk-0.raw raw     images     137438953472 807
local-opt:808/vm-808-disk-0.raw raw     images     137438953472 808
local-opt:809/vm-809-disk-0.raw raw     images     274877906944 809
local-opt:810/vm-810-disk-0.raw raw     images    1125281431552 810

 

[ubu]

Ich nehme an bei einem der Löschvorgänge wurden die images gelöscht. Wenn eine Datei die von einem Prozess geöffnet ist gelöscht wird bleibt sie für diesen Prozess (hier kvm)
zugreifbar. Wird der Prozess beendet wird die Datei gelöscht.

 

[uka]

Ja, das drei Images in einem Verzeichnis gleichzeitig per Zufall gelöscht werden, kann man wohl ausschließen. Ich bin auch sicher nicht im Verzeichnis der 701 gewesen und habe sie per Hand gelöscht...

Aber warum sollten die originalen Images gelöscht werden, wenn ich ein Backup abbreche und die inkomplette .lzo-Datei entferne, oder wenn ich clone und anschließend den Clone lösche? Da ist was fischig.

 

[Falk R.]

Ja, das drei Images in einem Verzeichnis gleichzeitig per Zufall gelöscht werden, kann man wohl ausschließen. Ich bin auch sicher nicht im Verzeichnis der 701 gewesen und habe sie per Hand gelöscht...

Aber warum sollten die originalen Images gelöscht werden, wenn ich ein Backup abbreche und die inkomplette .lzo-Datei entferne, oder wenn ich clone und anschließend den Clone lösche? Da ist was fischig.

Da müsste man noch einmal ganz genau schauen, was genau du in welcher Reihenfolge gemacht hast. Oft sind es Kleinigkeiten die zu unerwarteten Ergebnissen führen.

 

[uka]

Vielen Dank, Falk. Es ist nett, dass Du Dich um die Sache bemühst. In welcher Beziehung steht Dein Statement zu meiner Eröffnungsnachricht?

Ich lasse es darauf beruhen, weil ich die VM aus der Sicherung vom Vor-Vortag wiederhergestellt habe. Leider war die Log Rotation des Hosts zu schnell, um weiter zurückschauen zu können. Es bleibt ganz klar ein schlechtes Gefühl.

 

[Falk R.]

Mich interessiert auch immer gern die Ursache. Ist es ein Bedienerfehler? Eventuell ein vermeidbarer Fehler wenn man etwas anpasst? Oder sogar ein Softwarefehler?
Oft ist es einfach Punkt 1, aber manchmal kann man eine zusätzliche Abfrage oder Prüfung einfügen um soetwas in Zukunft zu vermeiden. Da ich soetwas noch nie gesehen habe und soetwas im Forum noch nicht gelesen habe würde ich das schon gerne mal mit dir durchgehen.
Da ich aber gerade im Urlaub bin, kann ich nur auf dem Handy lesen, daher ist Logs durchsuchen gerade ungünstig.