11.16. 仮想化
https または ssh 経由での仮想マシンのインストールに失敗する場合がある
現在、virt-install ユーティリティーは、https または ssh 接続を介して ISO ソースからゲストオペレーティングシステム (OS) をインストールしようとすると失敗します。たとえば、virt-install --cdrom https://example/path/to/image.iso を使用します。仮想マシンを作成する代わりに、上述の操作は internal error: process exited while connecting to monitor というメッセージが表示されて予期せず終了します。
同様に、https または ssh URL、あるいは Download OS 機能を使用した場合、RHEL 9 Web コンソールを使用したゲストオペレーティングシステムのインストールが失敗し、Unknown driver 'https' エラーが表示されます。
この問題を回避するには、ホストに qemu-kvm-block-curl および qemu-kvm-block-ssh をインストールして、https および ssh プロトコルのサポートを有効にします。別の接続プロトコルまたは別のインストールソースを使用することもできます。
仮想マシンで NVIDIA ドライバーを使用すると Wayland が無効になる
現在、NVIDIA ドライバーは Wayland グラフィカルセッションと互換性がありません。これにより、NVIDIA ドライバーを使用する RHEL ゲストオペレーティングシステムは、Wayland を自動的に無効にし、代わりに Xorg セッションを読み込みます。これは主に以下のシナリオで生じます。
- NVIDIA GPU デバイスを RHEL 仮想マシンに渡す場合
- NVIDIA vGPU 仲介デバイスを RHEL 仮想マシンに割り当てる場合
Jira:RHELPLAN-117234[1]
Milan 仮想マシンの CPU タイプは、AMD Milan システムで利用できないことがある
一部の AMD Milan システムでは、Enhanced REP MOVSB (erms) および Fast Short REP MOVSB (fsrm) 機能フラグがデフォルトで BIOS で無効になっています。したがって、Milan CPU タイプは、これらのシステムで利用できない可能性があります。さらに、機能フラグ設定が異なる Milan ホスト間の仮想マシンのライブマイグレーションが失敗する可能性があります。これらの問題を回避するには、ホストの BIOS で erms および fsrm を手動で有効にします。
Bugzilla:2077767[1]
フェイルオーバー設定のある hostdev インターフェイスは、ホットアンプラグされた後にホットプラグすることはできない
フェイルオーバー設定の hostdev ネットワークインターフェイスを実行中の仮想マシン (VM) から削除した後、現在、インターフェイスを同じ実行中の VM に再接続することはできません。
フェイルオーバー VF を使用した VM のコピー後のライブマイグレーションが失敗する
現在、VM が仮想機能 (VF) フェイルオーバー機能が有効になっているデバイスを使用している場合、実行中の仮想マシン (VM) のコピー後移行の試行は失敗します。この問題を回避するには、コピー後の移行ではなく、標準の移行タイプを使用します。
ライブマイグレーション中にホストネットワークが VF と VM に ping できない
設定済みの仮想機能 (VF) で仮想マシン (仮想 SR-IOV ソフトウェアを使用する仮想マシンなど) のライブマイグレーションを行う場合、仮想マシンのネットワークは他のデバイスに表示されず、ping などのコマンドで仮想マシンに到達できません。ただし、移行が終了すると、問題は発生しなくなります。
AVX を無効にすると、仮想マシンが起動できなくなる
Advanced Vector Extensions (AVX) をサポートする CPU を使用するホストマシンで、現在、AVX を明示的に無効にして VM を起動しようとすると失敗し、代わりに VM でカーネルパニックが発生します。
Bugzilla:2005173[1]
ネットワークインターフェイスのリセット後に Windows VM が IP アドレスの取得に失敗する
ネットワークインターフェイスの自動リセット後に、Windows 仮想マシンが IP アドレスの取得に失敗することがあります。その結果、VM はネットワークに接続できません。この問題を回避するには、Windows デバイスマネージャーでネットワークアダプタードライバーを無効にしてから再度有効にします。
vCPU をホットプラグした後、Windows Server 2016 VM が動作を停止することがある
現在、Windows Server 2016 ゲストオペレーティングシステムで実行中の仮想マシン (VM) に vCPU を割り当てると、仮想マシンが予期せず停止したり、応答しなくなったり、再起動したりするなど、さまざまな問題が発生する可能性があります。
NVIDIA パススルーデバイスを備えた VM での冗長エラーメッセージ。
RHEL 9.2 以降のオペレーティングシステムを搭載した Intel ホストマシンを使用している場合、パススルー NVDIA GPU デバイスを備えた仮想マシン (VM) で、次のエラーメッセージが頻繁に記録されます。
Spurious APIC interrupt (vector 0xFF) on CPU#2, should never happen.
ただし、このエラーメッセージは VM の機能には影響しないため、無視してかまいません。詳細は、Red Hat ナレッジベース を参照してください。
Bugzilla:2149989[1]
ホストで OVS サービスを再起動すると、実行中の VM でネットワーク接続がブロックされることがある
ホストで Open vSwitch (OVS) サービスが再起動またはクラッシュすると、このホストで実行されている仮想マシン (VM) はネットワークデバイスの状態を回復できません。その結果、仮想マシンがパケットを完全に受信できなくなる可能性があります。
この問題は、virtio ネットワークスタックで圧縮された virtqueue 形式を使用するシステムのみに影響します。
この問題を回避するには、virtio ネットワークデバイス定義で packed=off パラメーターを使用して、圧縮された virtqueue を無効にします。圧縮された virtqueue を無効にすると、状況によっては、ネットワークデバイスの状態を RAM から回復できます。
中断されたコピー後の VM 移行の回復が失敗することがある
仮想マシン (VM) のコピー後の移行が中断された後、同じ受信ポートですぐに再開されると、移行は Address already in use のエラーで失敗する可能性があります。
この問題を回避するには、コピー後の移行を再開する前に少なくとも 10 秒待つか、移行の回復のために別のポートに切り替えます。
AMD EPYC CPU で NUMA ノードマッピングが正しく機能しない
QEMU は、AMD EPYC CPU の NUMA ノードマッピングを正しく処理しません。これにより、NUMA ノード設定を使用する場合、これらの CPU を持つ仮想マシン (VM) のパフォーマンスに悪影響が及ぶ可能性があります。さらに、VM は起動時に以下のような警告を表示します。
sched: CPU #4's llc-sibling CPU #3 is not on the same node! [node: 1 != 0]. Ignoring dependency. WARNING: CPU: 4 PID: 0 at arch/x86/kernel/smpboot.c:415 topology_sane.isra.0+0x6b/0x80
この問題を回避するには、NUMA ノード設定に AMD EPYC CPU を使用しないでください。
VM 移行中の NFS 障害により、移行が失敗してソース仮想マシンのコアダンプが発生する
現在、仮想マシン (VM) の移行中に NFS サービスまたはサーバーがシャットダウンした場合、ソース VM の QEMU は、実行を再開したときに NFS サーバーに再接続できません。その結果、移行に失敗し、ソース VM でコアダンプが開始されます。現在、使用可能な回避策はありません。
PCIe ATS デバイスが Windows 仮想マシンで動作しない
Windows ゲストオペレーティングシステムを使用して仮想マシン (VM) の XML 設定で PCIe アドレス変換サービス (ATS) デバイスを設定しても、ゲストが仮想マシンの起動後に ATS デバイスを有効にしません。これは、Windows が現在 virtio デバイス上の ATS をサポートしていないためです。
詳細は、Red Hat ナレッジベース を参照してください。
virsh blkiotune --weight コマンドが正しい cgroup I/O コントローラー値を設定できない
現在、virsh blkiotune --weight コマンドを使用して VM weight を設定しても、期待どおりに機能しません。このコマンドは、cgroup I/O コントローラーインターフェイスファイルに正しい io.bfq.weight 値を設定できません。現時点では回避策はありません。
NVIDIA A16 GPU を使用して仮想マシンを起動すると、ホスト GPU が動作を停止する場合がある
現在、NVIDIA A16 GPU パススルーデバイスを使用する仮想マシンを起動すると、ホストシステム上の NVIDIA A16 GPU 物理デバイスが動作を停止する場合があります。
この問題を回避するには、ハイパーバイザーを再起動し、GPU デバイスの reset_method を bus に設定します。
# echo bus > /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method # cat /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method bus
詳細は、Red Hat ナレッジベースの記事 を参照してください。
Jira:RHEL-7212[1]
ストレージエラーが原因で Windows 仮想マシンが応答しなくなる可能性がある
Windows ゲストオペレーティングシステムを使用する仮想マシン (VM) では、I/O 負荷が高いときにシステムが応答しなくなることがあります。このような場合、システムは viostor Reset to device, \Device\RaidPort3, was issued エラーをログに記録します。
Jira:RHEL-1609[1]
特定の PCI デバイスを搭載した Windows 10 仮想マシンが起動時に応答しなくなることがある
現在、Windows 10 ゲストオペレーティングシステムを使用する仮想マシン (VM) は、ローカルディスクバックエンドを備えた virtio-win-scsi PCI デバイスが仮想マシンにアタッチされている場合、起動中に応答しなくなる可能性があります。この問題を回避するには、multi_queue オプションを有効にして仮想マシンを起動します。
Jira:RHEL-1084[1]
virtio-win ドライバー用の virtio-win-guest-tool の修復機能が機能しない
現在、Virtio Balloon Driver などの virtio-win ドライバーに対して virtio-win-guest-tool の Repair ボタンを使用しても、このボタンは効果がありません。そのため、ドライバーをゲスト上で削除した後は再インストールできません。
Jira:RHEL-1517[1]
メモリーバルーンデバイスセットが設定された Windows 11 仮想マシンが再起動中に予期せず終了することがある
現在、Windows 11 ゲストオペレーティングシステムとメモリーバルーンデバイスを使用する仮想マシン (VM) の再起動が、DRIVER POWER STAT FAILURE ブルースクリーンエラーで失敗する場合があります。
Jira:RHEL-935[1]
コピー後の仮想マシン移行の再開が失敗する場合がある
現在、仮想マシンのコピー後の移行を実行するときに、移行の RECOVER フェーズでプロキシーネットワークに障害が発生すると、仮想マシンが応答しなくなり、移行を再開できなくなります。代わりに、recovery コマンドは次のエラーを表示します。
error: Requested operation is not valid: QEMU reports migration is still running
virtio バルーンドライバーが Windows 10 仮想マシンで動作しない場合がある
特定の状況下では、virtio-balloon ドライバーが Windows 10 ゲストオペレーティングシステムを使用する仮想マシン (VM) 上で正しく動作しません。その結果、そのような仮想マシンは割り当てられたメモリーを効率的に使用できない可能性があります。
Windows 仮想マシンの virtio ファイルシステムのパフォーマンスは最適ではない
現在、Windows ゲストオペレーティングシステムを使用する仮想マシン (VM) 上で virtio ファイルシステム (virtiofs) が設定されている場合、仮想マシン内の virtiofs のパフォーマンスは、Linux ゲストを使用する仮想マシンよりも大幅に低下します。
Jira:RHEL-1212[1]
Windows 仮想マシンのストレージデバイスのホットアンプラグが失敗する可能性がある
Windows ゲストオペレーティングシステムを使用する仮想マシン (VM) で、仮想マシンの実行中にストレージデバイスを削除すると (デバイスのホットアンプラグとも呼ばれる)、失敗する場合があります。その結果、ストレージデバイスは仮想マシンにアタッチされたままになり、ディスクマネージャーサービスが応答しなくなる可能性があります。
CPU を Windows 仮想マシンにホットプラグするとシステム障害が発生する可能性がある
Huge Page が有効になっている Windows 仮想マシンに最大数の CPU をホットプラグすると、ゲストオペレーティングシステムが次の Stop エラー でクラッシュする場合があります。
PROCESSOR_START_TIMEOUT
Windows 仮想マシンの virtio ドライバーの更新が失敗する可能性がある
Windows 仮想マシン (VM) で KVM 準仮想化 (virtio) ドライバーを更新すると、更新によりマウスが動作しなくなり、新しくインストールされたドライバーが署名されない可能性があります。この問題は、virtio-win.iso ファイルの一部である virtio-win-guest-tools パッケージからインストールして、virtio ドライバーを更新する際に発生します。
この問題を回避するには、Windows Device Manager を使用して virtio ドライバーを更新します。
Jira:RHEL-574[1]
vhost-kernel を使用する仮想マシンで TX キューのサイズを変更できない
現在、virtio ネットワークドライバーのバックエンドとして vhost-kernel を使用する KVM 仮想マシンでは、TX キューサイズをセットアップすることができません。したがって、TX キューにはデフォルト値の 256 しか使用できず、仮想マシンのネットワークスループットを最適化できない可能性があります。
Jira:RHEL-1138[1]
仮想マシンが AMD SRSO の脆弱性を誤って報告する
AMD Zen 3 および 4 の CPU アーキテクチャーを搭載した RHEL 9 ホスト上で実行している RHEL 9.4 仮想マシン (VM) は、投機的リターンスタックオーバーフロー (SRSO) 攻撃に対する脆弱性を誤って報告します。
# lscpu | grep rstack
Vulnerability Spec rstack overflow: Vulnerable: Safe RET, no microcode
この問題は cpuid フラグの欠落によって発生し、次の条件下では仮想マシンで脆弱性は実際に完全に軽減されます。
-
ホストには、ここで説明されているように、更新された
linux-firmwareパッケージがあります (cve-2023-20569)。 -
ホストカーネルでは緩和策が有効になっており、これがデフォルトの動作です。緩和策が有効になっている場合は、ホスト上の
lscpuコマンド出力にSafe RETが表示されます。
Jira:RHEL-26152[1]
大量の vCPU と仮想ディスクを持つ仮想マシンは失敗する場合がある
現在、RHEL 仮想マシン (VM) に大量の vCPU と仮想ディスクを割り当てると、仮想マシンの起動に失敗する場合があります。
この問題を回避するには、可能であれば、ブロックデバイスの代わりに Small Computer System Interface (SCSI) 仮想ストレージデバイスを使用します。詳細は、CLI を使用して vHBA デバイスで SCSI ベースのストレージプールの作成 を参照してください。
仮想ブロックデバイスを使用する必要がある場合は、-global virtio-blk-pci.vectors=<number-of-vectors> QEMU オプションを使用して仮想マシンを起動し、割り込みベクターの数を減らすこともできます。仮想マシンが正常に起動できる、十分に少ない数の割り込みベクターを見つけるようにしてください。
Jira:RHEL-32990[1]
e1000e または igb モデルインターフェイスのステータスが down の場合でも、リンクステータスは仮想マシン上に up と表示されます。
仮想マシンを起動する前に、e1000 または igb モデルのネットワークインターフェイスのイーサネットリンクのステータスを down に設定します。設定したにもかかわらず、仮想マシンの起動後、ネットワークインターフェイスは up ステータスを維持します。これは、イーサネットリンクのステータスを down に設定し、仮想マシンを停止して再起動すると、自動的に up に設定されるためです。その結果、ネットワークインターフェイスの正しい状態が維持されません。回避策として、次のコマンドを使用して、仮想マシン内のネットワークインターフェイスのステータスを down に設定します。
# ip link set dev eth0 down
または、仮想マシンの実行中にこのネットワークインターフェイスを削除して再度追加してみることもできます。
NBD を使用して TLS 接続経由で仮想マシンストレージを移行すると正しく動作しない
現在、TLS 接続を介して Network Block Device (NBD) プロトコルを使用して仮想マシン (VM) とそのストレージデバイスを移行する場合は、TLS ハンドシェイクでのデータ競合により、移行が成功したように見えることがあります。ただし、これにより、宛先仮想マシン上の QEMU プロセスがそれ以上のやり取りに応答しなくなります。
ネットワークを信頼できる場合は、仮想マシンストレージの移行中に使用される NBD プロトコルに TLS 接続ではなくプレーンテキストを使用することで、この問題を回避できます。
AMD SEV-SNP を搭載した仮想マシンで Kdump が失敗する
現在、Secure Nested Paging (SNP) 機能を備えた AMD Secure Encrypted Virtualization (SEV) を使用する RHEL 9 仮想マシン (VM) では kdump が失敗します。
Jira:RHEL-10019[1]
VM が AMD EPYC モデルで spec_rstack_overflow パラメーターの 脆弱な ステータスを誤って報告
ホストを起動すると、spec_rstack_overflow パラメーターの脆弱性は検出されません。ログのパラメーターをクエリーすると、メッセージが表示されます。
# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow Mitigation: Safe RET
同じホストで仮想マシンを起動すると、仮想マシンは spec_rstack_overflow パラメーターに脆弱性を検出します。また、ログのパラメーターをクエリーすると、メッセージが表示されます。
# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow Vulnerable: Safe RET, no microcode
ただし、これは誤った警告メッセージであり、VM 内の /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow ファイルのステータスを無視できます。
Jira:RHEL-17614[1]
