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

13

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?

Michael Hampton
fuente

Respuestas:

8

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

Michael Hampton
fuente
4

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.

Craig Miskell
fuente
Tenga en cuenta que agregué el filtro y corrí pvscan --cachepara informarle a lvmetad sobre el nuevo filtro, y pvscanahora declara que un filtro rechaza el PV, pero el problema persiste.
Michael Hampton
Supongo que te refieres a la incapacidad de eliminar la instantánea. En esta etapa, puede ser complicado, y solo puedo ofrecer sugerencias vagas. Si reiniciar el host KVM está fuera de discusión (y reconozco que es un enfoque de mazo), entonces tal vez 'lvchange -an / path / to / LV' del host liberará su retención. Si no es así, entonces probablemente esté experimentando con varias operaciones de dmsetup para intentar omitir las herramientas LVM. Sin embargo, se pone peludo allí, y no me siento cómodo recomendando operaciones específicas.
Craig Miskell
El filtro no hace nada porque lvmetad está escaneando la instantánea explícitamente en respuesta a un evento udev. Sin embargo, la solución resultó ser otra cosa en la configuración ...
Michael Hampton
2

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.

Josip Rodin
fuente