Fehlgeschlagener Snapshot nach beinahe 20h

[Inworks IT]

Hallo zusammen,

wir hatten gestern einen seltsamen Vorfall auf einem unserer Proxmox-Server.
Es stand ein Update auf unserer Zimbra-VM an und zu diesem Zweck haben wir einen Snapshot angestoßen.
Da wir das ganze untertags vorhatten, haben wir einen Live-Snapshot (also mit RAM-Dump) gemacht.

Anfangs fing auch alles gut an:
saving VM state and RAM using storage 'statepool'
515.14 KiB in 0s
2.40 GiB in 1s
4.71 GiB in 2s
5.72 GiB in 3s
6.29 GiB in 4s
6.86 GiB in 5s
6.99 GiB in 6s

Allerdings brach die Geschwindigkeit nach kurzer Zeit massiv ein:
28.44 GiB in 46s
29.55 GiB in 47s
29.55 GiB in 48s
29.55 GiB in 49s
29.55 GiB in 50s

Das ganze endete dann so:
64.45 GiB in 19h 53m 44s
64.45 GiB in 19h 53m 54s
64.46 GiB in 19h 54m 4s
snapshot create failed: starting cleanup
TASK ERROR: query-savevm returned unexpected status 'failed'

Wir konnten nirgends eine Fehlermeldung finden, die uns einen Hinweis auf dieses Verhalten geliefert hätte.
Alle zpools sind in Ordnung, die SSDs liefern keine Fehler und auch ein Benchmark auf dem Pool hat Transferraten von 55 MB/s (mit fio) und mit 296 MB/s (mit ddrescue) ergeben.
Ein zweiter Lauf heute hat das selbe Verhalten gezeigt. Bei Abbruch des Snapshots war dann allerdings sogar die VM tot und auf dem Status 'stopped'.
Was zum Henker ist da los?

Ich hab beide Logs mal angehängt. Vielleicht ist da ja noch etwas Hilfreiches herauszulesen.

 

[ITT]

Habe hier leider die selbe Erfahrung (Ceph-Cluster)...
Snapshot startet mit "normaler" Geschwindigkeit und bricht dann total ein.
Ich verwende Snapshots eigentlich nie, daher ist es mir seit Kernel 5.15 nicht aufgefallen.
"Früher" ging das sehr schnell.

EDIT:
Gerade getestet auf einen unseren Testserver (no-subscription, aktuell) ging es wie gewohnt innerhalb weniger Sekunden.
Da sind aber auch qemu v7 und die letzten Kernel-Patches schon aktiv....

 

[fiona]

Hi,

Hallo zusammen,

wir hatten gestern einen seltsamen Vorfall auf einem unserer Proxmox-Server.
Es stand ein Update auf unserer Zimbra-VM an und zu diesem Zweck haben wir einen Snapshot angestoßen.
Da wir das ganze untertags vorhatten, haben wir einen Live-Snapshot (also mit RAM-Dump) gemacht.

Anfangs fing auch alles gut an:
saving VM state and RAM using storage 'statepool'
515.14 KiB in 0s
2.40 GiB in 1s
4.71 GiB in 2s
5.72 GiB in 3s
6.29 GiB in 4s
6.86 GiB in 5s
6.99 GiB in 6s

Allerdings brach die Geschwindigkeit nach kurzer Zeit massiv ein:
28.44 GiB in 46s
29.55 GiB in 47s
29.55 GiB in 48s
29.55 GiB in 49s
29.55 GiB in 50s

Das ganze endete dann so:
64.45 GiB in 19h 53m 44s
64.45 GiB in 19h 53m 54s
64.46 GiB in 19h 54m 4s
snapshot create failed: starting cleanup
TASK ERROR: query-savevm returned unexpected status 'failed'

leider haben wir die (wahrscheinlich vorhandene) Fehler-Nachricht von QEMU-Seite aus nicht ausgegeben. Ich habe dazu einen Patch gesendet.

