Il est important de comprendre les chaînes de volumes pour résoudre les problèmes de création/suppression d'instantanés. Cet article expliquera la corrélation des chaînes de volume.
Les chaînes de volume dans la base de données du moteur et l'hôte doivent être vérifiées car vous devez vérifier si l'état RÉEL des disques est le même que ce que vous voyez dans la base de données. La procédure illustrée ici concerne le stockage de blocs basé sur LVM (iSCSI et FiberChannel). Pour NFS, c'est beaucoup plus simple, recherchez simplement les fichiers avec l'identifiant de l'image comme nom. Lorsque nous créons un instantané, RHV « gèle » le disque de base et crée une copie sur la couche d'écriture (COW) au-dessus pour stocker les modifications. La couche COW est implémentée sous la forme d'un instantané qcow, qui stocke une référence à l'image de base contenant le disque d'origine (ou la couche précédente).
1. Vérifiez à partir de la base de données du moteur :
– Le « premier » instantané pour les VM est « VM active » dans RHV. "Active VM" n'est pas un instantané réel, mais affiche simplement "l'état actuel" sous forme d'instantané. C'est le disque principal (parentid zéro). Par exemple :
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)
– Si vous créez un instantané, le vrai premier instantané sera créé. Ce premier instantané est un instantané COW qui utilise le disque précédent comme image de base. L'ID parent est zéro. Une fois le premier instantané pris, l'ID parent "Active VM" devient l'image_guid du premier instantané.
Exemple :le nom du premier instantané est volumechain1. À partir de la sortie DB ci-dessous, vous pouvez voir la relation image_guid et parentid :
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)
Exemple pour le deuxième (volumechain2)/troisième (volumechain3) instantanés. Vous pouvez voir que le parentid du deuxième instantané est le premier snapshot volumeid et que le parentid du troisième snapshot est le deuxième snapshot volume_id.
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. Vérifiez depuis l'hôte :
– Vérifiez les infos domblk :
# 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
– Vérifier les balises LV :le backend LVM stocke les données dans des volumes logiques (LV). RHV balise tous les LV avec l'ID de disque qui utilise ce LV. À partir des balises LV de commande ci-dessous, vous pouvez voir les chaînes de volume.
# 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
– Vérifiez les images qemu. Par exemple :
# 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
Chaînes de volume de vidage. Par exemple :
# 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