9.16. 仮想化
多数のキューを使用すると、Windows 仮想マシンで障害が発生することがある
仮想 Trusted Platform Module (vTPM) デバイスが有効で、マルチキュー virtio-net 機能が 250 を超えるキューを使用するように設定されている場合、Windows 仮想マシン (VM) が失敗することがあります。
この問題は、vTPM デバイスの制限が原因で発生します。vTPM デバイスには、開いているファイル記述子の最大数に関するハードコーディングされた制限があります。新しいキューごとに複数のファイル記述子が開かれるため、内部の vTPM 制限を超えて VM が失敗する可能性があります。
この問題を回避するには、次の 2 つのオプションのいずれかを選択します。
- vTPM デバイスを有効のままにしますが、使用するキューは 250 未満にします。
- 250 を超えるキューを使用するには、vTPM デバイスを無効にします。
Jira:RHEL-13336[1]
Milan 仮想マシンの CPU タイプは、AMD Milan システムで利用できないことがある
一部の AMD Milan システムでは、Enhanced REP MOVSB (erms) および Fast Short REP MOVSB (fsrm) 機能フラグがデフォルトで BIOS で無効になっています。したがって、Milan CPU タイプは、これらのシステムで利用できない可能性があります。さらに、機能フラグ設定が異なる Milan ホスト間の仮想マシンのライブマイグレーションが失敗する可能性があります。これらの問題を回避するには、ホストの BIOS で erms および fsrm を手動で有効にします。
Bugzilla:2077770[1]
AMD EPYC でホストパススルーモードを使用する際に、SMT CPU トポロジーが仮想マシンで検出されない
AMD EPYC ホストで行われた CPU ホストパススルーモードで仮想マシンを起動すると、TOPOEXT 機能フラグは存在しません。したがって、仮想マシンは、コアごとに複数のスレッドを持つ仮想 CPU トポロジーを検出できません。この問題を回避するには、ホストパススルーの代わりに EPYC CPU モデルを使用して仮想マシンを起動します。
virtio-blk を使用して仮想マシンに LUN デバイスを割り当てると機能しません。
q35 マシンタイプは、移行用の virtio 1.0 デバイスをサポートしないため、RHEL 8 では virtio 1.0 で非推奨となった機能はサポートされません。特に、RHEL 8 ホストで virtio-blk デバイスから SCSI コマンドを送信することはできません。したがって、virtio-blk コントローラーを使用する場合は、物理ディスクを LUN デバイスとして仮想マシンに割り当てると失敗します。
物理ディスクをゲストオペレーティングシステムを通して渡すことは引き続き可能ですが、device='lun' オプションではなく、device='disk' オプションで設定する必要があることに留意してください。
Bugzilla:1777138[1]
多数の virtio-blk ディスクを使用すると、仮想マシンが起動しないことがある
仮想マシン (VM) に多数の virtio-blk デバイスを追加すると、プラットフォームで使用可能な割り込みベクトルの数が使い果たされる可能性があります。これが発生すると、仮想マシンのゲスト OS は起動できず、dracut-initqueue[392]: Warning: Could not boot エラーが表示されます。
iommu_platform=on が IBM POWER で起動に失敗する
RHEL 8 は現在、IBM POWER システムの仮想マシン用の iommu_platform=on パラメーターに対応していません。これにより、IBM POWER ハードウェアでこのパラメーターを使用して仮想マシンを起動すると、仮想マシンがシステムの起動プロセス時に応答しなくなります。
ibmvfc ドライバーの使用時に IBM POWER ホストが正しく動作するようになりました。
PowerVM 論理パーティション (LPAR) で RHEL 8 を実行すると、ibmvfc ドライバーの問題により、さまざまなエラーが発生することがありました。その結果、次のような特定の状況下で、ホスト上でカーネルパニックが発生していました。
- Live Partition Mobility (LPM) 機能の使用
- ホストアダプターのリセット
- SCSI エラー処理機能 (SCSI EH) 機能の使用
この更新により、ibmvfc の処理が修正され、前述のカーネルパニックは発生しなくなります。
Bugzilla:1961722[1]
IBM POWER Systems で perf kvm レコード を使用すると、仮想マシンがクラッシュする可能性があります。
IBM POWER ハードウェアのリトルエンディアンバリアントで RHEL 8 ホストを使用する場合は、perf kvm record コマンドを使用して KVM 仮想マシンのイベントサンプルを収集すると、仮想マシンが応答しなくなることがあります。この状況は、以下の場合に発生します。
-
perfユーティリティーは権限のないユーザーによって使用され、-pオプションは仮想マシンを識別するために使用されます (perf kvm record -e trace_cycles -p 12345)。 -
仮想マシンが
virshシェルを使用して起動している。
この問題を回避するには、perf kvm ユーティリティーに -i オプションを指定して、virsh シェルを使用して作成した仮想マシンを監視します。以下に例を示します。
# perf kvm record -e trace_imc/trace_cycles/ -p <guest pid> -i
-i オプションを使用する場合、子タスクはカウンターを継承しないため、スレッドは監視されないことに注意してください。
Bugzilla:1924016[1]
特定の CPU モデルの使用時に Hyper-V を有効化した Windows Server 2016 仮想マシンが起動に失敗する
現在、Windows Server 2016 をゲストオペレーティングシステムとして使用し、Hyper-V ロールが有効になっていて、以下の CPU モデルのいずれかを使用する仮想マシンを起動できません。
- EPYC-IBPB
- EPYC
この問題を回避するには、EPYC-v3 CPU モデルを使用するか、仮想マシンの xsaves CPU フラグを手動で有効にします。
Bugzilla:1942888[1]
RHEL 7-ALT ホストから RHEL 8 への POWER9 ゲストの移行に失敗する
現在のリリースでは、RHEL 7-ALT ホストシステムから RHEL 8 に POWER9 仮想マシンを移行すると、Migration status: active のステータスで応答がなくなります。
この問題を回避するには、RHEL 7-ALT ホストで Transparent Huge Pages (THP) を無効にすることで、移行が正常に完了します。
Bugzilla:1741436[1]
virt-customize を使用すると、guestfs-firstboot が失敗することがあります。
virt-customize ユーティリティーを使用して仮想マシン (VM) ディスクイメージを変更すると、SELinux パーミッションが正しくないために guestfs-firstboot サービスが失敗します。これにより、ユーザーの作成やシステム登録の失敗など、仮想マシンの起動時にさまざまな問題が発生します。
この問題を回避するには、virt-customize コマンドに --selinux-relabel オプションを指定して使用します。
macvtap 仮想ネットワークから正引きインターフェイスを削除すると、このネットワークの接続数がすべてリセットされます。
現在、複数のフォワードインターフェイスを持つ macvtap 仮想ネットワークからフォワードインターフェイスを削除すると、ネットワークの他のフォワードインターフェイスの接続ステータスもリセットされます。したがって、ライブネットワーク XML の接続情報が正しくありません。ただし、これは仮想ネットワークの機能に影響を与えるわけではないことに注意してください。この問題を回避するには、ホストで libvirtd サービスを再起動します。
SLOF が指定された仮想マシンは netcat インターフェイスでの起動に失敗する
netcat(nc) インターフェイスを使用して、現在 Slimline Open Firmware(SLOF) プロンプトで待機中の仮想マシンのコンソールにアクセスすると、ユーザー入力は無視され、仮想マシンが応答しないままとなります。この問題を回避するには、仮想マシンに接続する場合は nc -C オプションを使用するか、代わりに telnet インターフェイスを使用します。
Bugzilla:1974622[1]
場合によっては、virt-manager で仲介デバイスを仮想マシンに接続すると失敗します
virt-manager アプリケーションは現在、仲介されたデバイスを検出できますが、デバイスがアクティブであるかどうかを認識できません。結果として、virt-manager を使用して、非アクティブな仲介デバイスを実行中の仮想マシン (VM) に接続しようとすると失敗します。同様に、非アクティブな仲介デバイスを使用する新しい VM を作成しようとすると、device not found エラーで失敗します。
この問題を回避するには、virt-manager で使用する前に、virsh nodedev-start または mdevctl start コマンドを使用して仲介デバイスをアクティブにします。
RHEL 9 仮想マシンが POWER8 互換モードでの起動に失敗する
現在、仮想マシン (VM) が次のような CPU 設定も使用している場合、ゲストオペレーティングシステムとして RHEL 9 を実行する仮想マシンの起動は失敗します。
<cpu mode="host-model">
<model>power8</model>
</cpu>この問題を回避するには、RHEL 9 仮想マシンで POWER8 互換モードを使用しないでください。
さらに、POWER8 ホストでは RHEL 9 VM を実行できないことに注意してください。
SUID と SGID が virtiofs で自動的にクリアされない
killpriv_v2 機能を使用して virtiofsd サービスを実行すると、一部のファイルシステム操作を実行した後、システムによって SUID および SGID 権限が自動的にクリアされない場合があります。したがって、アクセス許可をクリアしないと、潜在的なセキュリティー上の脅威が発生する可能性があります。この問題を回避するには、次のコマンドを入力して killpriv_v2 機能を無効にします。
# virtiofsd -o no_killpriv_v2
Bugzilla:1966475[1]
ホストで OVS サービスを再起動すると、実行中の VM でネットワーク接続がブロックされることがある
ホストで Open vSwitch (OVS) サービスが再起動またはクラッシュすると、このホストで実行されている仮想マシン (VM) はネットワークデバイスの状態を回復できません。その結果、仮想マシンがパケットを完全に受信できなくなる可能性があります。
この問題は、virtio ネットワークスタックで圧縮された virtqueue 形式を使用するシステムのみに影響します。
この問題を回避するには、virtio ネットワークデバイス定義で packed=off パラメーターを使用して、圧縮された virtqueue を無効にします。圧縮された virtqueue を無効にすると、状況によっては、ネットワークデバイスの状態を RAM から回復できます。
nodedev-dumpxml が特定の仲介デバイスの属性を正しく一覧表示しない
現在、nodedev-dumpxml は、nodedev-create コマンドを使用して作成された仲介デバイスの属性を正しく一覧表示していません。この問題を回避するには、代わりに nodedev-define コマンドおよび nodedev-start コマンドを使用します。
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-2451[1]
