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

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

У меня есть сервер, который является гипервизором KVM для нескольких виртуальных машин. Одним из них является запуск Docker. Он имеет свои тома Docker в /dev/vdb, который настроен как LVM PV, на котором Docker использует свой драйвер direct-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.

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

Они точно соответствуют логическим томам внутри виртуальной машины:

[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, чтобы увидеть, есть ли в них что-то, что может бесполезно отобразить для меня. Могу ли я подавить это поведение? Или мне нужно создать снимок с помощью другого метода?

3 ответа

Решение

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

По умолчанию LVM автоматически пытается активировать тома на любых физических устройствах, которые подключаются к системе после загрузки, при условии, что присутствуют все PV, и запущены lvmetad и udev (или совсем недавно systemd). Когда создается снимок 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 гостя больше не отображаются на хосте, и, наконец, мои резервные копии запущены...

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

Я столкнулся примерно с той же проблемой в сочетании с 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 работал нормально.

Другие вопросы по тегам