Es ist wichtig, die Volume-Ketten zu verstehen, um Probleme beim Erstellen/Löschen von Snapshots zu beheben. Dieser Beitrag erklärt die Korrelation von Volumenketten.
Volume-Ketten sowohl in der Engine-Datenbank als auch im Host müssen überprüft werden, da Sie überprüfen müssen, ob der REAL-Status der Festplatten mit dem übereinstimmt, den Sie in der Datenbank sehen. Das hier gezeigte Verfahren gilt für LVM-basierte Blockspeicher (iSCSI und FibreChannel). Für NFS ist es viel einfacher, suchen Sie einfach nach Dateien mit der Bild-ID als Namen. Wenn wir einen Snapshot erstellen, „friert“ RHV die Basisfestplatte ein und erstellt eine Kopie auf der Schreibebene (COW) darüber, um die Änderungen zu speichern. Die COW-Schicht wird als qcow-Snapshot implementiert, der einen Verweis auf das Basis-Image speichert, das die Originalfestplatte (oder vorherige Schicht) enthält.
1. Aus Engine-Datenbank prüfen:
– Der „erste“ Snapshot für VMs ist „Active VM“ in RHV. „Active VM“ ist kein eigentlicher Snapshot, sondern zeigt nur den „aktuellen Status“ als Snapshot an. Es ist die Hauptfestplatte (Eltern-ID Null). Zum Beispiel:
vm_name | snapshot_name | snapshot_status | image_guid | image_group_id | parentid | imagestatus ------------+----------------------+-----------------+--------------------------------------+--------------------------------------+--------------------------------------+------------- TestVM | Active VM | OK | 4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 00000000-0000-0000-0000-000000000000 | 1 (1 row)
– Wenn Sie einen Snapshot erstellen, wird der echte erste Snapshot erstellt. Dieser erste Snapshot ist ein COW-Snapshot, der die vorherige Festplatte als Basisimage verwendet. Die Eltern-ID ist null. Nachdem der erste Snapshot erstellt wurde, wird die übergeordnete ID „Active VM“ zur image_guid des ersten Snapshots.
Beispiel :Der erste Snapshot-Name ist volumechain1. Aus der folgenden DB-Ausgabe können Sie die Beziehung zwischen image_guid und parentid sehen:
vm_name | snapshot_name | snapshot_status | image_guid | image_group_id | parentid | imagestatus ------------+---------------+-----------------+--------------------------------------+--------------------------------------+--------------------------------------+------------- TestVM | Active VM | OK | 3fdf455e-52e6-48da-81f5-475cad796d21 | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 | 1 TestVM | volumechain1 | OK | 4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 00000000-0000-0000-0000-000000000000 | 1 (2 rows)
Beispiel für den zweiten (Volumenkette2)/dritten (Volumenkette3) Snapshot. Sie können sehen, dass die parentid des zweiten Snapshots die volumeid des ersten Snapshots und die parentid des dritten Snapshots die volume_id des zweiten Snapshots ist.
vm_name | snapshot_name | snapshot_status | image_guid | image_group_id | parentid | imagestatus ------------+---------------+-----------------+--------------------------------------+--------------------------------------+--------------------------------------+------------- TestVM | Active VM | OK | 043dfd54-30d2-4437-9cba-2eded92136b6 | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 3fdf455e-52e6-48da-81f5-475cad796d21 | 1 TestVM | volumechain1 | OK | 4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 00000000-0000-0000-0000-000000000000 | 1 TestVM | volumechain2 | OK | 3fdf455e-52e6-48da-81f5-475cad796d21 | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 | 1 (3 rows)
vm_name | snapshot_name | snapshot_status | image_guid | image_group_id | parentid | imagestatus ------------+---------------+-----------------+--------------------------------------+--------------------------------------+--------------------------------------+------------- TestVM | Active VM | OK | c9a717e4-bc90-4ef5-900d-777bf01b43bf | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 043dfd54-30d2-4437-9cba-2eded92136b6 | 1 TestVM | volumechain1 | OK | 4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 00000000-0000-0000-0000-000000000000 | 1 TestVM | volumechain2 | OK | 3fdf455e-52e6-48da-81f5-475cad796d21 | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 | 1 TestVM | volumenchain3 | OK | 043dfd54-30d2-4437-9cba-2eded92136b6 | 9f13d2e3-eed5-4af2-936c-358bc4948608 | 3fdf455e-52e6-48da-81f5-475cad796d21 | 1 (4 rows)
2. Vom Host prüfen:
– Überprüfen Sie die Domblk-Informationen:
# virsh -r domblklist TestVM Target Source --------------------------------------------------------------------------------------------------------------------------------------------------------------- hdc - sda /rhev/data-center/mnt/blockSD/c95e9f3e-79cb-47ab-9825-8093ee12e42b/images/9f13d2e3-eed5-4af2-936c-358bc4948608/c9a717e4-bc90-4ef5-900d-777bf01b43bf
– LV-Tags prüfen:Das LVM-Backend speichert die Daten in Logical Volumes (LV). RHV kennzeichnet alle LV mit der Festplatten-ID, die dieses LV verwendet. Anhand der folgenden Befehls-LV-Tags können Sie die Volumenketten sehen.
# lvs -o +tags|grep 9f13d2e3-eed5-4af2-936c-358bc4948608 043dfd54-30d2-4437-9cba-2eded92136b6 c95e9f3e-79cb-47ab-9825-8093ee12e42b -wi-ao---- 1.00g IU_9f13d2e3-eed5-4af2-936c-358bc4948608,MD_8,PU_3fdf455e-52e6-48da-81f5-475cad796d21 >>>> third snapshot 3fdf455e-52e6-48da-81f5-475cad796d21 c95e9f3e-79cb-47ab-9825-8093ee12e42b -wi-ao---- 1.00g IU_9f13d2e3-eed5-4af2-936c-358bc4948608,MD_6,PU_4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 >>>>> second snapshot 4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 c95e9f3e-79cb-47ab-9825-8093ee12e42b -wi-ao---- 48.00g IU_9f13d2e3-eed5-4af2-936c-358bc4948608,MD_3,PU_00000000-0000-0000-0000-000000000000 >>>>> first snapshot c9a717e4-bc90-4ef5-900d-777bf01b43bf c95e9f3e-79cb-47ab-9825-8093ee12e42b -wi-ao---- 1.00g IU_9f13d2e3-eed5-4af2-936c-358bc4948608,MD_11,PU_043dfd54-30d2-4437-9cba-2eded92136b6 >>>>> Active VM
– Überprüfen Sie die qemu-Images. Zum Beispiel:
# qemu-img info /dev/c95e9f3e-79cb-47ab-9825-8093ee12e42b/4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 image: /dev/c95e9f3e-79cb-47ab-9825-8093ee12e42b/4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 file format: raw virtual size: 48G (51539607552 bytes) >>>>>>>>>>> disk size: 0
Volumenketten ausgeben. Zum Beispiel:
# vdsm-tool dump-volume-chains c95e9f3e-79cb-47ab-9825-8093ee12e42b |grep -A14 9f13d2e3-eed5-4af2-936c-358bc4948608 image: 9f13d2e3-eed5-4af2-936c-358bc4948608 - 4ccf601e-ec11-4c10-be8c-3b1a6e53aa51 >>>>this is the first snapshot volume_id status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type: PREALLOCATED, capacity: 51539607552, truesize: 51539607552 - 3fdf455e-52e6-48da-81f5-475cad796d21 >>>>this is the second snapshot volume_id status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 51539607552, truesize: 1073741824 - 043dfd54-30d2-4437-9cba-2eded92136b6 >>>>this is the third snapshot volume_id status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 51539607552, truesize: 1073741824 - c9a717e4-bc90-4ef5-900d-777bf01b43bf >>>>this is Active VM Leaf volume_id status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 51539607552, truesize: 1073741824