Что действительно мешает моему плану создать резервную копию этой машины ...
У меня есть сервер, который представляет собой гипервизор KVM для нескольких виртуальных машин. Один из них - это Docker. Он имеет свои тома Docker на / dev / vdb, который настроен как PVM 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.
В конце концов я понял, что устройство-сопоставитель на хосте каким-то образом выяснило, что этот логический том снимок содержал LVM PV, а затем приступил к сопоставлению логических томов в моментальном снимке с хостом (показаны только соответствующие тома):
[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, чтобы увидеть, есть ли в них что-нибудь, что может бесполезно отобразить для меня. Могу ли я подавить такое поведение? Или мне нужно создать снимок каким-то другим способом?
Иногда соответствующая документация скрыта в файлах конфигурации, а не, скажем, в документации. Так вроде с 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 гостя больше не отображаются на хосте, и, наконец, мои резервные копии запущены ...
Вы хотите отредактировать значение «filter» в /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 работал нормально.