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 に変更されます。

(BZ#1750862)

特定の 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 ユーティリティーがクラウド環境の正しいゲートウェイを検出できません。これにより、ユーティリティーは誤ったデフォルトルートを設定し、接続が破損していました。現在利用できる回避策はありません。

(BZ#1912236)

複数のゲストディスクで 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 キーを削除して正しく生成できるようになります。

(BZ#1957532)

バックアップ 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 キーを削除して正しく生成できるようになります。

(BZ#1963981)