解決策 1:
関連するドキュメントが、たとえばドキュメントではなく、構成ファイルに隠されている場合があります。 LVM のようです。
デフォルトでは、LVM は、すべての PV が存在する限り、起動後にシステムに接続された物理デバイス上のボリュームを自動的にアクティブ化しようとします。および 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 のボリューム グループの非アクティブ化に成功したように見えた後、kpartx によって作成されたネストされた PV のパーティション マッピングが 、どういうわけか使用され続けました。
このトリックは、デバイス マッパーが古いボリューム グループ名を使用して追加の親マッピングを保持していたことにあるようです。ツリー リストでは次のようになります。
insidevgname-lvroot (252:44)
└─outsidevgname-myvm--root-p2 (252:43)
└─outsidevgname-myvm--root (252:36)
解決策は、その特定のマッピングを dmsetup remove insidevgname-lvroot で単純に削除することでした .その後、kpartx -d と lvremove 正常に動作しました。