Der Linux-Geräte-Mapper ordnet beim Erstellen eines Snapshots in LV verschachtelte LVM-PV zu

Lösung 1:

Manchmal ist die relevante Dokumentation in Konfigurationsdateien versteckt und nicht etwa in der Dokumentation. So scheint es bei LVM.

Standardmäßig versucht LVM automatisch, Volumes auf allen physischen Geräten zu aktivieren, die nach dem Booten mit dem System verbunden werden, solange alle PVs vorhanden sind, und lvmetad und udev (oder neuerdings systemd) laufen. Wenn der LVM-Snapshot erstellt wird, wird ein udev-Ereignis ausgelöst, und da der Snapshot ein PV enthält, führt lvmetad automatisch pvscan aus , und so weiter.

Durch einen Blick auf /etc/lvm/backup/docker-volumes Ich konnte feststellen, dass lvmetad explizit pvscan ausgeführt hatte auf dem Snapshot unter Verwendung der Major- und Minor-Nummern des Geräts, wodurch LVM-Filter umgangen werden, die dies normalerweise verhindern würden. Die Datei enthielt:

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

Dieses Verhalten kann durch Setzen des auto_activation_volume_list gesteuert werden in /etc/lvm/lvm.conf . Hier können Sie festlegen, welche Volume-Gruppen, Volumes oder Tags automatisch aktiviert werden dürfen.

Also stelle ich den Filter einfach so ein, dass er beide Volumengruppen für den Host enthält; alles andere passt nicht zum Filter und wird nicht automatisch aktiviert.

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

Die LVM-Volumes des Gasts erscheinen nicht mehr auf dem Host, und endlich laufen meine Backups ...

Lösung 2:

Sie möchten den Wert „filter“ in /etc/lvm/lvm.conf bearbeiten, um nur die physischen Geräte auf dem KVM-Host zu untersuchen; Der Standardwert akzeptiert „jedes Blockgerät“, einschließlich der LVs selbst. Der Kommentar über dem Standardwert ist ziemlich umfassend und kann die Verwendung besser erklären als ich.

Lösung 3:

Ich bin ungefähr auf das gleiche Problem in Kombination mit vgimportclone gestoßen . Es würde manchmal damit fehlschlagen:

  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

Wenn ich zu diesem Zeitpunkt den Snapshot zerstören wollte, musste ich zuerst udev vorübergehend deaktivieren aufgrund des unter https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081

beschriebenen Fehlers

Aber selbst dann, nachdem die Volumengruppe des verschachtelten LVM anscheinend erfolgreich deaktiviert wurde, wurde die Partitionszuordnung für das verschachtelte PV von kpartx erstellt , blieb irgendwie in Gebrauch.

Der Trick schien darin zu bestehen, dass der Geräte-Mapper eine zusätzliche übergeordnete Zuordnung unter Verwendung des alten Datenträgergruppennamens beibehielt, wie hier in der Baumliste:

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

Die Lösung bestand darin, diese bestimmte Zuordnung einfach mit dmsetup remove insidevgname-lvroot zu entfernen . Danach kpartx -d und lvremove hat gut funktioniert.