Snapshot commit vs decommit?

Moin,

ich kämpfe auch gerade mit dem Thema Snapshots. leider hatte ich vor einigen Monaten vergessen, einen Snapshot zu löschen.

Die VM hat zwei virtuelleDisks (64G und 1.600G), die Snapshots sind mittlerweise 38G und 550G

Lösche ich den Snapshot in der Virtualization Szation steht der Ewigkeiten auf 0%, auch nach Stunden.

Jetzt hatte ich auf der Konsole nachgeschaut, was die Kiste denn eigentlich macht.

Der qemu-img Prozess läuft und schreibt die ".bk" Datei solange, bis sie genau groß ist wie die Snapshot-Datei. Und arbeitet dann an vdb.

/QVS//usr/bin/qemu-img decommit -b /share/VMs/debianvm/debianvm_vda.img -c /share/VMs/debianvm/debianvm_vda.1235549876 --backup /share/VMs/debianvm/debianvm_vda.img.bk

Jetzt habe ich versucht, Informationen über den Parameter "decommit" zu bekommen, bin aber nirgendwo fündig geworden. Ist das eine Besonderheit des QNap Hero OS

Nun würde ich gerne die Snapshots manuell einspielen, eigenlich ist ja der "commit" dafür gedacht (nicht "decommit"). Ich denke, den kann ich einfach so einsetzen oder sind da Probleme zu erwarten?

IDeen?

/KNEBB

Moin,

hmmm... wofür braucht man die Versionen, um mir zu erklären, was der "decommit" Befehl macht? Aber sei es drum: Aktuellstes QTS hero, VirtStaation ebenfalls (3.x, nicht beta).

Und nein, ich habe nicht das gleiche Problem, wie in dem anderen Thread geschildert, den hatte ich gesehen.

Wenn ich das richtig intergpretiere, macht der "decommit" Befehl nichts anderes, als eine Kopie des Snapshots als Rückfallmöglichkeit zu ertellen (--backup). Das macht die VirtsStation für beide VirtDisks. Ist die VirtStation damit fertig, wird sie vermutlich die Snapshots mittels "commit" auf die Base-Platte einspielen und bei Erfolg die Snapshot-Disk als auch das Backup löschen. Es werden also massiv Daten hin- und hergeschoben. Ist kein Problem bei den üblichen kleinen Snapshots. Hier macht der decommit mit den Backup-Dateien aber 38G+550G= 538G zusätzlichen HDD-Platz "locker". Aktuell sind "nur" 413G frei. Selbst wenn ich es laufen lasse, wird das später schief gehen.

Deshalb mache ich das jetzt manuell und direkt mittels "commit" und hoffe, dass es funktioniert.

Gibt es irgend etwas, was ich dabei beachten muss?

/KNEBB

So, auch hier wieder eine Lösung.

Eine , die ich selbst herausgefunden habe.

Wichtig ist, zu überprüfen, dass man die richtigen Dateien zusammenfügt. Das habe ich mit "info" festgestellt und auf das "backing_file" geachtet. Mit diesem dann den folgenden commit-Befehl gefüttert.

[/share/VirtualMachines/backuppc41] # /QVS/usr/bin/qemu-img info backuppc41_vdb.1686549550
image: backuppc41_vdb.1686549550
file format: qcow2
virtual size: 1.46 TiB (1610612736000 bytes)
disk size: 568 GiB
cluster_size: 65536
backing file: backuppc41_vdb.img
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false

Wie gesagt habe ich dann einfach den commit-Befehl gestartet:

/QVS/usr/bin/qemu-img commit -b backuppc42_vdb.img -d -p backuppc42_vdb.1686556047

Der hat eine schöne Prozentausgabe gemacht und danach hatte ich alle Änderungen des Snapshots im eigenlichen Base-Image.

Die Snapshot Datei gelöscht:

rm backuppc42_vdb.1686556047

Dann nur noch einen neuen (Dummy-) Snapshot erstellt, damit die Buchführung von QuTS nicht durcheinanderkommt. Auf den gleichen Namen setzen, wie die gerade gelöschte Datei! Und auf der Web-GUI dann den Snapshot gelöscht. Fertig.

/QVS/usr/bin/qemu-img create -b backuppc42_vdb.img -f qcow2 backuppc42_vdb.1686556047

Schwupps! Alles Snapshots weg und es läuft alles wieder einwandfrei.

/KNEBB