☰

シンプルゲストドメインの外部スナップショット

tag-icon • tag-icon arch-linux libvirt snapshot virt-manager
シンプルゲストドメインの外部スナップショット

私はホストとゲストの両方でArch Linuxを使用しています。 UEFIブートのためにedk2-ovmfゲストがファームウェアをインストールして使用できるようにしました/usr/share/edk2-ovmf/x64/OVMF_CODE.fd。仮想マシンのスナップショットを作成したいのですが、エラーが発生します。

Error creating snapshot: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/details/snapshots.py", line 237, in _do_create_snapshot
    self.vm.create_snapshot(xml)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1124, in create_snapshot
    self._backend.snapshotCreateXML(xml, flags)
  File "/usr/lib/python3.9/site-packages/libvirt.py", line 3059, in snapshotCreateXML
    raise libvirtError('virDomainSnapshotCreateXML() failed')
libvirt.libvirtError: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported

私が選択したファームウェア（Archのインストールに必要なUEFIを使用して起動する必要がある）がスナップショットをサポートしていないようです。

現在の設定を使用してスナップショットを作成する方法はありますか？

答え1

2022年でも、内部スナップショットは変更されませんでした。唯一の解決策は、外部スナップショットを使用することです。詳しくは以下をご覧ください。KVM：libvirt外部スナップショットの作成と復元。外部スナップショットの例のすべてのクレジットは、次に移動します。ファビアン・リー。

シンプルゲストドメインの外部スナップショット

外部スナップショットの作成

ゲストドメインがすべてを含む単純なVMの場合は、次のように<disk>起動 type="file"されたVMの状態（RAMを除く）の外部スナップショットを作成します。この例では、ハードドライブがにあり、hdaCD-ROMがにあると想定していますhdb。

# name of domain, snapshot, and target disk device
thedomain="mysimpledomain"
snapshotname="simple-test"
targetdisk="hda"

# look at '<disk>' types, should be just 'file' types
virsh dumpxml $thedomain | grep '<disk' -A5

# show block level devices and qcow2 paths (hda,hdb,..etc)
virsh domblklist $thedomain

# create snapshot in default pool location
# file name is $thedomain.$snapshotname
virsh snapshot-create-as $thedomain --name $snapshotname --disk-only

# list snapshot
virsh snapshot-list $thedomain

外部スナップショットの復元

基本的なメカニズムを確認し、スナップショットを復元するための変数を準備するには、次のコマンドを実行します。

# notice path to hda has now changed to snapshot file
virsh domblklist $thedomain

# <source> has changed to snapshot file
virsh dumpxml $thedomain | grep '<disk' -A5

# pull default pool path from xml 
pooldir=$(virsh pool-dumpxml default | grep -Po "(?<=path\>)[^<]+")
echo "default pool dir: $pooldir"

# should see two files starting with $thedomain
# the one named $thedomain.$snapshotname is the snapshot
cd $pooldir
ls -latr $thedomain*

# snapshot points to backing file, which is original disk
sudo qemu-img info $thedomain.$snapshotname -U --backing-chain

# capture original backing file name so we can revert
backingfile=$(qemu-img info $thedomain.$snapshotname -U | grep -Po 'backing file:\s\K(.*)')
echo "backing file: $backingfile"

復元するには、ドメインxmlを元のqcow2ファイルに変更し、スナップショットメタデータを削除し、最後にスナップショットファイルを削除する必要があります。

# stop VM
virsh destroy $thedomain

# edit hda path back to original qcow2 disk
virt-xml $thedomain --edit target=$targetdisk --disk path=$backingfile --update

# validate that we are now pointing back at original qcow2 disk
virsh domblklist $thedomain

# delete snapshot metadata
virsh snapshot-delete --metadata $thedomain $snapshotname

# delete snapshot qcow2 file
sudo rm $pooldir/$thedomain.$snapshotname

# start guest domain
virsh start $thedomain

これで、ゲストドメインは元の状態になっているはずです。外部スナップショットの詳細については、上記のリンクを参照してください。

内部スナップショットが無効になったのはなぜですか？

内部スナップショットが無効になった理由は、以下で確認できます。このトピックの検索中に見つけた最高の答えの1つは次のとおりです。これ:

