Картопостроитель устройства Linux отображает PV LVM, вложенный в LV при взятии снимка

Который действительно смешивает с моим планом резервировать эту машину...

У меня есть сервер, который является гипервизором KVM к нескольким виртуальным машинам. Один из них выполняет Докера. Это имеет свои объемы Докера на/dev/vdb, который настраивается как PV LVM, на котором Докер использует его прямой-lvm драйвер, чтобы хранить данные контейнера Докера. Этим виртуальным диском является LV LVM на локальном диске хоста.

Оба хоста и гость выполняют 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.

В конечном счете я выяснил, что картопостроитель устройства на хосте так или иначе выяснил, что этот снимок логического тома содержал PV 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

В частности, это не пытается сделать это к LV LVM, когда система загружается, но только когда я беру снимок.

Что продолжается здесь? Я действительно не хочу картопостроитель устройства, осматривая содержание снимков LVM, чтобы видеть, существует ли что-нибудь в них, он может бесполезно отобразиться для меня. Я могу подавить это поведение? Или я должен создать снимок с помощью некоторого другого метода?

12
задан 27 March 2015 в 07:22
3 ответа

Иногда соответствующая документация скрыта в файлах конфигурации, а не, скажем, в документации. Так же и с LVM.

По умолчанию LVM будет автоматически пытаться активировать тома на любых физических устройствах, которые подключаются к системе после загрузки, пока присутствуют все PV, и lvmetad и udev (или совсем недавно systemd) запущены. Когда создается снимок LVM, запускается событие udev, и, поскольку снимок содержит PV, lvmetad автоматически запускает pvscan и т. Д.

Посмотрев на / etc / lvm / backup / docker-volume Мне удалось определить, что 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 гостя больше не отображаются на хосте, и, наконец, мои резервные копии выполняются ...

7
ответ дан 2 December 2019 в 21:38

Вы хотите отредактировать значение 'filter' в /etc/lvm/lvm.conf, чтобы проверять только физические устройства на хосте KVM; значение по умолчанию принимает «каждое блочное устройство», которое включает сами LV. Комментарий над значением по умолчанию является довольно подробным и может лучше объяснить использование, чем я.

3
ответ дан 2 December 2019 в 21:38

Я столкнулся примерно с такой же проблемой в комбинации с 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 insideevgname-lvroot. После этого kpartx -d и lvremove работали нормально.

.
1
ответ дан 2 December 2019 в 21:38

Теги

Похожие вопросы