Qcow2 - Konsistente Backups

Hallo,

in der UVMM kann man Sicherungspunkte erstellen. Wenn ich das Handbuch richtig verstanden habe, werden diese direkt im qcow2-File abgelegt.

Ich habe nun ein solches File kopiert und damit eine neue VM erstellt.
Dort war dann leider kein Sicherungspunkt vorhanden.

Gibt es unter UCS die Möglichkeit ein qcow2-File im laufenden Betrieb so zu sichern, dass ein konsistentes Filesystem entsteht oder man per Sicherungspunkt auf ein solches zurückgehen kann?
(wenn das File nicht im einem LV liegt)

LG,
Roland.

Hallo,

im Bugzilla findet man mit der Suche nach “qcow2 snapshot” auch nur offene Bugs, zum Thema Sicherungspunkte sagt die Doku auch nur, dass es sie gibt. Ich würde mich mit virsh (“snapshot list” etc) auf die Suche nach den Snapshots machen.

Wenn ich vor dem Problem stünde, würde ich wahrscheinlich nach diesem SDB-Artikel vorgehen. Da sieht man wenigstens, wo der Snapshot liegt.

Viele Grüße,
Dirk Ahrnke

Da bin ich auch dahinter her… Ich habe vergeblich mit virsh bzw. qemu-img versucht, einen externen Snapshot zu separieren (so dass die originale vm keine Kenntnis mehr von dem Snapshot hat - er also irgendwie weg gesichert werden kann) und laufe an mehreren Stellen auf:

root@prod:~# virsh snapshot-delete debian83test 1460623963
error: Failed to delete snapshot 1460623963
error: unsupported configuration: deletion of 1 external disk snapshots not supported yet

Das ist der eine Punkt: Einmal angelegt, sehe ich nicht, wie ich den externen Snapshot wieder weg bekomme.

Dann habe ich versucht, den Spiegel synchron zu bekommen:

root@prod:~# virsh blockcommit debian83test hda --active --verbose --pivot
error: unsupported configuration: online commit not supported with this QEMU binary

Hm, “virsh debian83test suspend” => geht danach auch nicht.
Hm, resume + anschließenden shutdown - ja, und da wird es lustig:

root@prod:~# virsh blockcommit debian83test hda --active --verbose --pivot
error: Requested operation is not valid: domain is not running

Da ist sich virsh offenbar nicht einig, was es denn so wirklich will…

Hat jemand einen Weg gefunden, mit der UCS 4.1 Version (z.B. mit qemu-img) einen Snapshot von der VM zu separieren? Wobei mir der Disk-Zustand reicht (virtuelles Power-Off also).

Danke und Gruß,
Gottfried

Hallo Gottfried

Ich habe ebenfalls versucht mit virsh blockcommit zu arbeiten. Allerdings deshalb, weil ich eine Ladung Snapshots zusammenführen will (merge).

Es scheint nun aber so, dass dieser Befehl den Red Hat Enterprise Kunden vorbehalten wird:
bugzilla.redhat.com/show_bug.cgi?id=1204186

oder vielleicht kommt es auch mit einer höheren qemu-version (Ich habe mit der neusten UCS-Installation -> Running hypervisor: QEMU 1.1.2)
wiki.libvirt.org/page/Live-disk- … lockcommit

//edit:
Offenbar würde es mit QEMU 2.1 funktionieren. Man kann diese über die backports installieren.
gonzalomarcote.com/2014/kvm … ith-qcow2/ -> siehe am Ende des Posts
Hat jemand eine Ahnung, wie das genau funktioniert? Folgende Zeile habe ich in /etc/apt/sources.list drin:

deb http://ftp.debian.org/debian wheezy-backports main

und mit folgendem Befehl versuche ich zu installieren

apt-get install -t wheezy-backports qemu

Allerdings komme ich da mit den Abhängigkeiten nicht weiter… Jemand einen Vorschlag?

Gruss Andy

Hallo Andy,

bei dem Kunden, um dessen neue Virtualisierungsumgebung es hier geht, läuft inzwischen ein Ubuntu 16.04 (LTS). Und zwar prima und ohne Mucken. Ich bin auch zu dem Schluss gekommen, dass neuere Software die Probleme löst - Debian 8 müsste auch problemlos funktionieren.

Von Univention weiß ich, dass das nächste UCS-Release (eben auf Basis von Debian 8) noch nicht in Sicht ist (Stand April - da war mit allen Vorbehalten von Ende 2016 die Rede). Falls also warten eine Option ist… War es für für mich/meinen Kunden nicht - also musste eine andere Lösung her.

Sonst könnte nur noch selber bauen helfen - aber ob die Kernel-Schnittstellen von dem UCS-Kernel dann noch passen, ist die Frage. Mein Gefühl: eher nein. Und irgendwas Produktives würde ich auf so einem Aufbau auch nicht laufen lassen wollen :slight_smile:

Tja, das ist wohl die Lage.

Was bei meinen Tests mit dem UCS funktioniert hat, war folgender Ablauf:

  • Externen Snapshot anlegen
  • Mit blockpull den Inhalt des Base-Files in das Snap-File übernehmen

Ich habe dann aber das Base-File online nicht von der VM weg bekommen, sonst hätte ich noch über ein rollierendes Verfahren zwischen zwei Snap-Dateien nachgedacht. Wäre ich da hin gekommen, dann hätte ich die Methode aber wahrscheinlich auch verworfen - den IO hätte ich den darunter liegenden SSDs nicht zumuten wollen.

Was eigentlich gehen sollte ist: VM offline nehmen und die Disk durch das verbleibende Snap-File ersetzen. Schlimmstenfalls muss man die VM neu bauen, damit man die alte einfach wegwerfen kann (und damit die Überbleibsel der Snapshots).

Viele Grüße,
Gottfried

Mastodon