El mapeador de dispositivos Linux mapea el PV LVM anidado dentro del LV cuando toma una instantánea

Lo que realmente está jugando con mi plan para hacer una copia de seguridad de esta máquina ...

Tengo un servidor que es un hipervisor KVM para varias máquinas virtuales. Uno de ellos es ejecutar Docker. Tiene sus volúmenes Docker en / dev / vdb, que se configura como un PV LVM, en el que Docker usa su controlador directo-lvm para almacenar los datos del contenedor Docker. Este disco virtual es un LVM LV en el disco local del host.

Tanto el host como el invitado ejecutan Fedora 21.

La vista del host de este volumen es (solo se muestra el volumen relevante):

[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 vista del invitado de este volumen es (nuevamente, solo se muestra el volumen relevante):

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

Con todos los demás volúmenes LVM en el host, puedo tomar una instantánea lvcreate --snapshot, hacer una copia de seguridad de la instantánea y luego lvremovesin problemas. Pero con este volumen en particular, no puedo lvremoveporque está en 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.

Finalmente, descubrí que el mapeador de dispositivos en el host había descubierto de alguna manera que esta instantánea de volumen lógico contenía un PV LVM, y luego procedí a asignar los volúmenes lógicos dentro de la instantánea al host (solo se muestran los volúmenes relevantes):

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

Estos corresponden exactamente a los volúmenes lógicos dentro 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

Notablemente, no intenta hacer esto al LVM LV cuando el sistema se está iniciando, sino solo cuando tomo una instantánea.

¿Que esta pasando aqui? Realmente no quiero que el mapeador de dispositivos inspeccione el contenido de las instantáneas de LVM para ver si hay algo dentro de ellas que pueda asignarme de manera inútil. ¿Puedo suprimir este comportamiento? ¿O necesito crear la instantánea a través de algún otro método?

A veces, la documentación relevante está oculta en los archivos de configuración en lugar de, por ejemplo, la documentación. Así parece con LVM.

De forma predeterminada, LVM intentará activar automáticamente los volúmenes en cualquier dispositivo físico que se conecte al sistema después del arranque, siempre y cuando todos los PV estén presentes, y lvmetad y udev (o más recientemente systemd) se estén ejecutando. Cuando se crea la instantánea LVM, se desencadena un evento udev y, dado que la instantánea contiene un PV, lvmetad se ejecuta automáticamente pvscan, y así sucesivamente.

Al observar /etc/lvm/backup/docker-volumes, pude determinar que lvmetad se había ejecutado explícitamente pvscanen la instantánea utilizando los números mayor y menor del dispositivo, lo que omitió los filtros LVM que normalmente evitarían esto. El archivo contenía:

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

Este comportamiento se puede controlar mediante el establecimiento de la auto_activation_volume_listen /etc/lvm/lvm.conf. Le permite establecer qué grupos de volúmenes, volúmenes o etiquetas pueden activarse automáticamente.

Entonces, simplemente configuro el filtro para que contenga ambos grupos de volúmenes para el host; cualquier otra cosa no coincidirá con el filtro y no se activará automáticamente.

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

Los volúmenes LVM del invitado ya no aparecen en el host y, finalmente, mis copias de seguridad se están ejecutando ...

Desea editar el valor de 'filtro' en /etc/lvm/lvm.conf para inspeccionar solo los dispositivos físicos en el host KVM; el valor predeterminado acepta "todos los dispositivos de bloque", que incluye los mismos LV. El comentario sobre el valor predeterminado es bastante completo y puede explicar mejor el uso que yo.

Encontré aproximadamente el mismo problema en combinación con vgimportclone. A veces fallaba con esto:

  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

En ese punto, si quería destruir la instantánea, primero tenía que desactivarla temporalmente udevdebido al error descrito en https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081

Pero incluso entonces, después de desactivar aparentemente con éxito el grupo de volúmenes del LVM anidado, el mapeo de partición para el PV anidado, creado por kpartx, de alguna manera permaneció en uso.

El truco parecía ser que el mapeador de dispositivos mantenía una asignación principal adicional usando el antiguo nombre del grupo de volúmenes, como este en la lista de árbol:

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

La solución fue simplemente eliminar esa asignación particular con dmsetup remove insidevgname-lvroot. Después de eso, kpartx -dy lvremovefuncionó bien.