O mapeador de dispositivos Linux mapeia o PV do LVM aninhado dentro do LV ao tirar uma captura instantânea

O que está realmente atrapalhando meu plano de fazer backup desta máquina ...

Eu tenho um servidor que é um hypervisor KVM para várias máquinas virtuais. Um deles está executando o Docker. Ele possui seus volumes do Docker em / dev / vdb, que é configurado como um PV LVM, no qual o Docker usa seu driver de lvm direto para armazenar dados do contêiner do Docker. Este disco virtual é um LVM LV no disco local do host.

O host e o convidado executam o Fedora 21.

A visualização deste host pelo volume é (apenas o volume relevante é mostrado):

[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)

A visualização deste hóspede por este volume é (novamente, apenas o volume relevante é mostrado):

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

Com todos os outros volumes LVM no host, posso tirar um instantâneo lvcreate --snapshot, fazer backup do instantâneo e, em seguida lvremove, sem problemas. Mas com este volume em particular, não posso lvremoveporque está em uso:

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

Eventualmente, eu descobri que o mapeador de dispositivos no host de alguma forma descobriu que esse instantâneo de volume lógico continha um PV LVM e, em seguida, procedi ao mapeamento dos volumes lógicos no instantâneo para o host (apenas os volumes relevantes são mostrados):

[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)

Eles correspondem exatamente aos volumes lógicos dentro da VM:

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

Notavelmente, ele não tenta fazer isso com o LVM LV quando o sistema está inicializando, mas apenas quando tiro um instantâneo.

O que está acontecendo aqui? Eu realmente não quero que o mapeador de dispositivos inspecione o conteúdo dos snapshots do LVM para ver se há algo nele que possa ser mapeado sem ajuda para mim. Posso suprimir esse comportamento? Ou preciso criar o instantâneo por meio de outro método?

Às vezes, a documentação relevante fica oculta nos arquivos de configuração, e não na documentação, por exemplo. Assim parece com o LVM.

Por padrão, o LVM tentará ativar automaticamente os volumes em qualquer dispositivo físico que seja conectado ao sistema após a inicialização, desde que todos os PVs estejam presentes, e lvmetad e udev (ou, mais recentemente, systemd) estejam em execução. Quando o instantâneo do LVM é criado, um evento udev é acionado e, como o instantâneo contém um PV, o lvmetad é executado automaticamente pvscane assim por diante.

Ao analisar, /etc/lvm/backup/docker-volumespude determinar que o lvmetad havia sido executado explicitamente pvscanno instantâneo usando o número principal e o menor do dispositivo, que ignoravam os filtros LVM que normalmente evitariam isso. O arquivo continha:

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

Esse comportamento pode ser controlado definindo o auto_activation_volume_listin /etc/lvm/lvm.conf. Permite definir quais grupos de volumes, volumes ou tags podem ser ativados automaticamente.

Portanto, simplesmente configurei o filtro para conter os dois grupos de volumes do host; qualquer outra coisa não corresponderá ao filtro e não será ativada automaticamente.

auto_activation_volume_list = [ "mandragora", "vm-volumes" ]

Os volumes LVM do convidado não estão mais aparecendo no host e, finalmente, meus backups estão em execução ...

Você deseja editar o valor do 'filtro' em /etc/lvm/lvm.conf para inspecionar apenas os dispositivos físicos no host KVM; o valor padrão aceita 'todo dispositivo de bloco', que inclui os próprios LVs. O comentário acima do valor padrão é bastante abrangente e pode explicar melhor o uso do que eu.

Eu encontrei aproximadamente o mesmo problema em combinação com vgimportclone. Às vezes falhava com isso:

  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

Nesse ponto, se eu quisesse destruir o instantâneo, primeiro tive que desativar temporariamente udevdevido ao erro descrito em https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081

Mas mesmo assim, depois de desativar com êxito o grupo de volumes do LVM aninhado, o mapeamento da partição para o PV aninhado, criado por kpartx, de alguma forma permaneceu em uso.

O truque parecia ser que o mapeador de dispositivos mantinha um mapeamento pai extra usando o nome do grupo de volumes antigo, como este na lista de árvores:

insidevgname-lvroot (252:44)
 └─outsidevgname-myvm--root-p2 (252:43)
    └─outsidevgname-myvm--root (252:36)

A solução foi simplesmente remover esse mapeamento específico dmsetup remove insidevgname-lvroot. Depois disso, kpartx -de lvremovefuncionou bem.