Linux-пристрій-карта відображає LVM PV, що вкладається всередину LV, коли робить знімок


13

Що насправді псує мій план створити резервну копію цієї машини ...

У мене є сервер, який представляє собою гіпервізор KVM для декількох віртуальних машин. Одним з таких є запущений Докер. У ньому є томи Docker on / dev / vdb, який встановлюється як LVM PV, на якому Docker використовує драйвер прямого lvm для зберігання даних контейнерів Docker. Цей віртуальний диск є LVM LV на локальному диску хоста.

Як хост, так і гість управляють Fedora 21.

Перегляд хосту на цей том (показано лише відповідний том):

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

Перегляд гостям на цей том (знову ж, відображається лише відповідний том):

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

З усіма іншими томами LVM на хості, я можу зробити знімок, створити lvcreate --snapshotрезервну копію знімка, а потім - lvremoveбез проблем. Але з цим конкретним обсягом я не можу, lvremoveтому що він використовується:

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

Врешті-решт я зрозумів, що пристрій-картограф на хості якимось чином зрозумів, що цей логічний знімок обсягу містить ПВ LVM, а потім перейшов до картографування логічного обсягу на знімку до хоста (показано лише відповідні томи):

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

Вони точно відповідають логічним томам всередині VM:

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

Примітно, він не намагається зробити це на LVM LV, коли система завантажується, але лише коли я роблю знімок.

Що тут відбувається? Я дійсно не хочу, щоб розробник пристроїв перевіряв вміст знімків LVM, щоб побачити, чи є всередині них щось, це може для мене безпомилково відображати. Чи можу я придушити таку поведінку? Або мені потрібно створити знімок за допомогою іншого способу?

Відповіді:


8

Іноді відповідна документація ховається далеко у файлах конфігурації, а не у, скажімо, документації. Так здається з LVM.

За замовчуванням LVM автоматично спробує активувати томи на будь-яких фізичних пристроях, які підключаються до системи після завантаження, доки всі ПВ є, а також lvmetad і udev (або нещодавно систематизовані). Коли створюється знімок LVM, подія udev знімається, а оскільки знімок містить PV, lvmetad автоматично запускається pvscanтощо.

Дивлячись на /etc/lvm/backup/docker-volumesя був в змозі визначити , що lvmetad було явно запустити pvscanна знімку за допомогою пристрою мажорних і мінорних номера, які байпасні фільтрів LVM , які зазвичай запобігають це. Файл містив:

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

Таку поведінку можна контролювати шляхом установки auto_activation_volume_listв систему /etc/lvm/lvm.conf. Це дозволяє встановити, які групи томів, томи або теги дозволяється автоматично активувати.

Отже, я просто встановив фільтр, щоб він містив обидві групи гучності для хоста; нічого іншого не буде відповідати фільтру і не активується автоматично.

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

Об'єм LVM гостя більше не з'являється на хості, і нарешті, мої резервні копії запущені ...


4

Ви хочете відредагувати значення 'filter' у /etc/lvm/lvm.conf, щоб перевірити лише фізичні пристрої хоста KVM; значення за замовчуванням приймає "кожен блок пристроїв", що включає в себе самі НВ. Коментар вище значення за замовчуванням є досить вичерпним і може зробити кращу роботу з пояснення використання, ніж я.


Зауважте, що я додав фільтр і побіг pvscan --cacheрозповісти lvmetad про новий фільтр, і pvscanтепер констатується, що PV відхиляється фільтром, але проблема зберігається.
Майкл Хемптон

Я припускаю, що ви маєте на увазі неможливість зняти знімок. На цьому етапі це може бути складно, і я можу запропонувати лише невиразні пропозиції. Якщо перезавантаження хоста KVM не викликає сумнівів (і я визнаю, що це підхід кувалди), можливо, 'lvchange -an / path / to / LV' від хоста звільнить його місце. Якщо ні, то, ймовірно, ви експериментуєте з різними операціями dmsetup, щоб спробувати обійти інструменти LVM. Хоча там стає волохатим, і мені не комфортно рекомендувати якісь конкретні операції.
Крейг Міскелл

Фільтр нічого не робить, оскільки lvmetad сканує знімок явно у відповідь на подію udev. Але рішення виявилося чимось іншим у конфігурації ...
Майкл Хемптон

2

Я зіткнувся приблизно з тією ж проблемою в поєднанні з vgimportclone. Іноді це не вдасться:

  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

У той момент, якщо я хотів знищити знімок, мені спочатку довелося тимчасово відключити udevчерез помилку, описану на https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081

Але навіть тоді, після начебто успішної дезактивації вкладеної групи томів LVM, картографування розділів для вкладеного PV kpartx, якимось чином, залишилось у використанні.

Виявилося, що картограф пристрою зберігав додаткове відображення батьків, використовуючи стару назву групи томів, як це у списку дерев:

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

Рішення полягало в тому, щоб просто видалити саме це відображення dmsetup remove insidevgname-lvroot. Після цього kpartx -dі lvremoveдобре працював.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.