qcow2 auf LVM - Snapshot delete hängt sich weg

[Falk R.]

Moin,
ht schon mal jemand das Problem gehabt, dass VMs gelockt sind und ein Snapshot löschen im Status delete steckenbleibt?
Das Setup ist qcow auf shared LVM (FC LUNs)
Bei den meisten VMs funktioniert alles korrekt, aber immer wieder bleibt nach den Backups mit Commvault eine Vm gelockt und der Snapshot steht im Status delete.
Der status bleibt auch über Tage unverändert.

Mit der Option force kann man den Snapshot löschen (nach einem unlock der VM), aber dann bleibt immer eine Disk, in der Regel die OS Disk auf der Snapshotdisk.
Wenn ich mir mit qm monitor ein info block ausgeben lasse nutzt die VM das Snapshot qcow. Die Original qcow welche in der VM Konfiguration drin steht wird auch mit 0 Byte angezeigt.
Weiß jemand ob man das Mapping auch ohne Downtime wieder gerade ziehen kann?

 

[Bu66as]

Snapshot-Löschen auf qcow2/LVM ist bei uns bisher nicht hängen geblieben, aber klingt nach einem block-commit, der im QMP nie fertig wird. Schau mal mit info block-jobs im qm monitor ob da noch ein Job drinhängt (offset/len vergleichen, ob er überhaupt Fortschritt macht). Wenn ja, würd ich den nicht abschießen sondern mit block_job_complete abschließen, cancel wirft dich sonst genau in den Zustand den du jetzt hast.

Wenn kein Job mehr läuft und die VM stabil auf dem Snapshot-Layer schreibt, kannst du den Commit von Hand nachziehen: block-commit auf das Device aus info block, ohne top/base commitet er die ganze Chain nach unten, danach complete und der aktive Layer ist wieder die Basis-qcow. Das geht ohne Downtime, vorher aber ein Backup falls die Kette doch inkonsistent ist. Die 0 Byte an der Original-Disk würd ich vorher klären - bei einer intakten Backing-Chain sollte da die volle virtuelle Größe sein.

Welche pve-qemu-kvm und PVE-Version läuft da? Und macht Commvault die Snapshots über die PVE-API oder direkt am Storage vorbei? Falls die parallel zum vzdump/PBS-Job laufen, wär auch ein Lock-Konflikt eine heiße Spur.

 

[Falk R.]

Snapshot-Löschen auf qcow2/LVM ist bei uns bisher nicht hängen geblieben, aber klingt nach einem block-commit, der im QMP nie fertig wird. Schau mal mit info block-jobs im qm monitor ob da noch ein Job drinhängt (offset/len vergleichen, ob er überhaupt Fortschritt macht). Wenn ja, würd ich den nicht abschießen sondern mit block_job_complete abschließen, cancel wirft dich sonst genau in den Zustand den du jetzt hast.

Jobs laufen keine und auch sonst ist da nix was den hängenden Prozess erklären könnte.

Wenn kein Job mehr läuft und die VM stabil auf dem Snapshot-Layer schreibt, kannst du den Commit von Hand nachziehen: block-commit auf das Device aus info block, ohne top/base commitet er die ganze Chain nach unten, danach complete und der aktive Layer ist wieder die Basis-qcow.

Das testen wir mal bei einer kleinen VM.

Das geht ohne Downtime, vorher aber ein Backup falls die Kette doch inkonsistent ist. Die 0 Byte an der Original-Disk würd ich vorher klären - bei einer intakten Backing-Chain sollte da die volle virtuelle Größe sein.

Auf dem Datastore wir die volle Größe angezeigt, aber scheinbar sind die kompletten Daten in dem Snapshot qcow. Ich habe die vielen Befehle nicht dokumentiert, aber in der Basis Disk ist nur die Referenz zum Snapshot.

Welche pve-qemu-kvm und PVE-Version läuft da? Und macht Commvault die Snapshots über die PVE-API oder direkt am Storage vorbei? Falls die parallel zum vzdump/PBS-Job laufen, wär auch ein Lock-Konflikt eine heiße Spur.

Es ist noch 9.2.2 und natürlich nutzt Commvault nicht die API. Soll aber bald kommen.
PBS oder vzdump gibts nicht, wird nur mit Commvault gesichert. Auf den Clustern mit Ceph macht Commvault keine Probleme, nur auf den Clustern mit FC Storage. Aber da sind die Cluster mit AMD und Intel CPUs gleich betroffen.