10.16. クラウド環境の RHEL
Azure および Hyper-V で kdump が起動しないことがあります。
Microsoft Azure または Hyper-V ハイパーバイザーでホストされている RHEL 8 ゲストオペレーティングシステムでは、実行後通知が有効な場合に kdump カーネルの起動が失敗することがあります。
この問題を回避するには、crash kexec post notifiers を無効にします。
# echo N > /sys/module/kernel/parameters/crash_kexec_post_notifiers
(BZ#1865745)
VMWare ホストの RHEL 8 仮想マシンで静的 IP を設定できませんでした。
現在、VMWare ホストで RHEL 8 を仮想マシンのゲストオペレーティングシステムとして使用すると、DatasourceOVF 機能は正しく機能しません。これにより、cloud-init ユーティリティーを使用して、仮想マシンのネットワークを静的 IP に設定し、仮想マシンを再起動すると、仮想マシンのネットワークが DHCP に変更されます。
特定の NIC を搭載した RHEL 8 仮想マシンの Azure のリモートマシンへのコアダンプには、予想よりも長い時間がかかっていました。
現在、kdump ユーティリティーを使用した、Microsoft Azure ハイパーバイザー上の RHEL 8 仮想マシンのコアダンプファイルのリモートマシンへの保存は、仮想マシンがネットワークアクセラレーションを有効化して NIC を使用している場合は適切に動作しません。これにより、ダンプファイルは即座にではなく、約 200 秒後に保存されます。さらに、ダンプファイルを保存する前に、以下のエラーメッセージがコンソールに記録されます。
device (eth0): linklocal6: DAD failed for an EUI-64 address
(BZ#1854037)
nm-cloud-setup ユーティリティーは、Microsoft Azure に誤ったデフォルトルートを設定します。
Microsoft Azure では、nm-cloud-setup ユーティリティーがクラウド環境の正しいゲートウェイを検出できません。これにより、ユーティリティーは誤ったデフォルトルートを設定し、接続が破損していました。現在利用できる回避策はありません。
複数のゲストディスクで Hyper-V 仮想マシンを起動する際に、SCSI ホストアドレスが変更することがあります。
現在、Hyper-V ハイパーバイザーで RHEL 8 仮想マシンを起動すると、場合によっては、Host, Bus, Target, Lun (HBTL) SCSI アドレスのホスト部分が変わることがあります。したがって、仮想マシンで HBTL SCSI 識別またはデバイスノードで設定した自動タスクは一貫して動作しません。これは、仮想マシンに複数のディスクがある場合、またはディスクに異なるサイズがある場合に発生します。
この問題を回避するには、以下のいずれかの方法でキックスタートファイルを変更します。
方法 1: SCSI デバイスに永続的な識別子を使用
たとえば、以下の powershell スクリプトを使用すると、特定のデバイス識別子を特定できます。
# Output what the /dev/disk/by-id/<value> for the specified hyper-v virtual disk.
# Takes a single parameter which is the virtual disk file.
# Note: kickstart syntax works with and without the /dev/ prefix.
param (
[Parameter(Mandatory=$true)][string]$virtualdisk
)
$what = Get-VHD -Path $virtualdisk
$part = $what.DiskIdentifier.ToLower().split('-')
$p = $part[0]
$s0 = $p[6] + $p[7] + $p[4] + $p[5] + $p[2] + $p[3] + $p[0] + $p[1]
$p = $part[1]
$s1 = $p[2] + $p[3] + $p[0] + $p[1]
[string]::format("/dev/disk/by-id/wwn-0x60022480{0}{1}{2}", $s0, $s1, $part[4])このスクリプトは、ハイパーホストで使用することができます。以下に例を示します。
PS C:\Users\Public\Documents\Hyper-V\Virtual hard disks> .\by-id.ps1 .\Testing_8\disk_3_8.vhdx /dev/disk/by-id/wwn-0x60022480e00bc367d7fd902e8bf0d3b4 PS C:\Users\Public\Documents\Hyper-V\Virtual hard disks> .\by-id.ps1 .\Testing_8\disk_3_9.vhdx /dev/disk/by-id/wwn-0x600224807270e09717645b1890f8a9a2
その後、以下のようにキックスタートファイルでディスクの値を使用できます。
part / --fstype=xfs --grow --asprimary --size=8192 --ondisk=/dev/disk/by-id/wwn-0x600224807270e09717645b1890f8a9a2 part /home --fstype="xfs" --grow --ondisk=/dev/disk/by-id/wwn-0x60022480e00bc367d7fd902e8bf0d3b4
これらの値は仮想ディスクごとに固有であるため、仮想マシンインスタンスごとに設定を行う必要があります。そのため、%include 構文を使用して、ディスク情報を別のファイルに配置すると便利です。
方法 2: デバイス選択をサイズで設定
サイズに基づいてディスク選択を設定するキックスタートファイルには、以下のような行を含める必要があります。
...
# Disk partitioning information is supplied in a file to kick start
%include /tmp/disks
...
# Partition information is created during install using the %pre section
%pre --interpreter /bin/bash --log /tmp/ks_pre.log
# Dump whole SCSI/IDE disks out sorted from smallest to largest ouputting
# just the name
disks=(`lsblk -n -o NAME -l -b -x SIZE -d -I 8,3`) || exit 1
# We are assuming we have 3 disks which will be used
# and we will create some variables to represent
d0=${disks[0]}
d1=${disks[1]}
d2=${disks[2]}
echo "part /home --fstype="xfs" --ondisk=$d2 --grow" >> /tmp/disks
echo "part swap --fstype="swap" --ondisk=$d0 --size=4096" >> /tmp/disks
echo "part / --fstype="xfs" --ondisk=$d1 --grow" >> /tmp/disks
echo "part /boot --fstype="xfs" --ondisk=$d1 --size=1024" >> /tmp/disks
%end(BZ#1906870)
RHEL 8 仮想マシンの場合、AWS ARM64 インスタンスでネットワークパフォーマンスが低下する。
Amazon Web Services (AWS) ARM64 インスタンスで実行される仮想マシンで RHEL 8 をゲストオペレーティングシステムとして使用する場合は、iommu.strict=1 カーネルパラメーターが使用されるとき、または、iommu.strict カーネルパラメーターが定義されないとき、仮想マシンのネットワークパフォーマンスは予想されるよりも低くなります。
この問題を回避するには、パラメーターを iommu.strict=0 に変更します。ただし、これにより、仮想マシンのセキュリティーも減らすこともできます。
(BZ#1836058)
FIPS モードが有効な場合に RHEL 8 ゲストが休止状態に
現在、仮想マシンが FIPS モードを使用している場合は、RHEL 8 をゲストオペレーティングシステムとして使用する仮想マシンをハイバネートすることはできません。
(BZ#1934033, BZ#1944636)
バックアップ AMI から作成された EC2 インスタンスで SSH キーが正しく生成されない
現在、バックアップ Amazon Machine Image (AMI) から RHEL 8 の新しい Amazon EC2 インスタンスを作成する場合、cloud-init は仮想マシン上の既存の SSH キーを削除しますが、新しい SSH キーは作成しません。その結果、仮想マシンがホストに接続できない場合があります。
この問題を回避するには、cloud.cgf ファイルを編集し、ssh_genkeytypes: ~行を ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519'] に変更します。
これにより、上記の状況で RHEL 8 仮想マシンをプロビジョニングする際に、SSH キーを削除して正しく生成できるようになります。
バックアップ AMI から作成された EC2 インスタンスで SSH キーが正しく生成されない
現在、バックアップ Amazon Machine Image (AMI) から RHEL 8 の新しい Amazon EC2 インスタンスを作成する場合、cloud-init は仮想マシン上の既存の SSH キーを削除しますが、新しい SSH キーは作成しません。その結果、仮想マシンがホストに接続できない場合があります。
この問題を回避するには、cloud.cgf ファイルを編集し、ssh_genkeytypes: ~行を ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519'] に変更します。
これにより、上記の状況で RHEL 8 仮想マシンをプロビジョニングする際に、SSH キーを削除して正しく生成できるようになります。