Könntest Du bitte die Ausgabe von pveversion -v und qm config <ID> posten? Nach diesem Fehlschlag lief die VM noch oder?

Wir konnten nirgends eine Fehlermeldung finden, die uns einen Hinweis auf dieses Verhalten geliefert hätte.
Alle zpools sind in Ordnung, die SSDs liefern keine Fehler und auch ein Benchmark auf dem Pool hat Transferraten von 55 MB/s (mit fio) und mit 296 MB/s (mit ddrescue) ergeben.
Ein zweiter Lauf heute hat das selbe Verhalten gezeigt. Bei Abbruch des Snapshots war dann allerdings sogar die VM tot und auf dem Status 'stopped'.
Was zum Henker ist da los?

Ich hab beide Logs mal angehängt. Vielleicht ist da ja noch etwas Hilfreiches herauszulesen.

Das Problem mit dem Abbrechen ist schon bekannt und ist im aktuellen git gepatched. Wird leider aber noch ein bisschen dauern, bis es durch die internen Tests durch ist und durch die Repositories wandert.

 

[Inworks IT]

Könntest Du bitte die Ausgabe von pveversion -v und qm config <ID> posten? Nach diesem Fehlschlag lief die VM noch oder?

Die VM ließ sich anschließend wieder starten, ja.

# pveversion -v proxmox-ve: 7.1-1 (running kernel: 5.15.30-1-pve) pve-manager: 7.1-12 (running version: 7.1-12/b3c09de3) pve-kernel-5.15: 7.1-14 pve-kernel-helper: 7.1-14 pve-kernel-5.13: 7.1-9 pve-kernel-5.15.30-1-pve: 5.15.30-1 pve-kernel-5.15.27-1-pve: 5.15.27-1 pve-kernel-5.13.19-6-pve: 5.13.19-15 pve-kernel-5.13.19-2-pve: 5.13.19-4 ceph-fuse: 15.2.15-pve1 corosync: 3.1.5-pve2 criu: 3.15-1+pve-1 glusterfs-client: 9.2-1 ifupdown2: 3.1.0-1+pmx3 ksm-control-daemon: 1.4-1 libjs-extjs: 7.0.0-1 libknet1: 1.22-pve2 libproxmox-acme-perl: 1.4.1 libproxmox-backup-qemu0: 1.2.0-1 libpve-access-control: 7.1-7 libpve-apiclient-perl: 3.2-1 libpve-common-perl: 7.1-5 libpve-guest-common-perl: 4.1-1 libpve-http-server-perl: 4.1-1 libpve-storage-perl: 7.1-1 libspice-server1: 0.14.3-2.1 lvm2: 2.03.11-2.1 lxc-pve: 4.0.11-1 lxcfs: 4.0.11-pve1 novnc-pve: 1.3.0-2 proxmox-backup-client: 2.1.5-1 proxmox-backup-file-restore: 2.1.5-1 proxmox-mini-journalreader: 1.3-1 proxmox-widget-toolkit: 3.4-7 pve-cluster: 7.1-3 pve-container: 4.1-4 pve-docs: 7.1-2 pve-edk2-firmware: 3.20210831-2 pve-firewall: 4.2-5 pve-firmware: 3.3-6 pve-ha-manager: 3.3-3 pve-i18n: 2.6-2 pve-qemu-kvm: 6.1.1-2 pve-xtermjs: 4.16.0-1 qemu-server: 7.1-4 smartmontools: 7.2-1 spiceterm: 3.2-2 swtpm: 0.7.1~bpo11+1 vncterm: 1.7-1 zfsutils-linux: 2.1.4-pve1

