Solución 1:
A veces, la documentación relevante está oculta en los archivos de configuración en lugar de, por ejemplo, en 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 que 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 activa un evento udev y, dado que la instantánea contiene un PV, lvmetad ejecuta automáticamente pvscan , y así sucesivamente.
Mirando /etc/lvm/backup/docker-volumes Pude determinar que lvmetad había ejecutado explícitamente pvscan en la instantánea usando los números mayor y menor del dispositivo, que omitieron 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 configurando el auto_activation_volume_list en /etc/lvm/lvm.conf . Le permite establecer qué grupos de volúmenes, volúmenes o etiquetas se pueden activar 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...
Solución 2:
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 propios LV. El comentario sobre el valor predeterminado es bastante completo y puede explicar mejor el uso que yo.
Solución 3:
Encontré más o menos 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 momento, si quería destruir la instantánea, primero tenía que deshabilitar temporalmente udev debido 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 mantuvo una asignación principal adicional usando el nombre del grupo de volumen antiguo, como este en la lista de árboles:
insidevgname-lvroot (252:44)
└─outsidevgname-myvm--root-p2 (252:43)
└─outsidevgname-myvm--root (252:36)
La solución fue simplemente eliminar esa asignación en particular con dmsetup remove insidevgname-lvroot . Después de eso, kpartx -d y lvremove funcionó bien.