5.11. 仮想化
大容量メモリーを搭載した仮想マシンが状態を正しく報告するようになる
以前は、1 TB 以上のメモリーを使用している仮想マシン (VM) をライブマイグレーションすると、libvirt
が仮想マシンの状態を誤って報告していました。この問題は修正され、大量のメモリーを搭載したライブマイグレーションされた仮想マシンのステータスが libvirt
によって正確に報告されるようになりました。
Jira:RHEL-28819[1]
仮想マシンのネットワークブートが RNG デバイスなしでも正常に動作するようになる
以前は、仮想マシン (VM) に RNG デバイスが設定されておらず、その CPU モデルが RDRAND 機能をサポートしていない場合、ネットワークから仮想マシンを起動することはできませんでした。この更新により、この問題は修正され、RDRAND をサポートしていない仮想マシンは、RNG デバイスが設定されていなくてもネットワークから起動できるようになりました。
ただし、ネットワークからの起動時のセキュリティーを強化するために、RDRAND をサポートしていない CPU モデルを使用する仮想マシンには RNG デバイスを追加することが強く推奨される点に注意してください。
Jira:RHEL-58631、Jira:RHEL-65725
vGPU ライブマイグレーションで、過剰な量のダーティーページが報告されなくなる
以前は、NVIDIA vGPU が接続された仮想マシン (VM) のライブマイグレーションを実行すると、移行中に過剰な量のダーティーページが誤って報告されることがありました。この問題により、移行中に必要な仮想マシンのダウンタイムが長くなり、移行が失敗する可能性がありました。
この更新により、根本的な問題が修正され、移行中に正しいダーティーページが報告されるようになり、場合によっては vGPU ライブマイグレーション中に必要な仮想マシンのダウンタイムを減らすことができます。
Jira:RHEL-64307[1]
vGPU ドライバーのバージョンがソースホストとターゲットホストで異なる場合でも、vGPU ライブマイグレーションが失敗しなくなりました。
以前は、ソースホストとターゲットホストのドライバーバージョンが異なる場合、NVIDIA vGPU が接続された仮想マシン (VM) のライブマイグレーションは失敗していました。
この更新により、基礎となるコードが修正され、ドライバーのバージョンが移行元ホストと移行先ホストで異なる場合でも、NVIDIA vGPU を使用した仮想マシンのライブマイグレーションが正しく機能するようになりました。
Jira:RHEL-33795[1]
仮想マシンが AMD SRSO の脆弱性を誤って報告しなくなる
以前は、AMD Zen 3 および 4 CPU アーキテクチャーを搭載した RHEL 9 ホストで実行されている仮想マシン (VM) が、投機的リターンスタックオーバーフロー (SRSO) 攻撃に対する脆弱性を誤って報告していました。
この問題は cpuid フラグの欠落によって発生していましたが、この更新で修正されました。仮想マシンによって報告された AMD SRSO の脆弱性に関するレポートは、すべて正しいものとして扱われるようになりました。
Jira:RHEL-26152[1]
仮想マシンに RHEL をインストールするための予想されるシステムディスクをインストールプログラムが表示するようになる
以前は、virtio-scsi
デバイスを使用して仮想マシンに RHEL をインストールすると、device-mapper-multipath
のバグにより、これらのデバイスがインストールプログラムに表示されない可能性がありました。その結果、インストール時に、シリアルセットを持つデバイスとシリアルセットを持たないデバイスがある場合、シリアルセットを持つすべてのデバイスを multipath
コマンドが要求していました。このため、仮想マシンに RHEL をインストールするために必要なシステムディスクをインストールプログラムが検出できませんでした。
この更新により、multipath
はシリアル番号のないデバイスを World Wide Identifier (WWID) がないものとして正しく設定し、それらを無視するようになりました。インストール時に、multipath
は multipathd
がマルチパスデバイスのバインドに使用するデバイスのみを要求し、インストールプログラムは仮想マシンに RHEL をインストールするための予想されるシステムディスクを表示します。
Jira:RHELPLAN-66975[1]
AMD EPYC CPU を搭載したホストで v2v 変換を行った後、Windows ゲストの起動がより安定する
virt-v2v
ユーティリティーを使用して、Windows 11 または Windows Server 2022 をゲスト OS として使用する仮想マシン (VM) を変換した後、以前は仮想マシンの起動に失敗していました。これは、AMD EPYC シリーズ CPU を使用するホストで発生していました。現在、基礎となるコードが修正され、仮想マシンは説明した状況で期待どおりに起動します。
Jira:RHELPLAN-147926[1]
nodedev-dumpxml
が、特定の仲介デバイスの属性を正しくリストする
この更新より前は、nodedev-dumpxml
ユーティリティーは、nodedev-create
コマンドを使用して作成された仲介デバイスの属性を正しくリストしませんでした。この問題は修正され、nodedev-dumpxml
が該当する仲介デバイスの属性を適切に表示するようになりました。
Jira:RHELPLAN-139536[1]
virtqemud
または libvirtd
を再起動した後、virtiofs
デバイスをアタッチできるようになる
以前は、virtqemud
サービスまたは libvirtd
サービスを再起動すると、virtiofs
ストレージデバイスをホスト上の仮想マシン (VM) に接続できなくなりました。このバグは修正されており、説明されているシナリオで期待どおりに virtiofs
デバイスをアタッチできるようになりました。
Jira:RHELPLAN-119912[1]
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]
VNC ビューアーが、ramfb
のライブマイグレーション後に仮想マシンディスプレイを正しく初期化する
この更新により、仮想マシン (VM) のプライマリーディスプレイとして設定できる ramfb
フレームバッファーデバイスが強化されます。以前は、ramfb
は移行できなかったため、ramfb
を使用する仮想マシンではライブマイグレーション後に空白の画面が表示されていました。現在、ramfb
は、ライブマイグレーションと互換性があります。その結果、移行が完了すると仮想マシンデスクトップが表示されます。