Snaphots Problems

[inno-forum]

Wir kriegen oft Ärger mit Snapshots.
Beim Erstellen hängt die VM und bei Löschen ist noch schlimmer.

Anbei ein paar Tests


Erstellen
Test 1 - 12:42 test1_ohne_Ram, mit VM angeschaltet und ohne HA
Duration 3m 59

VM war sofort nicht mehr erreichbar
Nach Snapshot war wieder erreichbar.

Löschen von test1_ohne_Ram

Duration 10m
TASK ERROR: VM 102 qmp command 'blockdev-snapshot-delete-internal-sync' failed - got timeout

Snapshot Status: delete

VM war sofort nicht mehr erreichbar

ich habe die VM unlocked
VM war nicht mehr erreichbar

ich habe die VM neu gestartet

2. Versuch durch Konsole

qm delsnapshot 102 test1_ohne_Ram -force

VM 102 qmp command 'blockdev-snapshot-delete-internal-sync' failed - Snapshot with id 'null' and name 'test1_ohne_Ram' does not exist on device 'drive-scsi0'

VM war während der Löschung nicht erreichbar
Duration: 26s
Danach Snapshot war weg und VM läuft.

-------------Test 2 - test2 mit VM abgeschaltet und ohne HA-----------------------------------------
Erstellen
Duration 14,6s


Löschen von test2

Duration 2m 7

Hat geklappt
-------------------------------------------------------------
Manchmal klappt bei ausgeschaltete VMs auch nicht.

In die meisten Fällen dauert ewig und wird nicht gelöscht.

Beim zweiten Versucht kommt diese Meldung

VM xxx qmp command 'blockdev-snapshot-delete-internal-sync' failed - Snapshot with id 'null' and name '---------' does not exist on device 'drive-scsi0'
Und die Snapshot verschwindet.


An sich sollte auch mit angeschaltete VMs funktionieren.

Mit RAM passiert genau das Gleiche.

Wenn ich bei der Untersuchen mit Logs helfen kann, einfach Bescheid geben.

Es wäre toll, wenn es zuverlässig funktioniert wurde

Danke

Info:
Cluster mit 5 Proxmoxs

Storage:
NAS

VM Config
agent: 1,fstrim_cloned_disks=1
balloon: 4096
bios: ovmf
boot: order=scsi0;ide2;scsi4
cores: 4
cpu: host
efidisk0: xxx-NAS:102/vm-102-disk-4.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
machine: pc-i440fx-7.2
memory: 8192
name: test-VM
net0: virtio=3E:F2:04:4D:69:75,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: win10
scsi0: xxx-NAS:102/vm-102-disk-0.qcow2,discard=on,size=127G
scsi1: xxx-NAS:102/vm-102-disk-1.qcow2,discard=on,size=53G
scsi2: xxx-NAS:102/vm-102-disk-2.qcow2,discard=on,size=107G
scsi3: xxx-NAS:102/vm-102-disk-3.qcow2,discard=on,size=900G
scsi4: none,media=cdrom
scsihw: virtio-scsi-pci
smbios1: uuid=6b9ce577-3800-4a74-b044-944c29914b72
sockets: 1
vga: std
vmgenid: 12f8a5dc-1223-43cd-9a90-ae0e40d91f20

 

[fiona]

Hi,
der RAM selbst wird asynchron gespeichert, aber das Erstellen und Löschen von Snapshots auf großen qcow2-Disken ist leider nicht die effizienteste Operation (und wenn es über das Netzwerk läuft wird es natürlich nicht besser) und momentan muss währenddessen der Gast blockiert werden. Beim Löschen gibt es eine Idee, die Situation zu verbessern und das ganze asynchron zu machen, ist aber noch nicht umgesetzt.

 

[inno-forum]

Hi,
der RAM selbst wird asynchron gespeichert, aber das Erstellen und Löschen von Snapshots auf großen qcow2-Disken ist leider nicht die effizienteste Operation (und wenn es über das Netzwerk läuft wird es natürlich nicht besser) und momentan muss währenddessen der Gast blockiert werden. Beim Löschen gibt es eine Idee, die Situation zu verbessern und das ganze asynchron zu machen, ist aber noch nicht umgesetzt.

alles klar.

Wird mit andere Disk Formate besser funktionieren?

Haben Sie eine empfohlene Vorgang? Für Erstellen und löschen?
Z.B. mit ausgeschalteter VM, oder löschen direkt mit "--force" bei so eine große VM.

Ich hoffe, dass die Idee umgesetzt wird, das wird uns sicher helfen

Danke

 

[fiona]

alles klar.

Wird mit andere Disk Formate besser funktionieren?

Für file-based Storages geht leider nur qcow2. Wenn du shared Storage mit Snapshots brauchst, gäbe es nur Ceph als Alternative.

Haben Sie eine empfohlene Vorgang? Für Erstellen und löschen?
Z.B. mit ausgeschalteter VM, oder löschen direkt mit "--force" bei so eine große VM.

Force würde helfen, dass nach dem Timeout auch noch mit den anderen Disks weitergemacht wird und die VM nicht gelockt bleibt, aber der Gast ist halt trotzdem lange blockiert.