O mapeador de dispositivos do Linux mapeia o LVM PV aninhado dentro do LV ao tirar um instantâneo

Question

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

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

Tanto o host quanto o guest rodam o Fedora 21.

A visão do host deste volume é (somente 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 do convidado deste 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 de LVM no host, posso tirar um instantâneo com lvcreate --snapshot , fazer backup do instantâneo e, em seguida, lvremove sem nenhum problema. Mas com esse volume específico, não posso lvremove porque 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, descobri que o mapeador de dispositivo no host tinha de alguma forma descoberto que esse volume lógico snapshot continha um PV do LVM e, em seguida, começou a mapear os volumes lógicos dentro do snapshot para o host ( somente 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)

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 eu faço um snapshot.

O que está acontecendo aqui? Eu realmente não quero que o mapeador de dispositivos inspecione o conteúdo dos instantâneos do LVM para ver se há alguma coisa dentro deles que possa mapear de forma inútil para mim. Posso suprimir esse comportamento? Ou preciso criar o instantâneo por meio de outro método?

    

Answer 1

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

Por padrão, o LVM tentará automaticamente ativar volumes em quaisquer dispositivos físicos que se conectarem ao sistema após a inicialização, desde que todos os PVs estejam presentes, e lvmetad e udev (ou mais recentemente systemd) estão em execução. Quando o instantâneo do LVM é criado, um evento do udev é acionado e, como o instantâneo contém um PV, o lvmetad executa automaticamente pvscan e assim por diante.

Olhando para /etc/lvm/backup/docker-volumes , consegui determinar que lvmetad executou explicitamente pvscan no instantâneo usando os números maior e menor do dispositivo, que ignoravam os filtros LVM que normalmente impediriam isso. O arquivo continha:

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

Esse comportamento pode ser controlado pela configuração de auto_activation_volume_list in /etc/lvm/lvm.conf . Ele permite que você defina quais grupos de volumes, volumes ou tags podem ser ativados automaticamente.

Então, simplesmente configurei o filtro para conter os dois grupos de volume para o 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 ...

    

Answer 2

Você deseja editar o valor de 'filtro' em /etc/lvm/lvm.conf para inspecionar apenas os dispositivos físicos no host KVM; o valor padrão aceita 'every block device', 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.

    

Answer 3

Encontrei mais ou menos o mesmo problema em combinação com vgimportclone . Às vezes, falharia 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 snapshot, primeiro tive que desabilitar temporariamente udev por causa do bug descrito em link

Mas mesmo assim, depois de aparentemente desativar com sucesso a desativação do grupo de volumes do LVM aninhado, o mapeamento de partições 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 antigo nome do grupo de volumes, 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 com dmsetup remove insidevgname-lvroot . Depois disso, kpartx -d e lvremove funcionaram bem.