2017年9月4日月曜日午前8時30分23秒-0700にovirt@xxxxxxxxxxxxxxxxxが次のように書きました。

オペレーティングシステム: Fedora 26 + Virt-Manager v1.42 仮想マシン: Win 10 UEFI + Q35

スナップショットの作成中にエラーが発生しました：操作はサポートされていません。 pflashベースのファームウェアを持つVMの内部スナップショットはサポートされていません。

解決策はありますか？

こんにちは。残念ながらそうではなく、UEFIゲストのスナップショットをサポートするのに少し時間がかかることがあります。

問題は、内部スナップショットが古く、外部スナップショットの機能の多くが不足していることです。デフォルトでは、クライアントの状態を含むすべては、ファイルに保存されているディスクが1つしかないクライアントでのみ機能します。

この問題を解決してUEFI virt-managerを使用しているゲストのスナップショットを撮るには、外部スナップショットを使用するように切り替える必要があります。すでにバグがあります。サム。ただし、libvirtには外部スナップショットの一部の必須機能がまだ欠けているため、まだ実行できません。たとえば、外部スナップショットに戻せず、使用できなくなります。 libvirtの実装にはBUGもあります。4。

パベル

サム https://bugzilla.redhat.com/show_bug.cgi?id=1403951 4 https://bugzilla.redhat.com/show_bug.cgi?id=1402581

なぜならここ:

Re: [libvirt] [PATCH v2] qemu: snapshot: pflash ファームウェアを使用して内部スナップショットを無効にする

From: Laszlo Ersek <lersek redhat com>
To: Peter Krempa <pkrempa redhat com>
Cc: libvir-list redhat com
Subject: Re: [libvirt] [PATCH v2] qemu: snapshot: Forbid internal snapshots with pflash firmware
Date: Thu, 23 Mar 2017 17:49:56 +0100

2017年3月23日15:07に、Peter Krempaは次のように書きました。

2017年3月23日木曜日11:03:02 +0100でLazzlo Ersekが書いた：

2017年3月23日10:54に、Peter Krempaは次のように書きました。

2017年3月23日木曜日10:48:01 +0100でLazzlo Ersekが書いた：

2017年3月23日10:29に、Peter Krempaは次のように書きました。

変数store（）ファイルがソースの場合、qemuはそれをスナップショットできないため、スナップショットは不完全です。 QEMUはこれらのスナップショットを拒否しません。

また、qcow2可変ストレージサポートファイルの使用を許可すると、この問題は解決されますが、メモリダンプの対象になる可能性があります。

使用されているストレージ形式に関係なく、この場合、libvirtはpflashファイルを処理しないため、オフライン内部スナップショットは不完全です。

問題を回避するには、これらのスナップショットを無効にしてください。

[...]

@@ -13873,8 +13873,14 @@ qemuDomainSnapshotPrepare(virConnectPtr conn, クリーンアップに移動; }

  • / * qemuがOVMFローダーを使用しているVMでは、内部スナップショットは機能しません。
  • * not snapshot the variable store */
  • / *内部スナップショット+ pflashベースのローダーには、次の問題があります。
  • * - if the variable store is raw, the snapshot is incomplete

  • * - alowing a qcow2 image as the varstore would make it eligible to receive

  • *   the vmstate dump, which would make it huge

  • * - offline snapshot would not snapshot the varstore at all

  • *

  • * Avoid the issues by forbidding this completely.

  • */

私はこれについてもっと考えてきましたが、上記の問題にもかかわらず、Snapshot + OVMFユーザーはそれをうまく使用できると思います。上記の問題にもかかわらず、悪い点を観察しなかったため、禁止すると再び戻ります。

理由は次のとおりです。

  1. 内部スナップショットはvirt-managerのデフォルトです。
  2. ゲストは通常​​varstoreを頻繁に再構築しません。通常、インストール時にのみ再構築します。
  3. オペレーティングシステムは通常、開始項目を除いて何も変更しません。
  4. オンラインVMのスナップショットには、メモリイメージにvarstoreが含まれています。
  5. オペレーティングシステムは、失敗した場合に起動エントリを復元するのに非常に熟練しています。

