Início / server / Perguntas / 678642
Accepted
Michael Hampton
Asked: 2015-03-27 21:22:12 +0800 CST

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

  • 772

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 tem seus volumes do Docker em /dev/vdb, que é configurado como um LVM PV, no qual o Docker usa seu driver direct-lvm para armazenar dados do contêiner do Docker. Este disco virtual é um LVM LV no disco local do host.

Tanto o host quanto o convidado executam 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 visã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 LVM no host, posso tirar um instantâneo com lvcreate --snapshot, fazer backup do instantâneo e, em seguida lvremove, sem problemas. Mas com este volume específico, 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, descobri que o mapeador de dispositivos no host havia descoberto de alguma forma que esse instantâneo de volume lógico continha um LVM PV e, em seguida, mapeei os volumes lógicos dentro do instantâneo 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)

Estes 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 tiro um instantâneo.

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á algo dentro deles que possa mapear de forma inútil para mim. Posso suprimir esse comportamento? Ou preciso criar o instantâneo por meio de algum outro método?

linux

3 respostas

  1. Best Answer

    Às vezes, a documentação relevante está escondida em arquivos de configuração em vez de, digamos, na documentação. Assim parece com LVM.

    Por padrão, o LVM tentará automaticamente ativar volumes em quaisquer dispositivos físicos que sejam conectados 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 LVM é criado, um evento udev é acionado e, como o instantâneo contém um PV, o lvmetad é executado automaticamente pvscane assim por diante.

    Ao olhar, /etc/lvm/backup/docker-volumespude determinar que o lvmetad foi executado explicitamente pvscanno instantâneo usando os números principais e secundários do dispositivo, que ignoraram 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 definindo o auto_activation_volume_listin /etc/lvm/lvm.conf. Ele permite que você defina quais grupos de volumes, volumes ou tags podem ser ativados automaticamente.

    Então, eu simplesmente defino o filtro para conter ambos os grupos de volumes para o host; qualquer outra coisa não corresponderá ao filtro e não será ativado 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 sendo executados...

    • 10

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

    • 5

  3. 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 teria que desativar temporariamente udevpor causa do bug descrito em https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081

    Mas mesmo assim, após aparentemente desativar com sucesso o grupo de volumes do LVM aninhado, o mapeamento de 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 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 -de lvremovefuncionou bem.

    • 2

relate perguntas