Solution 1 :
Parfois, la documentation pertinente est cachée dans les fichiers de configuration plutôt que dans, disons, la documentation. Il semble donc avec LVM.
Par défaut, LVM tentera automatiquement d'activer les volumes sur tous les périphériques physiques connectés au système après le démarrage, tant que tous les PV sont présents, et lvmetad et udev (ou plus récemment systemd) sont en cours d'exécution. Lorsque l'instantané LVM est créé, un événement udev est déclenché, et puisque l'instantané contient un PV, lvmetad exécute automatiquement pvscan , et ainsi de suite.
En regardant /etc/lvm/backup/docker-volumes J'ai pu déterminer que lvmetad avait explicitement exécuté pvscan sur l'instantané en utilisant les numéros majeur et mineur du périphérique, qui ont contourné les filtres LVM qui empêcheraient normalement cela. Le fichier contenait :
description = "Created *after* executing 'pvscan --cache --activate ay 253:13'"
Ce comportement peut être contrôlé en définissant le auto_activation_volume_list en /etc/lvm/lvm.conf . Il vous permet de définir quels groupes de volumes, volumes ou balises sont autorisés à être activés automatiquement.
Donc, j'ai simplement défini le filtre pour qu'il contienne les deux groupes de volumes pour l'hôte ; tout le reste ne correspondra pas au filtre et ne sera pas automatiquement activé.
auto_activation_volume_list = [ "mandragora", "vm-volumes" ]
Les volumes LVM de l'invité n'apparaissent plus sur l'hôte, et enfin, mes sauvegardes sont en cours d'exécution...
Solution 2 :
Vous souhaitez modifier la valeur 'filter' dans /etc/lvm/lvm.conf pour inspecter uniquement les périphériques physiques sur l'hôte KVM ; la valeur par défaut accepte "chaque périphérique de bloc" qui inclut les LV eux-mêmes. Le commentaire au-dessus de la valeur par défaut est assez complet et peut mieux expliquer l'utilisation que moi.
Solution 3 :
J'ai rencontré à peu près le même problème en combinaison avec vgimportclone . Cela échouait parfois avec ceci :
WARNING: Activation disabled. No device-mapper interaction will be attempted.
Physical volume "/tmp/snap.iwOkcP9B/vgimport0" changed
1 physical volume changed / 0 physical volumes not changed
WARNING: Activation disabled. No device-mapper interaction will be attempted.
Volume group "insidevgname" successfully changed
/dev/myvm-vg: already exists in filesystem
New volume group name "myvm-vg" is invalid
Fatal: Unable to rename insidevgname to myvm-vg, error: 5
À ce stade, si je voulais détruire l'instantané, je devais d'abord désactiver temporairement udev à cause du bogue décrit sur https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081
Mais même dans ce cas, après avoir apparemment réussi à désactiver le groupe de volumes du LVM imbriqué, le mappage de partition pour le PV imbriqué, créé par kpartx , est resté en quelque sorte en usage.
L'astuce semblait être que le mappeur de périphérique gardait un mappage parent supplémentaire en utilisant l'ancien nom du groupe de volumes, comme ceci dans l'arborescence :
insidevgname-lvroot (252:44)
└─outsidevgname-myvm--root-p2 (252:43)
└─outsidevgname-myvm--root (252:36)
La solution consistait simplement à supprimer ce mappage particulier avec dmsetup remove insidevgname-lvroot . Après cela, kpartx -d et lvremove a bien fonctionné.