题 Linux设备映射器在拍摄快照时将LVM PV嵌套在LV内部


这真的搞乱了我备份这台机器的计划......

我有一台服务器,它是几个虚拟机的KVM管理程序。其中一个是运行Docker。它在/ dev / vdb上有Docker卷,它被设置为LVM PV,Docker使用它 它的直接驱动程序 存储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)

这些与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快照的内容,看看它们中是否有任何内容可以帮助我无法映射。我可以抑制这种行为吗?或者我是否需要通过其他方法创建快照?


11
2018-03-27 05:22






答案:


有时,相关文档隐藏在配置文件中,而不是隐藏在文档中。所以LVM似乎也是如此。

默认情况下,只要所有PV都存在,LVM将自动尝试在启动后连接到系统的任何物理设备上激活卷,  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" ]

guest虚拟机的LVM卷不再出现在主机上,最后,我的备份正在运行...


6
2018-03-27 06:31





您想编辑/etc/lvm/lvm.conf中的“过滤器”值,以仅检查KVM主机上的物理设备;默认值接受包含LV本身的“每个块设备”。默认值以上的评论相当全面,可以比我更好地解释用法。


3
2018-03-27 06:02



请注意,我添加了过滤器,然后运行 pvscan --cache 告诉lvmetad新的过滤器,和 pvscan 现在声明PV被过滤器拒绝,但问题仍然存在。 - Michael Hampton♦
我假设你的意思是无法删除快照。在这个阶段,它可能很棘手,我只能提出含糊的建议。如果重新启动KVM主机是不可能的(我承认这是一个大锤的方法),那么也许从主机'lvchange -an / path / to / LV'将释放它的保留。如果不是这样,那么您可能正在尝试各种dmsetup操作来尝试绕过LVM工具。虽然它在那里变得毛茸茸,但我觉得推荐任何特定的操作并不舒服。 - Craig Miskell
过滤器不执行任何操作,因为lvmetad正在显式扫描快照以响应udev事件。该解决方案原来是配置中的其他内容,但...... - Michael Hampton♦


我遇到了大致相同的问题 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 工作得很好。


1
2017-09-28 09:26