Le mappeur de périphériques Linux mappe LVM PV imbriqué dans LV lors de la prise d'un instantané

Ce qui dérange vraiment mon plan de sauvegarde de cette machine ...

J'ai un serveur qui est un hyperviseur KVM pour plusieurs machines virtuelles. L'un d'eux exécute Docker. Il a ses volumes Docker sur / dev / vdb, qui est configuré en tant que PV LVM, sur lequel Docker utilise son pilote direct-lvm pour stocker les données du conteneur Docker. Ce disque virtuel est un LVM LV sur le disque local de l'hôte.

L'hôte et l'invité exécutent Fedora 21.

La vue de l'hôte sur ce volume est (seul le volume pertinent est affiché):

[root@host ~]# lvs
  LV                           VG         Attr       LSize
  docker2.example.com-volumes vm-volumes -wi-ao---- 40.00g
[root@host ~]# dmsetup ls --tree
vm--volumes-docker2.example.com--volumes (253:10)
 └─ (9:125)

La vue de l'invité sur ce volume est (encore une fois, seul le volume pertinent est affiché):

[root@docker2 ~]# pvs
  PV         VG             Fmt  Attr PSize  PFree
  /dev/vdb   docker-volumes lvm2 a--  40.00g    0 

Avec tous les autres volumes LVM sur l'hôte, je peux prendre un instantané avec lvcreate --snapshot, sauvegarder l'instantané et ensuite lvremovesans problème. Mais avec ce volume particulier, je ne peux pas lvremovecar il est utilisé:

[root@host ~]# lvremove /dev/vm-volumes/snap-docker2.example.com-volumes 
  Logical volume vm-volumes/snap-docker2.example.com-volumes is used by another device.

Finalement, j'ai compris que le mappeur de périphériques sur l'hôte avait en quelque sorte compris que cet instantané de volume logique contenait un PV LVM, puis j'ai procédé à la mappage des volumes logiques dans l'instantané à l'hôte (seuls les volumes pertinents sont affichés):

[root@host ~]# dmsetup ls --tree
vm--volumes-docker2.example.com--volumes (253:10)
 └─vm--volumes-docker2.example.com--volumes-real (253:14)
    └─ (9:125)
docker--volumes-docker--data (253:18)
 └─vm--volumes-snap--docker2.example.com--volumes (253:16)
    ├─vm--volumes-snap--docker2.example.com--volumes-cow (253:15)
    │  └─ (9:125)
    └─vm--volumes-docker2.example.com--volumes-real (253:14)
       └─ (9:125)
docker--volumes-docker--meta (253:17)
 └─vm--volumes-snap--docker2.example.com--volumes (253:16)
    ├─vm--volumes-snap--docker2.example.com--volumes-cow (253:15)
    │  └─ (9:125)
    └─vm--volumes-docker2.example.com--volumes-real (253:14)
       └─ (9:125)

Ceux-ci correspondent exactement aux volumes logiques à l'intérieur de la VM:

[root@docker2 ~]# lvs
  LV          VG             Attr       LSize
  docker-data docker-volumes -wi-ao---- 39.95g
  docker-meta docker-volumes -wi-ao---- 44.00m

Notamment, il n'essaie pas de faire cela au LVM LV lorsque le système démarre, mais uniquement lorsque je prends un instantané.

Qu'est-ce qui se passe ici? Je ne veux vraiment pas que le mappeur de périphériques inspecte le contenu des instantanés LVM pour voir s'il y a quelque chose en eux qu'il peut mapper sans aide pour moi. Puis-je supprimer ce comportement? Ou dois-je créer l'instantané via une autre méthode?

Parfois, la documentation pertinente est cachée dans les fichiers de configuration plutôt que, disons, dans la documentation. Il semble donc avec LVM.

Par défaut, LVM tentera automatiquement d'activer les volumes sur tous les périphériques physiques qui se connectent au système après le démarrage, tant que tous les PV sont présents et que 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, comme l'instantané contient un PV, lvmetad s'exécute automatiquement pvscan, etc.

En regardant, /etc/lvm/backup/docker-volumesj'ai pu déterminer que lvmetad s'était explicitement exécuté pvscansur l'instantané en utilisant les nombres majeurs et mineurs de l'appareil, qui contournaient les filtres LVM qui normalement empêcheraient cela. Le dossier contenait:

description = "Created *after* executing 'pvscan --cache --activate ay 253:13'"

Ce comportement peut être contrôlé en réglant la auto_activation_volume_listdans /etc/lvm/lvm.conf. Il vous permet de définir quels groupes de volumes, volumes ou balises peuvent être activés automatiquement.

Ainsi, j'ai simplement défini le filtre pour contenir les deux groupes de volumes pour l'hôte; rien d'autre ne correspondra au filtre et ne sera pas activé automatiquement.

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 ...

Vous souhaitez modifier la valeur du «filtre» 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.

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 en udevraison du bogue décrit à https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081

Mais même alors, 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 utilisé.

L'astuce semble être que le mappeur de périphériques a conservé un mappage parent supplémentaire en utilisant l'ancien nom du groupe de volumes, comme ceci dans la liste arborescente:

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 -det lvremovea bien fonctionné.