11.14. 仮想化

Windows Server 2019 ホストの RHEL 8 仮想マシンで GUI ディスプレイのパフォーマンスが下がります。

Windows Server 2019 ホストのグラフィカルモードで RHEL 8 をゲストオペレーティングシステムとして使用すると、GUI ディスプレイのパフォーマンスが下がり、ゲストのコンソール出力に現在必要なよりも長い時間がかかります。

これは、Windows 2019 ホストで既知の問題で、Microsoft が修正を保留しています。この問題を回避するには、SSH を使用してゲストに接続するか、ホストとして Windows Server 2016 を使用します。

(BZ#1706541)

QXL で、Wayland を使用する仮想マシンの複数のモニターを表示できません。

remote-viewer ユーティリティーを使用して、Wayland ディスプレイサーバーを使用している仮想マシンのモニターを複数表示すると、仮想マシンが応答しなくなり、Waiting for display というステータスメッセージが永久に表示されます。

この問題を回避するには、Wayland を使用する仮想マシンの GPU デバイスとして qxl の代わりに virtio-gpu を使用します。

(BZ#1642887)

virsh iface-\* コマンドが一貫して動作しません。

現在、virsh iface-* コマンド (virsh iface-start、virsh iface-destroy など) は、設定の依存関係が原因で頻繁に失敗します。したがって、ホストネットワーク接続の設定および管理には virsh iface-\* コマンドを使用しないことが推奨されます。代わりに、NetworkManager プログラムとその関連管理アプリケーションを使用します。

(BZ#1664592)

RHEL 8 仮想マシンが、Witherspoon ホストで起動できないことがあります。

RHEL 8 仮想マシン (VM) で pseries -rhel7.6.0-sxxm マシンタイプを使用すると、DD 2.2 または DD2.3 CPU を使用する Power9 S922LC for HPC ホストで起動できない場合があります。

代わりに仮想マシンを起動しようとすると、以下のエラーメッセージが出力されます。 

qemu-kvm: Requested safe indirect branch capability level not supported by kvm

この問題を回避するには、仮想マシンの XML 設定を次のように構成します。 

<domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <qemu:commandline>
    <qemu:arg value='-machine'/>
    <qemu:arg value='cap-ibs=workaround'/>
  </qemu:commandline>

(BZ#1732726, BZ#1751054)

IBM POWER 仮想マシンが、空の NUMA ノードで正常に動作しません。

現在、RHEL 8 ホストで実行している IBM POWER 仮想マシン (VM) が、メモリーを使用せず (memory='0')、CPU も使用しない NUMA ノードで設定されていると、仮想マシンが起動しません。したがって、Red Hat は、RHEL 8 では、そういった空の NUMA ノードを持つ IBM POWER 仮想マシンを使用しないことを強く推奨しています。

(BZ#1651474)

AMD EPYC でホストパススルーモードを使用する際に、SMT CPU トポロジーが仮想マシンで検出されません。

AMD EPYC ホストで行われた CPU ホストパススルーモードで仮想マシンを起動すると、TOPOEXT 機能フラグは存在しません。したがって、仮想マシンは、コアごとに複数のスレッドを持つ仮想 CPU トポロジーを検出できません。この問題を回避するには、ホストパススルーの代わりに EPYC CPU モデルを使用して仮想マシンを起動します。

(BZ#1740002)

RHEL 8.2 仮想マシンのディスク識別子は、仮想マシンの再起動で変わる可能性があります。

Hyper-V ハイパーバイザーのゲストオペレーティングシステムとして RHEL 8.2 で仮想マシン (VM) を使用する場合は、仮想マシンの再起動時に仮想マシンの仮想ディスクのデバイス識別子が変わることがあります。たとえば、最初は /dev/sda として識別されていたディスクが、dev/sdb になる場合があります。これにより、仮想マシンが起動に失敗し、仮想マシンのディスクを参照するスクリプトが動作しなくなる可能性があります。

この問題を回避するには、Red Hat は、仮想マシンのディスクに永続的な名前を設定することを強く推奨します。詳細は、Microsoft Azure のドキュメント(https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-device-names-problems)を参照して ください。

(BZ#1777283)

多数の virtio-blk ディスクを使用すると、仮想マシンが起動しないことがあります。

多数の virtio-blk デバイスを仮想マシンに追加すると、プラットフォームで利用可能な割り込みベクトルの数が使い切られる可能性があります。これが発生すると、仮想マシンのゲスト OS は起動できず、dracut-initqueue[392]: Warning: Could not boot エラーが表示されます。

(BZ#1719687)

virtio-blk を使用して仮想マシンに LUN デバイスを割り当てると機能しません。

q35 マシンタイプは、移行用の virtio 1.0 デバイスをサポートしないため、RHEL 8 では virtio 1.0 で非推奨となった機能はサポートされません。特に、RHEL 8 ホストで virtio-blk デバイスから SCSI コマンドを送信することはできません。したがって、virtio-blk コントローラーを使用する場合は、物理ディスクを LUN デバイスとして仮想マシンに割り当てると失敗します。

物理ディスクをゲストオペレーティングシステムを通して渡すことは引き続き可能ですが、device='lun' オプションではなく、device='disk' オプションで設定する必要があることに留意してください。

(BZ#1777138)

RHEL 7-ALT ホストから RHEL 8 への POWER9 ゲストの移行に失敗する

現在のリリースでは、RHEL 7-ALT ホストシステムから RHEL 8 に POWER9 仮想マシンを移行すると、「Migration status: active」のステータスで応答がなくなります。

この問題を回避するには、RHEL 7-ALT ホストで Transparent Huge Pages (THP) を無効にすることで、移行が正常に完了します。

(BZ#1741436)

このページには機械翻訳が使用されている場合があります (詳細はこちら)。