slu hat geschrieben: 29.12.2021 16:09:28
reox hat geschrieben: 29.12.2021 15:54:29
Ich habe bei mir eine etwas andere Lösung gewählt und verwende --quiesce in kombination mit
qemu-guest-agent - dadurch kann man aber auch den State nicht speichern.
Ja das wird in dem Mailinglist Thread auch erwähnt und als ziemlich/fast sicher beschrieben, wenn der RAM aber zusätzlich mit kommt kann das nicht schaden.
Leider geht --quiesce in der Kombination mit --memspec nicht, ein Kompromiss muss man halt eingehen
Was mir noch nicht ganz klar ist: Wenn ich das RAM image habe, wie kann ich dann im Backup Fall die Maschine wieder starten? Den richtigen virsh befehl hab ich da noch nicht gefunden
slu hat geschrieben: 29.12.2021 16:11:14
Mir ist kein anderer Weg bekannt.
Hmm.. ich wollte in mein Backup script einen verlässlichen Check einbauen, ob das Snapshot Image gelöscht werden kann. Wenn es nämlich noch da ist, verweigert virsh snapshot-create-as den Dienst - aber es könnte ja sein, dass der Blockcommit nicht funktioniert hat und dann lösche ich das Image wohlmöglich einfach weg. Rein von der Ausgabe von domblkinfo kann man nicht immer 100% sicher sein, dass das Image nicht in betrieb ist. zB könnte ja ein weiterer snapshot dran hängen. Allerdings schreibt qemu-img info mir immer die gesamte Kette raus, auch wenn der blockcommit durchgeführt wurde. Und auf das original image kann ich mit qemu-img nicht zugreifen, solange die VM rennt...
Vllt ist aber auch genau das ein guter Test:
Code: Alles auswählen
# virsh snapshot-create-as --domain testvm --name backup-snapshot.qcow2 --no-metadata --atomic --quiesce --disk-only --diskspec vda,snapshot=external
Domain snapshot backup-snapshot.qcow2 created
# qemu-img info /vmimages/testvm.backup-snapshot.qcow2
qemu-img: Could not open '/vmimages/testvm.backup-snapshot.qcow2': Failed to get shared "write" lock
Is another process using the image [/vmimages/testvm.backup-snapshot.qcow2]?
# qemu-img info /vmimages/testvm.img
image: /vmimages/testvm.img
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 1.9G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
# virsh domblklist testvm
Target Source
--------------------------------------------------
vda /vmimages/testvm.backup-snapshot.qcow2
# virsh blockcommit testvm vda --active --pivot --wait --verbose --delete # --delete wird unter Buster noch nicht unterstützt...
error: unsupported flags (0x2) in function qemuDomainBlockCommit
# virsh blockcommit testvm vda --active --pivot --wait --verbose
Block commit: [100 %]
Successfully pivoted
# qemu-img info /vmimages/testvm.img
qemu-img: Could not open '/vmimages/testvm.img': Failed to get shared "write" lock
Is another process using the image [/vmimages/testvm.img]?
# qemu-img info /vmimages/testvm.backup-snapshot.qcow2
image: /vmimages/testvm.backup-snapshot.qcow2
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 2.3M
cluster_size: 65536
backing file: /vmimages/testvm.img
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
# qemu-img info --backing-chain /vmimages/testvm.backup-snapshot.qcow2 # Leider kann man die Backing-Chain im Betrieb auch nicht ausgeben lassen, weil dazu alle images angeschaut werden...
qemu-img: Could not open '/vmimages/testvm.img': Failed to get shared "write" lock
Is another process using the image [/vmimages/testvm.img]?
Solange der snapshot aktiv ist, kann man keine info auslesen.
Übrigens, das was auf der ML steht funktioniert bei mir nach dem blockcommit nicht:
Code: Alles auswählen
# virsh snapshot-delete testvm backup-snapshot.qcow2
error: Domain snapshot not found: no domain snapshot with matching name 'backup-snapshot.qcow2'