8.15. 仮想化
FIFO スケジューラーを備えた RT 仮想マシンが正しく起動するようになる
以前は、リアルタイム (RT) 仮想マシン (VM) で vCPU スケジューラーに fifo 設定を使用するように設定した後、仮想マシンを起動しようとすると応答しなくなりました。代わりに、仮想マシンに Guest has not initialized the display (yet) というエラーが表示されました。この更新により、エラーが修正され、説明した状況で vCPU スケジューラー用に fifo を設定することが期待どおりに動作するようになりました。
Jira:RHEL-2815[1]
ダンプの失敗によって IBM Z VMs with Secure Execution がブロックされなくなりました。
以前は、IBM Z virtual machine (VM) with Secure Execution のダンプが失敗すると、仮想マシンは一時停止状態のままになり、実行がブロックされていました。たとえば、ディスクに十分なスペースがない場合、virsh dump コマンドを使用して仮想マシンをダンプすることは失敗します。
基礎となるコードが修正され、ダンプ失敗後も Secure Execution 仮想マシンは正常に操作を再開します。
Jira:RHEL-16695[1]
仮想マシンに RHEL をインストールするための予想されるシステムディスクをインストールプログラムが表示するようになりました
以前は、virtio-scsi デバイスを使用して仮想マシンに RHEL をインストールすると、device-mapper-multipath のバグにより、これらのデバイスがインストールプログラムに表示されない可能性がありました。その結果、インストール時に、シリアルセットを持つデバイスとシリアルセットを持たないデバイスがある場合、シリアルセットを持つすべてのデバイスを multipath コマンドが要求していました。このため、仮想マシンに RHEL をインストールするために必要なシステムディスクをインストールプログラムが検出できませんでした。
今回の更新により、multipath はシリアルのないデバイスを World Wide Identifier (WWID) を持たないものとして正しく設定し、無視します。インストール時に、multipath は multipathd がマルチパスデバイスのバインドに使用するデバイスのみを要求し、インストールプログラムは仮想マシンに RHEL をインストールするための予想されるシステムディスクを表示します。
Bugzilla:1926147[1]
多数のキューを使用しても仮想マシンで障害が発生しなくなりました
以前は、Virtual Trusted Platform Module (vTPM) デバイスが有効で、マルチキュー virtio-net 機能が 250 を超えるキューを使用するように設定されている場合、仮想マシン (VM) で障害が発生することがありました。
この問題は、vTPM デバイスの制限が原因で発生していました。この更新により、問題が修正され、250 を超えるキューを使用する、vTPM が有効な仮想マシンが確実に動作するようになりました。
Jira:RHEL-13335[1]
AMD EPYC CPU を搭載したホストで v2v 変換を行った後、Windows ゲストの起動がより安定します。
virt-v2v ユーティリティーを使用して、Windows 11 または Windows Server 2022 をゲスト OS として使用する仮想マシン (VM) を変換した後、以前は仮想マシンの起動に失敗していました。これは、AMD EPYC シリーズ CPU を使用するホストで発生していました。現在、基礎となるコードが修正され、仮想マシンは説明した状況で期待どおりに起動します。
Bugzilla:2168082[1]
nodedev-dumpxml は、特定の仲介デバイスの属性を正しくリストします。
この更新より前は、nodedev-dumpxml ユーティリティーは、nodedev-create コマンドを使用して作成された仲介デバイスの属性を正しくリストしませんでした。この問題は修正され、nodedev-dumpxml は、影響を受ける仲介デバイスの属性を適切に表示するようになりました。
virtqemud または libvirtd を再起動した後、virtiofs デバイスを接続できませんでした
以前は、virtqemud サービスまたは libvirtd サービスを再起動すると、virtiofs ストレージデバイスをホスト上の仮想マシン (VM) に接続できなくなりました。このバグは修正されており、説明されているシナリオで期待どおりに virtiofs デバイスをアタッチできるようになりました。
仮想マシンへの Watchdog カードのホットプラグが失敗しなくなる
以前は、使用可能な PCI スロットがない場合、実行中の仮想マシン (VM) に Watchdog カードを追加すると、以下のエラーが発生し、失敗していました。
Failed to configure watchdog ERROR Error attempting device hotplug: internal error: No more available PCI slots
今回の更新で問題が修正され、実行中の仮想マシンに Watchdog カードを追加すると、想定どおりに機能するようになりました。
IBM Z 上の virtio-gpu で blob リソースが正しく動作するようになる
以前は、virtio-gpu デバイスは IBM Z システム上の blob メモリーリソースと互換性がありませんでした。その結果、IBM Z ホスト上で virtio-gpu を使用して仮想マシン (VM) を設定し、blob リソースを使用すると、仮想マシンにグラフィカル出力がありませんでした。
この更新により、virtio デバイスにオプションの blob 属性が追加されました。blob を on に設定すると、デバイス内の blob リソースが使用できるようになります。これにより、virtio-gpu デバイスで説明した問題が防止され、ゲストとホスト間のピクセルデータのコピーが削減または排除されるため、ディスプレイパスも高速化されます。blob リソースのサポートには QEMU バージョン 6.1 以降が必要であることに注意してください。
virtio-win ドライバーを再インストールしても、ゲストの DNS 設定がリセットされなくなりました
以前は、Windows ゲストオペレーティングシステムを使用する仮想マシンで、ネットワークインターフェイスコントローラー (NIC) の virtio-win ドライバーを再インストールまたはアップグレードすると、ゲストの DNS 設定がリセットされていました。その結果、Windows ゲストのネットワーク接続が失われる場合がありました。
この更新により、上記の問題が修正されました。したがって、virtio-win の最新バージョンを再インストールまたはアップグレードすると、問題は発生しなくなります。ただし、virtio-win の以前のバージョンからアップグレードしても問題は解決されず、Windows ゲストで DNS リセットが引き続き発生する可能性があることに注意してください。
Jira:RHEL-1860[1]