# qm config 100 agent: 1,fstrim_cloned_disks=1 boot: order=ide2;scsi0 cores: 8 ide2: none,media=cdrom memory: 32768 meta: creation-qemu=6.1.1,ctime=1646150084 name: xxx.xxx.de net0: virtio=46:A3:B3:63:D0:B7,bridge=vmbr2 numa: 0 onboot: 1 ostype: l26 scsi0: basepool:vm-100-disk-0,aio=native,discard=on,iothread=1,size=1003G scsi1: vaultpool:vm-100-disk-0,aio=native,discard=on,iothread=1,size=3003G scsihw: virtio-scsi-single smbios1: uuid=9ac944c6-54b4-4799-b362-0f9e4a202c8b sockets: 1 template: 0 vmgenid: f0009411-8d60-4e02-abb6-367e27899bdc vmstatestorage: statepool

 

[Inworks IT]

Hi, Kollege vom Thread-Ersteller hier...
Status -> Aktuelle Softwareupdates gemacht. Versuch der Erstellung eines Snapshots dauert immer noch "ewig" und bricht erfolglos ab:
...
64.39 GiB in 1d 1h 8m 24s
64.40 GiB in 1d 1h 8m 34s
64.40 GiB in 1d 1h 8m 44s
64.41 GiB in 1d 1h 8m 54s
64.41 GiB in 1d 1h 9m 4s
64.42 GiB in 1d 1h 9m 14s
64.42 GiB in 1d 1h 9m 24s
64.43 GiB in 1d 1h 9m 34s
64.43 GiB in 1d 1h 9m 44s
64.43 GiB in 1d 1h 9m 54s
64.44 GiB in 1d 1h 10m 4s
64.44 GiB in 1d 1h 10m 14s
64.45 GiB in 1d 1h 10m 24s
64.45 GiB in 1d 1h 10m 34s
snapshot create failed: starting cleanup
TASK ERROR: query-savevm returned unexpected status 'failed'


# pveversion -v
proxmox-ve: 7.2-1 (running kernel: 5.15.39-4-pve)
pve-manager: 7.2-7 (running version: 7.2-7/d0dd0e85)
pve-kernel-5.15: 7.2-9
pve-kernel-helper: 7.2-9
pve-kernel-5.13: 7.1-9
pve-kernel-5.15.39-4-pve: 5.15.39-4
pve-kernel-5.15.30-1-pve: 5.15.30-1
pve-kernel-5.13.19-6-pve: 5.13.19-15
pve-kernel-5.13.19-2-pve: 5.13.19-4
ceph-fuse: 15.2.15-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve1
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.2-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-2
libpve-guest-common-perl: 4.1-2
libpve-http-server-perl: 4.1-3
libpve-storage-perl: 7.2-8
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.0-3
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.2.5-1
proxmox-backup-file-restore: 2.2.5-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.5.1
pve-cluster: 7.2-2
pve-container: 4.2-2
pve-docs: 7.2-2
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-5
pve-firmware: 3.5-1
pve-ha-manager: 3.4.0
pve-i18n: 2.7-2
pve-qemu-kvm: 7.0.0-2
pve-xtermjs: 4.16.0-1
qemu-server: 7.2-4
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.5-pve1



# qm config 100
agent: 1,fstrim_cloned_disks=1
boot: order=ide2;scsi0
cores: 8
ide2: none,media=cdrom
memory: 32768
meta: creation-qemu=6.1.1,ctime=1646150084
name: mail.inworks.de
net0: virtio=46:A3:B3:630:B7,bridge=vmbr2
numa: 0
onboot: 1
ostype: l26
scsi0: basepool:vm-100-disk-0,aio=native,discard=on,iothread=1,size=1003G
scsi1: vaultpool:vm-100-disk-0,aio=native,discard=on,iothread=1,size=3003G
scsihw: virtio-scsi-single
smbios1: uuid=9ac944c6-54b4-4799-b362-0f9e4a202c8b
sockets: 1
template: 0
vmgenid: f0009411-8d60-4e02-abb6-367e27899bdc
vmstatestorage: statepool



--> Wir werden jetzt wohl notgedrungen im Rahmen unserer Support Subscription ein Support Ticket lösen. Eine produktive Virtualisierungs Lösung in der man kein Snapshot machen kann ist für uns gelinde gesagt gerade etwas problematisch.

Viele Grüße & ein schönes WE