☰

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

tag-icon • tag-icon linux lvm device-mapper
Linux 设备映射器在拍摄快照时映射嵌套在 LV 内的 LVM PV

这确实打乱了我备份这台机器的计划......

我有一台服务器，它是多台虚拟机的 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.

最终我发现主机上的设备映射器以某种方式弄清楚了这个逻辑卷快照包含一个 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 快照的内容，看看其中是否有任何对我毫无帮助的内容。我可以抑制这种行为吗？还是我需要通过其他方法创建快照？

答案1

有时相关文档隐藏在配置文件中，而不是文档中。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" ]

客户机的 LVM 卷不再出现在主机上，最后，我的备份正在运行......

答案2

您需要编辑 /etc/lvm/lvm.conf 中的“filter”值，以便仅检查 KVM 主机上的物理设备；默认值接受“每个块设备”，其中包括 LV 本身。默认值上方的注释相当全面，可以比我更好地解释用法。

答案3

我在与 结合时遇到了大致相同的问题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就可以正常工作了。

相关内容