6.14. 仮想化

大量の vCPU と仮想ディスクを持つ仮想マシンに障害が発生しなくなりました。

以前は、RHEL 仮想マシンに大量の vCPU および仮想ディスクを割り当てると、仮想マシンが起動に失敗する可能性がありました。今回の更新により、問題が修正され、これらのケースで仮想マシンが正常に機能するようになりました。

NBD を使用した TLS 接続を介した仮想マシンストレージの移行が正しく機能する

以前は、TLS 接続上で Network Block Device (NBD)プロトコルを使用して仮想マシン(VM)とそのストレージデバイスを移行する場合、TLS ハンドシェイクのデータ競合により移行が正常に実行されるように見えていました。ただし、宛先 VM の QEMU プロセスが応答しなくなり、さらなる対話が行われる可能性がありました。

インストーラーには、VM に RHEL をインストールするために予期されるシステムディスクが表示される

以前は、virtio-scsi デバイスを使用して VM に RHEL をインストールする場合、device-mapper-multipath のバグにより、これらのデバイスがインストーラーに表示されない可能性がありました。したがって、インストール中に、シリアルセットを持つデバイスとシリアルセットを持たないデバイスがある場合、multipath コマンドはすべてのデバイスがシリアルを持つと主張していました。このため、インストーラーは、VM に RHEL をインストールするための予期されたシステムディスクを見つけることができませんでした。

AMD EPYC CPU を搭載したホストで v2v 変換を行った後、Windows ゲストの起動がより安定します。

virt-v2v ユーティリティーを使用して、Windows 11 または Windows Server 2022 をゲスト OS として使用する仮想マシン (VM) を変換した後、以前は仮想マシンの起動に失敗していました。これは、AMD EPYC シリーズ CPU を使用するホストで発生していました。現在、基礎となるコードが修正され、仮想マシンは説明した状況で期待どおりに起動します。

nodedev-dumpxml は、特定の仲介デバイスの属性を正しくリストします。

この更新より前は、nodedev-dumpxml ユーティリティーは、nodedev-create コマンドを使用して作成された仲介デバイスの属性を正しくリストしませんでした。この問題は修正され、nodedev-dumpxml が該当する仲介デバイスの属性を適切に表示するようになりました。

virtqemud または libvirtd を再起動した後、virtiofs デバイスをアタッチできるようになる

以前は、virtqemud サービスまたは libvirtd サービスを再起動すると、virtiofs ストレージデバイスをホスト上の仮想マシン (VM) に接続できなくなりました。このバグは修正されており、説明されているシナリオで期待どおりに virtiofs デバイスをアタッチできるようになりました。

IBM Z 上の virtio-gpu で blob リソースが正しく動作するようになる

以前は、virtio-gpu デバイスは IBM Z システム上の blob メモリーリソースと互換性がありませんでした。その結果、IBM Z ホスト上で virtio-gpu を使用して仮想マシン (VM) を設定し、blob リソースを使用すると、仮想マシンにグラフィカル出力がありませんでした。

postcopy 仮想マシンの移行を再開すると、正しく機能するようになりました。

以前は、仮想マシン(VM)のポストコピー移行を実行すると、移行の RECOVER フェーズ中にプロキシーネットワークに障害が発生した場合、仮想マシンが応答しなくなり、移行を再開できませんでした。代わりに、recovery コマンドに以下のエラーが表示されます。

virtio-win ドライバーを再インストールしても、ゲストの DNS 設定がリセットされなくなる

以前、Windows ゲストオペレーティングシステムを使用する仮想マシンでは、ネットワークインターフェイスカード (NIC) の virtio-win ドライバーを再インストールまたはアップグレードすると、ゲストの DNS 設定がリセットされていました。その結果、Windows ゲストのネットワーク接続が失われる場合がありました。