8.18. クラウド環境の RHEL
Nutanix AHV で LVM を使用する RHEL 9 仮想マシンのクローンを作成または復元すると、ルート以外のパーティションが表示されなくなる
Nutanix AHV ハイパーバイザーをホストとする仮想マシン (VM) で RHEL 9 ゲストオペレーティングシステムを実行する場合、スナップショットから VM を復元するか VM をクローンすると、ゲストが論理ボリューム管理 (LVM) を使用している場合は VM 内の非ルートパーティションを消失させることがあります。これにより、以下の問題が発生します。
- スナップショットから仮想マシンを復元すると、仮想マシンは起動できず、緊急モードに入ります。
- クローンを作成して作成した仮想マシンは起動できず、緊急モードに入ります。
これらの問題を回避するには、仮想マシンの緊急モードで以下を行います。
-
以下の LVM システムデバイスファイルを削除します:
rm/etc/lvm/devices/system.devices -
LVM デバイス設定を再作成します:
vgimportdevices -a - 仮想マシンを再起動します。
これにより、クローン化または復元された VM を正しく起動できます。
または、問題が発生しないようにするには、VM のクローンを作成する前、または VM のスナップショットを作成する前に、次の手順を実行します。
-
/etc/lvm/lvm.confファイル内のuse_devicesfile = 0行のコメントを解除します。 initramfsを再生成します。これを行うには、仮想マシンで次の手順を実行し、<kernelVersion> を再構築するカーネルの完全なバージョンに置き換えます。現在の
initramfs設定をバックアップします。# cp /boot/initramfs-<kernelVersion>.img /boot/initramfs-<kernelVersion>.img.bakinitramfsをビルドします。# dracut -f /boot/initramfs-<kernelVersion>.img <kernelVersion>
- 仮想マシンを再起動して、正常に起動したことを確認します。
Jira:RHELPLAN-114103[1]
ESXi で RHEL 9 ゲストをカスタマイズすると、ネットワークの問題が発生することがある
現在、VMware ESXi ハイパーバイザーでの RHEL 9 ゲストオペレーティングシステムのカスタマイズは、NetworkManager キーファイルでは正しく機能しません。その結果、ゲストがそのようなキーファイルを使用している場合、IP アドレスやゲートウェイなどのネットワーク設定が正しくなくなります。
回避策: VMware のナレッジベース を参照してください。
Jira:RHELPLAN-106947[1]
cloud-init によってプロビジョニングされ、NFSv3 マウントエントリーで設定された場合、Azure で RHEL インスタンスが起動しない
現在、仮想マシンが cloud-init ツールによってプロビジョニングされ、仮想マシンのゲストオペレーティングシステムで /etc/fstab ファイルに NFSv3 マウントエントリーがある場合、Microsoft Azure クラウドプラットフォームで RHEL 仮想マシンの起動に失敗します。現在、この問題に対する回避策はありません。
Jira:RHELPLAN-120807[1]
kmemleak オプションが有効になっていると、大規模な仮想マシンがデバッグカーネルで起動できない場合がある
RHEL 9 仮想マシンをデバッグカーネルで起動しようとすると、マシンカーネルが kmemleak=on 引数を使用している場合、次のエラーで起動が失敗することがあります。
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.
この問題は主に、ブートシーケンスに多くの時間を費やす大規模な仮想マシンに影響します。
回避策: マシン上の /etc/fstab ファイルを編集し、/boot および /boot/efi マウントポイントにさらなるタイムアウトオプションを追加します。以下に例を示します。
UUID=e43ead51-b364-419e-92fc-b1f363f19e49 /boot xfs defaults,x-systemd.device-timeout=600,x-systemd.mount-timeout=600 0 0
UUID=7B77-95E7 /boot/efi vfat defaults,uid=0,gid=0,umask=077,shortname=winnt,x-systemd.device-timeout=600,x-systemd.mount-timeout=600 0 2
Jira:RHELDOCS-16979[1]
Hyper-V enlightenments を有効にしても CPU の最適化が改善されない場合がある
Windows ゲストオペレーティングシステムを使用する仮想マシン (VM) では、Hyper-V enlightenments を有効にしても、仮想マシンの CPU 使用率が期待どおりに改善されない場合があります。現在、この問題に対する回避策はありません。
Jira:RHEL-17331[1]
メモリーサイズがメモリーブロックサイズと一致していない場合でも、VMware でメモリーのホットプラグが可能
現在、アタッチされたメモリーサイズが個々のメモリーブロックのサイズと一致していない場合でも、VMware ハイパーバイザー上の RHEL 9 ゲストに対して、メモリーのホットプラグを試みることが可能です。ただし、この方法でメモリーをアタッチすると、Block size unaligned hotplug range エラーが発生し、常に失敗します。
回避策: ゲスト上で設定されたメモリーブロックサイズで割り切れるメモリーのみをホットプラグしてください。メモリーブロックサイズを取得するには、lsmem コマンドを使用します。詳細は、Red Hat ナレッジベースの記事 を参照してください。
Jira:RHEL-81748[1]
KVM 仮想化と OVMF を備えたネストされた仮想マシンは、AMD EPYC プロセッサーを使用すると Azure または Hyper-V で起動に失敗する
AMD EPYC プロセッサーを使用している Azure クラウドまたは Hyper-V 環境において、KVM 仮想化を有効にした RHEL 仮想マシン上で、Open Virtual Machine Firmware (OVMF) を使用したネストされた仮想マシンは起動に失敗します。仮想マシンは起動に失敗し、次のログメッセージが表示されます。
Code=qemu-kvm: ../hw/core/cpu-sysemu.c:76 Aborted (core dumped) .
回避策: AMD EPYC プロセッサーを使用せずに起動してみてください。
Jira:RHEL-29919[1]
BIOS または UEFI でサポートされている Hyper-V Windows Server 2016 仮想マシンは、ホストが AMD EPYC CPU プロセッサーを使用している場合、起動に失敗する
Hyper-V が有効化されている設定では、Hyper-V Windows Server 2016 仮想マシンは AMD EPYC CPU ホスト上で起動できません。
回避策: 次のログメッセージを確認します。
kvm: Booting SMP Windows KVM VM with !XSAVES && XSAVEC.
If it fails to boot try disabling XSAVEC in the VM config.
また、Hyper-V Windows Server 2016 仮想マシンを起動するために、xsavec=off の -cpu cmdline への追加を試みます。
Jira:RHEL-38957[1]
Azure Confidential 仮想マシンで kdump の完了に失敗する
Azure Confidential VM インスタンスの Red Hat Enterprise Linux 仮想マシンでカーネルクラッシュが発生した場合 (この場合は DCv5 と ECv5 シリーズ)、kdump プロセスが完了せず、仮想マシンが応答しなくなることがあります。その結果、強制的な再起動後に、vmcore-incomplete ファイルが作成されます。
Jira:RHEL-70228[1]