10.16. 클라우드 환경의 RHEL
Kdump가 Azure 및 Hyper-V에서 시작되지 않는 경우가 있습니다.
Microsoft Azure 또는 Hyper-V 하이퍼바이저에서 호스팅되는 RHEL 8 게스트 운영 체제에서는 실행 후 알림기를 활성화하면 kdump 커널을 시작할 수 없는 경우가 있습니다.
이 문제를 해결하려면 크래시 kexec 후 알림기를 비활성화합니다.
# echo N > /sys/module/kernel/parameters/crash_kexec_post_notifiers
(BZ#1865745)
VMWare 호스트의 RHEL 8 가상 머신에서 고정 IP 설정이 작동하지 않음
현재 RHEL 8을 VMWare 호스트에서 VM(가상 머신)의 게스트 운영 체제로 사용할 때 DatasourceOVF 기능이 제대로 작동하지 않습니다. 결과적으로 cloud-init 유틸리티를 사용하여 VM의 네트워크를 고정 IP로 설정한 다음 VM을 재부팅하면 VM의 네트워크가 DHCP로 변경됩니다.
특정 NIC가 있는 코어 덤프 RHEL 8 가상 머신을 Azure의 원격 머신에 추가하는 데 예상보다 시간이 오래 걸립니다.
현재 kdump 유틸리티를 사용하여 Microsoft Azure 하이퍼바이저에 RHEL 8 가상 머신(VM)의 코어 덤프 파일을 원격 머신에 저장하면 VM이 가속화된 네트워킹이 활성화된 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 VM을 부팅할 때 SCSI 호스트 주소가 변경될 수 있습니다.
현재 Hyper-V 하이퍼바이저에서 RHEL 8 가상 머신(VM)을 부팅할 때 일부 경우 호스트 , 버스, 대상, LBTL(Lun) SCSI 주소의 호스트 부분이 변경됩니다. 결과적으로 VM의 HBTL SCSI 식별 또는 장치 노드로 설정된 자동화된 작업이 일관적으로 작동하지 않습니다. VM에 디스크가 두 개 이상 있거나 디스크에 크기가 다른 경우 발생합니다.
문제를 해결하려면 다음 방법 중 하나를 사용하여 킥스타트 파일을 수정하십시오.
방법 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])다음과 같이 hyper-v 호스트에서 이 스크립트를 사용할 수 있습니다.
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
나중에 디스크 값은 다음과 같이 kickstart 파일에서 사용할 수 있습니다.
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
이러한 값은 각 가상 디스크에 고유하므로 각 VM 인스턴스에 대해 구성을 수행해야 합니다. 따라서 %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 인스턴스에서 네트워크 성능이 낮습니다.
AWS(Amazon Web Services) ARM64 인스턴스에서 실행되는 VM(가상 머신)에서 RHEL 8을 게스트 운영 체제로 사용하는 경우, iommu.strict=1 커널 매개 변수를 사용하거나 no 예상 네트워크 성능보다 낮습니다.
iommu.strict 매개 변수를 정의할 때 VM은
이 문제를 해결하려면 매개 변수를 to iommu.strict=0 으로 변경합니다. 그러나 VM의 보안도 줄일 수 있습니다.
(BZ#1836058)
FIPS 모드가 활성화된 경우 RHEL 8 게스트 최대 절전 실패
현재 VM이 FIPS 모드를 사용하는 경우 RHEL 8을 게스트 운영 체제로 사용하는 VM(가상 머신)을 최대 절전 모드로 설정할 수 없습니다.
(BZ#1934033, BZ#1944636)
백업 AMI에서 생성된 EC2 인스턴스에서 SSH 키가 올바르게 생성되지 않습니다.
현재 백업 AMI(Amazon Machine Image)에서 RHEL 8의 새 Amazon EC2 인스턴스를 만들 때 cloud-init 는 VM에서 기존 SSH 키를 삭제하지만 새 SSH 키를 생성하지 않습니다. 따라서 경우에 따라 VM을 호스트에 연결할 수 없습니다.
이 문제를 해결하려면 cloud.cgf 파일을 편집하고 "ssh_genkeytypes: ~" 행을 ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519'] 로 변경합니다.
이렇게 하면 설명된 환경에서 RHEL 8 VM을 프로비저닝할 때 SSH 키를 올바르게 삭제하고 생성할 수 있습니다.
백업 AMI에서 생성된 EC2 인스턴스에서 SSH 키가 올바르게 생성되지 않습니다.
현재 백업 AMI(Amazon Machine Image)에서 RHEL 8의 새 Amazon EC2 인스턴스를 만들 때 cloud-init 는 VM에서 기존 SSH 키를 삭제하지만 새 SSH 키를 생성하지 않습니다. 따라서 경우에 따라 VM을 호스트에 연결할 수 없습니다.
이 문제를 해결하려면 cloud.cgf 파일을 편집하고 "ssh_genkeytypes: ~" 행을 ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519'] 로 변경합니다.
이렇게 하면 설명된 환경에서 RHEL 8 VM을 프로비저닝할 때 SSH 키를 올바르게 삭제하고 생성할 수 있습니다.
