Linuxデバイスマッパーは、スナップショットを撮るときにLV内にネストされたLVM PVをマップします

これは本当にこのマシンをバックアップする私の計画を台無しにしています...

複数の仮想マシンに対するKVMハイパーバイザーであるサーバーがあります。これらの1つはDockerを実行しています。LVM PVとして設定された/ dev / vdbにDockerボリュームがあり、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)

これらは、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スナップショットの内容を検査して、その中に役に立たないマッピングができるものがあるかどうかを確認したくないのです。この動作を抑制できますか？または、他の方法でスナップショットを作成する必要がありますか？

関連するドキュメントは、ドキュメントなどではなく、構成ファイルに隠されている場合があります。そのため、LVMのようです。

デフォルトでLVMによって自動的限りのPVの全てが存在している、として、ブート後にシステムに接続されます任意の物理デバイス上のアクティブボリュームにしようとすると lvmetadとudev（以上、最近にsystemd）が実行されています。LVMスナップショットが作成されると、udevイベントが発生し、スナップショットにはPVが含まれるため、lvmetadが自動的に実行されpvscanます。

見てみると、通常はこれを防ぐLVMフィルターをバイパスしたデバイスのメジャー番号とマイナー番号を使用して、/etc/lvm/backup/docker-volumeslvmetadがpvscanスナップショットで明示的に実行されたことを確認できました。含まれるファイル：

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罰金を働きました。