6.7.17. 仮想化
cloud-init を使用した Microsoft Azure での仮想マシンのプロビジョニングに失敗します。
現在、cloud-init ユーティリティーを使用して、Microsoft Azure プラットフォームで RHEL 8 仮想マシンをプロビジョニングすることができません。この問題を回避するには、以下のいずれかの方法を使用します。
-
cloud-initの代わりにWALinuxAgentパッケージを使用して、Microsoft Azure に仮想マシンをプロビジョニングします。 以下の設定を
/etc/NetworkManager/NetworkManager.confファイルの[main]セクションに追加します。[main] dhcp=dhclient
(BZ#1641190)
一部の場合において RHEL 7 ホストの RHEL 8 仮想マシンは、1920x1200 を超える解像度で表示できません。
現在、RHEL 7 ホストシステムで RHEL 8 仮想マシンを実行している場合は、kiosk モードでアプリケーションを実行するなど、仮想マシンのグラフィカル出力を表示する方法によっては、1920x1200 を超える解像度を表示することはできません。そのため、ホストハードウェアがより高い解像度に対応している場合でも、この方法での仮想マシンを表示解像度は最大 1920x1200 のみとなります。
(BZ#1635295)
Windows Server 2019 ホストの RHEL 8 仮想マシンで GUI ディスプレイのパフォーマンスが下がります。
Windows Server 2019 ホストのグラフィカルモードで RHEL 8 をゲストオペレーティングシステムとして使用すると、GUI ディスプレイのパフォーマンスが下がり、ゲストのコンソール出力に現在必要なよりも長い時間がかかります。
これは、Windows 2019 ホストで既知の問題で、Microsoft が修正を保留しています。この問題を回避するには、SSH を使用してゲストに接続するか、ホストとして Windows Server 2016 を使用します。
(BZ#1706541)
RHEL 仮想マシンのインストールが失敗することがあります。
特定の状況下では、virt-install ユーティリティーを使用して作成した RHEL 7 および RHEL 8 仮想マシンが、--location オプションを指定すると起動に失敗します。
この問題を回避するには、代わりに --extra-args オプションを指定して、ネットワークが到達可能なインストールツリーを指定します。以下にその例を示します。
--extra-args="inst.repo=https://some/url/tree/path"
これにより、RHEL インストーラーはインストールファイルを正しく検出できるようになります。
(BZ#1677019)
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)
cloud-init を使用して ESXi 仮想マシンをカスタマイズし、VM を再起動すると、IP 設定が失われ、仮想マシンの起動が非常に遅くなります。
現在、cloud-init サービスを使用して VMware ESXi ハイパーバイザーで実行している仮想マシンを修正し、静的 IP を使用して、仮想マシンをクローンすると、新しいクローンの仮想マシンを再起動するのにかかる時間が非常に長くなる場合があります。これは、cloud-init が仮想マシンの静的 IP を DHCP に書き換えてから、利用可能なデータソースを検索しているからです。
この問題を回避するには、仮想マシンを最初に起動してから cloud-init をアンインストールします。その結果、その後の再起動の速度は低下しません。
(BZ#1666961, BZ#1706482)
RHEL 8 仮想マシンが、対応するホストで起動できません。
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>
IBM POWER 仮想マシンが、ゼロメモリーの NUMA ノードで正常に動作しません。
現在、RHEL 8 ホストで実行している IBM POWER 仮想マシン (VM) が、ゼロメモリー (memory='0') を使用する NUMA ノードで設定されていると、仮想マシンが起動しません。したがって、Red Hat は、RHEL 8 ではゼロメモリー NUMA ノードを持つ IBM POWER 仮想マシンを使用しないことを強く推奨しています。
(BZ#1651474)
RHEL 7-ALT ホストから RHEL 8 への POWER9 ゲストの移行に失敗する
現在のリリースでは、RHEL 7-ALT ホストシステムから RHEL 8 に POWER9 仮想マシンを移行すると、Migration status: active のステータスで応答がなくなります。
この問題を回避するには、RHEL 7-ALT ホストで Transparent Huge Pages (THP) を無効にすることで、移行が正常に完了します。
(BZ#1741436)
AMD EPYC でホストパススルーモードを使用する際に、SMT CPU トポロジーが仮想マシンで検出されない
AMD EPYC ホストで行われた CPU ホストパススルーモードで仮想マシンを起動すると、TOPOEXT 機能フラグは存在しません。したがって、仮想マシンは、コアごとに複数のスレッドを持つ仮想 CPU トポロジーを検出できません。この問題を回避するには、ホストパススルーの代わりに EPYC CPU モデルを使用して仮想マシンを起動します。
多くの virtio-blk ディスクを使用すると、仮想マシンが起動しないことがあります。
多数の virtio-blk デバイスを仮想マシンに追加すると、プラットフォームで利用可能な割り込みベクトルの数が使い切られる可能性があります。これが発生すると、仮想マシンのゲスト OS は起動できず、dracut-initqueue[392]: Warning: Could not boot エラーが表示されます。