Soluzione 1:
A volte la documentazione pertinente è nascosta nei file di configurazione piuttosto che, ad esempio, nella documentazione. Così sembra con LVM.
Per impostazione predefinita, LVM tenterà automaticamente di attivare i volumi su tutti i dispositivi fisici che vengono connessi al sistema dopo l'avvio, purché siano presenti tutti i PV, e lvmetad e udev (o più recentemente systemd) sono in esecuzione. Quando viene creata l'istantanea LVM, viene attivato un evento udev e poiché l'istantanea contiene un PV, lvmetad esegue automaticamente pvscan e così via.
Osservando /etc/lvm/backup/docker-volumes Sono stato in grado di determinare che lvmetad aveva eseguito esplicitamente pvscan sullo snapshot utilizzando i numeri maggiore e minore del dispositivo, che aggirano i filtri LVM che normalmente lo impedirebbero. Il file conteneva:
description = "Created *after* executing 'pvscan --cache --activate ay 253:13'"
Questo comportamento può essere controllato impostando auto_activation_volume_list in /etc/lvm/lvm.conf . Consente di impostare quali gruppi di volumi, volumi o tag possono essere attivati automaticamente.
Quindi, ho semplicemente impostato il filtro per contenere entrambi i gruppi di volumi per l'host; qualsiasi altra cosa non corrisponderà al filtro e non verrà attivata automaticamente.
auto_activation_volume_list = [ "mandragora", "vm-volumes" ]
I volumi LVM del guest non vengono più visualizzati sull'host e, infine, i miei backup sono in esecuzione...
Soluzione 2:
Si desidera modificare il valore 'filter' in /etc/lvm/lvm.conf per ispezionare solo i dispositivi fisici sull'host KVM; il valore predefinito accetta "ogni dispositivo a blocchi" che include gli stessi LV. Il commento sopra il valore predefinito è abbastanza completo e può spiegare l'utilizzo meglio di me.
Soluzione 3:
Ho riscontrato più o meno lo stesso problema in combinazione con vgimportclone . A volte falliva con questo:
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
A quel punto, se volevo distruggere lo snapshot, dovevo prima disabilitare temporaneamente udev a causa del bug descritto su https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081
Ma anche allora, dopo aver apparentemente disattivato con successo il gruppo di volumi di LVM nidificato, la mappatura delle partizioni per il PV nidificato, creata da kpartx , in qualche modo è rimasto in uso.
Il trucco sembrava essere che il mapper del dispositivo manteneva una mappatura principale aggiuntiva utilizzando il vecchio nome del gruppo di volumi, come questo nell'elenco ad albero:
insidevgname-lvroot (252:44)
└─outsidevgname-myvm--root-p2 (252:43)
└─outsidevgname-myvm--root (252:36)
La soluzione era rimuovere semplicemente quella particolare mappatura con dmsetup remove insidevgname-lvroot . Dopodiché, kpartx -d e lvremove ha funzionato bene.