这是真的搞乱我的计划，备份这台机器…
我有一个服务器，这是一个KVM虚拟机pipe理程序的几个虚拟机。 其中之一就是运行Docker。 它在/ dev / vdb上有Docker卷，它被设置为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创build快照，备份快照，然后lvremove它，而不会出现问题。 但是有了这个特定的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快照的内容，看看里面是否有任何东西可以帮我映射。 我能压制这种行为吗？ 还是我需要通过其他方法创build快照？
有时相关的文档被隐藏在configuration文件中，而不是在文档中。 所以它似乎与LVM。
默认情况下，LVM将自动尝试激活引导后连接到系统的任何物理设备上的卷，只要所有的PV都存在， 并且 lvmetad和udev（或更近的systemd）正在运行。 当LVM快照被创build时，udev事件被触发，并且由于快照包含PV，lvmetad会自动运行pvscan ，等等。
通过查看/etc/lvm/backup/docker-volumes docker /etc/lvm/backup/docker-volumes我可以确定lvmetad已经通过使用设备的主要和次要号码（它们绕过了通常会阻止这种情况的LVMfilter）在快照上明确运行pvscan 。 该文件包含：
description = "Created *after* executing 'pvscan --cache --activate ay 253:13'"
这个行为可以通过在/etc/lvm/lvm.conf设置auto_activation_volume_list来控制。 它允许您设置哪些卷组，卷或标签被允许自动激活。
所以，我只需将filter设置为包含主机的两个卷组; 其他任何东西都不匹配filter，并不会自动激活。
auto_activation_volume_list = [ "mandragora", "vm-volumes" ]
客户的LVM卷不再出现在主机上，最后，我的备份正在运行…
您想编辑/etc/lvm/lvm.conf中的“filter”值，仅检查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的卷组之后，由kpartx创build的嵌套PV的分区映射仍然在使用中。
技巧似乎是设备映射程序使用旧的卷组名称保留了一个额外的父映射，如下所示：
insidevgname-lvroot (252:44) └─outsidevgname-myvm--root-p2 (252:43) └─outsidevgname-myvm--root (252:36)
解决scheme是简单地删除与dmsetup remove insidevgname-lvroot特定的映射。 之后， kpartx -d和lvremove工作正常。