Linux-maper urządzeń mapuje LVM PV zagnieżdżone w LV podczas robienia migawki

Co naprawdę psuje mój plan tworzenia kopii zapasowej tej maszyny ...

Mam serwer, który jest hiperwizorem KVM dla kilku maszyn wirtualnych. Jednym z nich jest Docker. Ma woluminy Docker na / dev / vdb, które są skonfigurowane jako PV LVM, na których Docker używa sterownika bezpośredniego lvm do przechowywania danych kontenera Docker. Ten dysk wirtualny to LVM LV na dysku lokalnym hosta.

Zarówno host, jak i gość uruchamiają Fedorę 21.

Widok hosta na ten wolumin jest (pokazany jest tylko odpowiedni wolumin):

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

Widok gościa na ten wolumin jest (ponownie pokazany jest tylko odpowiedni wolumin):

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

Przy wszystkich innych woluminach LVM na hoście mogę zrobić migawkę lvcreate --snapshot, wykonać kopię zapasową migawki, a następnie lvremovebez problemu. Ale z tym konkretnym tomem nie mogę lvremove, ponieważ jest w użyciu:

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

W końcu zorientowałem się, że urządzenie mapujące urządzenie na hoście w jakiś sposób zorientowało się, że ta migawka logiczna woluminu zawierała PV LVM, a następnie przystąpiła do mapowania woluminów logicznych w migawce na hoście (pokazano tylko odpowiednie woluminy):

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

Odpowiadają one dokładnie woluminom logicznym w maszynie wirtualnej:

[root@docker2 ~]# lvs
  LV          VG             Attr       LSize
  docker-data docker-volumes -wi-ao---- 39.95g
  docker-meta docker-volumes -wi-ao---- 44.00m

W szczególności nie próbuje tego zrobić z LVM LV podczas uruchamiania systemu, ale tylko wtedy, gdy robię migawkę.

Co tu się dzieje? Naprawdę nie chcę, aby mapowanie urządzeń sprawdzało zawartość migawek LVM, aby sprawdzić, czy jest w nich coś, co może mi nieprzydatnie zmapować. Czy mogę stłumić to zachowanie? Czy też muszę utworzyć migawkę za pomocą innej metody?

Czasami odpowiednia dokumentacja jest ukryta w plikach konfiguracyjnych zamiast, powiedzmy, w dokumentacji. Tak wygląda LVM.

Domyślnie LVM automatycznie podejmie próbę aktywacji woluminów na dowolnym urządzeniu fizycznym, które zostanie podłączone do systemu po uruchomieniu, o ile wszystkie PV są obecne, a lvmetad i udev (lub ostatnio systemd) są uruchomione. Kiedy tworzona jest migawka LVM, uruchamiane jest zdarzenie udev, a ponieważ migawka zawiera PV, lvmetad uruchamia się automatycznie pvscani tak dalej.

Patrząc na /etc/lvm/backup/docker-volumesto, byłem w stanie ustalić, że lvmetad wyraźnie uruchomił się pvscanna migawce, używając głównych i mniejszych liczb urządzenia, które ominęły filtry LVM, które normalnie by temu zapobiegały. Plik zawierał:

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

To zachowanie można kontrolować, ustawiając opcję auto_activation_volume_listin /etc/lvm/lvm.conf. Pozwala określić, które grupy woluminów, woluminy lub tagi mogą być aktywowane automatycznie.

Po prostu ustawiłem filtr tak, aby zawierał obie grupy woluminów dla hosta; nic innego nie będzie pasować do filtra i nie zostanie automatycznie aktywowane.

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

Woluminy LVM gościa nie są już wyświetlane na hoście, a moje kopie zapasowe są uruchomione ...

Chcesz edytować wartość „filter” w /etc/lvm/lvm.conf, aby sprawdzać tylko fizyczne urządzenia na hoście KVM; wartość domyślna akceptuje „każde urządzenie blokowe”, które obejmuje same wartości LV. Komentarz powyżej wartości domyślnej jest dość wyczerpujący i może lepiej wyjaśnić użycie niż ja.

Napotkałem mniej więcej ten sam problem w połączeniu z vgimportclone. Czasami się to nie udaje:

  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

W tym momencie, jeśli chciałem zniszczyć migawkę, najpierw musiałem tymczasowo wyłączyć z udevpowodu błędu opisanego na https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081

Ale nawet wtedy, po pozornie skutecznej dezaktywacji zagnieżdżonej grupy woluminów LVM, mapowanie partycji dla zagnieżdżonego PV, utworzone przez kpartx, jakoś pozostało w użyciu.

Wydawało się, że sztuczka polega na tym, że program mapujący urządzenia zachował dodatkowe mapowanie nadrzędne, używając starej nazwy grupy woluminów, takiej jak na liście drzew:

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

Rozwiązaniem było po prostu usunięcie tego konkretnego mapowania dmsetup remove insidevgname-lvroot. Po tym, kpartx -di lvremovepracował w porządku.