上記の事実により、一部のユーザーは、pflashローダーを使用したスナップショットが期待どおりに機能することを合法的に信じているようです。これは、主にデータが非常に静的で、オペレーティングシステムが重要な内容を保存せず、それ自体がいくつかの問題を解決できるためです。

私は有用性の損失を避けるためにこれを禁止する必要はないと思います。スナップショットが安全ではないという文書を追加できます。さらに、現在同様の問題が発生している外部スナップショットのサポートを追加する必要があります。

有効なように見えますが、本質的に安全ではない操作と安全を保証する明確なエラーメッセージの間にはバランスがあります。

UEFI可変リポジトリには、前述のものよりも多くの用途があります（重要度は降順）。

  • 特定のUEFI変数（認証された変数）にはセキュリティ関連があります。これには、セキュアブート用の標準化されたキー（プラットフォームキー、キー交換キー、ホワイトリスト証明書と署名（DB）、ブラックリスト証明書と署名（DBX））が含まれます。

  • 私が知る限り、これにはshim / MokManager（「MOK」はMachine Owner Keyの略語です）が使用する同様のセキュリティ関連変数も含まれています。つまり、shimは標準化されたセキュアブートインターフェイスでEFIバイナリ検証を委任します。不揮発性変数。

  • UEFI 변수는 Linux "pstore"(영구 저장소) 파일 시스템의 백엔드 역할을 할 수 있습니다. 그러면 충돌이 발생할 경우 Pstore를 사용하여 dmesg의 마지막 부분을 저장할 수 있습니다. 이 메시지는 새로 시작할 때 다시 읽을 수 있습니다.

  • 펌웨어는 부팅할 때마다 내부적으로 여러 변수를 사용(읽기/쓰기)합니다. 이것들은 중요하지 않을 수도 있습니다. 한 가지 예는 일련의 부팅 프로세스 중에 UEFI 메모리 맵 조각화를 줄이는 데 도움이 되는 변수입니다.

  • OVMF는 bootindex 속성을 기반으로(또는 "bootorder" fw_cfg 파일을 더 직접적으로 기반으로) 부팅할 때마다 UEFI 부팅 옵션에서 작동합니다. 물론 이는 아마도 varstore 콘텐츠 중 가장 덜 위험한 범주일 것입니다.

나 자신은 varstore가 실제로 스냅샷을 생성한 적이 없다는 사실을 깨닫지 못한 채 OVMF 게스트의 내부 스냅샷(오프라인에만 해당)을 성공적으로 사용했지만 본질적으로 손실이 있는 작업을 자동으로 수행하는 데 매우 불편함을 느꼈습니다. 특히 varstore가 삭제될 가능성이 있는 경우 더욱 그렇습니다. 안전에 영향이 있습니다.

사용자는 문서를 읽지 않으며(절대 읽지 않습니다), 저는 모호한 보안 부팅 오작동에 대한 향후 버그 보고서를 제출하지 않는 것이 좋습니다.

이는 궁극적으로 libvirt 개발자에게 달려 있지만 제 생각에는 이런 종류의 안전하지 않은 작업을 계속 허용한다면 최소값은 다음과 같습니다.

  • virt-manager에서는 작업이 손실되고 보안에 영향을 미칠 수 있음을 명확하게 나타내는 추가 확인 대화 상자가 나타납니다.

  • virsh에서는 "--force" 또는 이와 유사한 옵션을 지정하지 않는 한 유사한 오류 메시지와 함께 작업을 거부합니다.

  • 또한 다른 (독립적인) libvirt 클라이언트 애플리케이션이 있으므로 이를 제출한 클라이언트 애플리케이션에 관계없이 libvirt 자체가 안전하지 않은 스냅샷 요청을 거부할 수 있도록 libvirt API 수준에 새 플래그가 필요할 수 있습니다.

나는 유용성 회귀가 좋지 않으며 버그 보고서를 생성할 수 있다는 점에 동의합니다.만약에이는 보안 개선과 직접적으로 충돌하므로 보안 개선이 유용성 회귀보다 우선합니다. 사용자가 보안을 무시하도록 허용할 수는 있지만 그 자리에서 알림을 받고 동의해야 합니다.

이번 패치를 통해 앞으로 나아갈 수 있기를 바랍니다. 그러나 궁극적으로는 귀하에게 달려 있습니다.

감사해요! 라즐로

関連情報