これは、このマシンをバックアップするという私の計画を本当に混乱させています...
KVMハイパーバイザーである複数の仮想マシンのサーバーがあります。これらの1つはDockerを実行しています。/dev/vdbにDockerボリュームがあり、LVM PVとしてセットアップされています。 Dockerが its direct-lvm driver を使用して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.
最終的に私は、ホスト上のデバイスマッパーがこの論理ボリュームsnapshotに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が存在する限り、起動後にシステムに接続される物理デバイス上のボリュームを自動的にアクティブ化しようとしますand 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ボリュームがホストに表示されなくなり、最後にバックアップが実行されています...
/etc/lvm/lvm.confの「filter」値を編集して、KVM Host;上の物理デバイスのみを検査します。デフォルト値は、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
によって作成されたネストされたPVのパーティションマッピングは、どういうわけか使用されたままでした。
トリックは、次のツリーリストにあるように、デバイスマッパーが古いボリュームグループ名を使用して追加の親マッピングを保持しているように見えました。
insidevgname-lvroot (252:44)
└─outsidevgname-myvm--root-p2 (252:43)
└─outsidevgname-myvm--root (252:36)
解決策は、dmsetup remove insidevgname-lvroot
を使用してその特定のマッピングを単に削除することでした。その後、kpartx -d
とlvremove
は問題なく動作しました。