10.18. 가상화
경우에 따라 https 또는 ssh를 통한 가상 머신 설치 실패
현재 https 또는 ssh 연결을 통해 ISO 소스에서 게스트 운영 체제(OS)를 설치하려고 할 때 virt-install 유틸리티가 실패합니다(예: virt-install --cdrom https://example/path/to/image.iso ). VM(가상 머신)을 생성하는 대신 설명된 작업은 메시지를 모니터링하는 동안 내부 오류(프로세스 종료)로 예 기치 않게 종료됩니다.
마찬가지로, RHEL 9 웹 콘솔을 사용하여 게스트 운영 체제를 설치하는 데 실패하고 https 또는 ssh URL 또는 오류가 표시됩니다.
다운로드 OS 기능을 사용하는 경우 알 수 없는 드라이버 'https'
해결방법: https 및 ssh 프로토콜 지원을 활성화하려면 호스트에 qemu-kvm-block-curl 및 qemu-kvm-block-ssh 를 설치합니다. 또는 다른 연결 프로토콜 또는 다른 설치 소스를 사용합니다.
Jira:RHELPLAN-99854[1]
가상 머신에서 NVIDIA 드라이버를 사용하면 Wayland가 비활성화됨
현재 NVIDIA 드라이버는 Wayland 그래픽 세션과 호환되지 않습니다. 결과적으로 NVIDIA 드라이버를 사용하는 RHEL 게스트 운영 체제는 자동으로 Wayland를 비활성화하고 대신 Xorg 세션을 로드합니다. 이는 주로 다음 시나리오에서 발생합니다.
- NVIDIA GPU 장치를 RHEL VM(가상 머신)에 전달하는 경우
- NVIDIA vGPU 미디어 장치를 RHEL VM에 할당하는 경우
현재 이 문제에 대한 해결방법이 없습니다.
Jira:RHELPLAN-117234[1]
Nutanix AHV에서 LVM을 사용하는 RHEL 9 가상 머신을 복제하거나 복원하면 루트가 아닌 파티션이 사라집니다.
Nutanix AHV 하이퍼바이저에서 호스팅되는 VM(가상 머신)에서 RHEL 9 게스트 운영 체제를 실행하는 경우 스냅샷에서 VM을 복원하거나 VM 복제로 인해 게스트가 LVM(Logical Volume Management)을 사용하는 경우 VM의 루트가 아닌 파티션이 사라집니다. 결과적으로 다음과 같은 문제가 발생합니다.
- 스냅샷에서 VM을 복원하면 VM을 부팅할 수 없으며 대신 긴급 모드로 전환됩니다.
- 복제로 생성된 VM은 부팅할 수 없으며 대신 긴급 모드로 전환됩니다.
이러한 문제를 해결하려면 VM의 긴급 모드에서 다음을 수행합니다.
LVM 시스템 장치 파일을 제거합니다.
rm /etc/lvm/devices/system.devices
# rm /etc/lvm/devices/system.devicesCopy to Clipboard Copied! Toggle word wrap Toggle overflow LVM 장치 설정을 다시 생성합니다.
vgimportdevices -a
# vgimportdevices -aCopy to Clipboard Copied! Toggle word wrap Toggle overflow - VM 재부팅
이렇게 하면 복제 또는 복원된 VM이 올바르게 부팅될 수 있습니다.
또는 VM을 복제하거나 VM 스냅샷을 생성하기 전에 문제가 발생하지 않도록 하려면 다음을 수행합니다.
-
/etc/lvm/lvm.conf파일에서use_devicesfile = 0행의 주석을 제거합니다. initramfs를 다시 생성합니다. 이렇게 하려면 VM에서 다음 단계를 사용하고 <
kernelVersion>을 다시 빌드하려는 커널의 전체 버전으로 바꿉니다.현재
initramfs구성을 백업합니다.cp /boot/initramfs-<kernelVersion>.img /boot/initramfs-<kernelVersion>.img.bak
# cp /boot/initramfs-<kernelVersion>.img /boot/initramfs-<kernelVersion>.img.bakCopy to Clipboard Copied! Toggle word wrap Toggle overflow build
initramfs:dracut -f /boot/initramfs-<kernelVersion>.img <kernelVersion>
# dracut -f /boot/initramfs-<kernelVersion>.img <kernelVersion>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- VM을 재부팅하여 성공적으로 부팅되었는지 확인합니다.
Jira:RHELPLAN-114103[1]
AMD Milan 시스템에서 Milan VM CPU 유형을 사용할 수 없는 경우가 있습니다.
특정 AMD Milan 시스템에서는 Enhanced REP MOVSB(erms) 및 Fast Short REP MOVSB(fsrm) 기능 플래그가 기본적으로 BIOS에서 비활성화되어 있습니다. 결과적으로 Milan CPU 유형을 이러한 시스템에서 사용할 수 없습니다. 또한 다른 기능 플래그 설정이 있는 Milan 호스트 간에 VM 실시간 마이그레이션이 실패할 수 있습니다.
해결방법: 호스트의 BIOS에서 수동으로 erms 및 fsrm 을 설정합니다.
Jira:RHELPLAN-119655[1]
장애 조치 설정이 있는 hostdev 인터페이스는 핫 플러그 해제된 후 핫 플러그할 수 없습니다
실행 중인 VM(가상 머신)에서 장애 조치 구성을 사용하여 hostdev 네트워크 인터페이스를 제거한 후 현재 실행 중인 동일한 VM에 다시 연결할 수 없습니다. 현재 이 문제에 대한 해결방법이 없습니다.
장애 조치 VF가 있는 VM의 실시간 복사 후 마이그레이션 실패
현재 VM에서 VF(가상 기능) 페일오버 기능이 활성화된 장치를 사용하는 경우 실행 중인 VM(가상 머신)을 post-copy가 실패합니다.
해결방법: 마이그레이션 후 복사가 아닌 표준 마이그레이션 유형을 사용합니다.
호스트 네트워크는 실시간 마이그레이션 중에 VF를 사용하여 VM을 ping할 수 없습니다.
가상 SR-IOV 소프트웨어를 사용하는 VM(가상 기능)과 같이 구성된 VF(가상 기능)를 사용하여 VM(가상 머신)을 실시간 마이그레이션하는 경우 VM의 네트워크가 다른 장치에 표시되지 않으며 ping 과 같은 명령을 통해 VM에 연결할 수 없습니다. 그러나 마이그레이션이 완료되면 문제가 더 이상 발생하지 않습니다.
AVX를 비활성화하면 VM을 부팅할 수 없게 됩니다.
AVX(Advanced Vector Extensions) 지원이 포함된 CPU를 사용하는 호스트 시스템에서 AVX가 명시적으로 비활성화된 VM을 부팅하려고 시도하면 현재 VM에서 커널 패닉이 트리거됩니다. 현재 이 문제에 대한 해결방법이 없습니다.
Jira:RHELPLAN-97394[1]
마이그레이션된 IdM 사용자는 일치하지 않는 도메인 SID로 인해 로그인할 수 없을 수 있습니다.
ipa migrate-ds 스크립트를 사용하여 IdM 배포에서 사용자를 다른 IdM 배포로 마이그레이션한 경우 이전 SID(보안 식별자)에 현재 IdM 환경의 도메인 SID가 없기 때문에 IdM 서비스를 사용하는 데 문제가 있을 수 있습니다. 예를 들어 해당 사용자는 kinit 유틸리티를 사용하여 Kerberos 티켓을 검색할 수 있지만 로그인할 수 없습니다.
해결방법: 다음 지식 베이스 문서를 참조하십시오 . 마이그레이션된 IdM 사용자는 일치하지 않는 도메인 SID로 인해 로그인할 수 없습니다.
Jira:RHELPLAN-109613[1]
네트워크 인터페이스 재설정 후 Windows VM에서 IP 주소를 얻지 못했습니다
경우에 따라 자동 네트워크 인터페이스를 재설정한 후 Windows 가상 머신이 IP 주소를 얻지 못하는 경우가 있습니다. 결과적으로 VM이 네트워크에 연결되지 못합니다.
해결방법: Windows 장치 관리자에서 네트워크 어댑터 드라이버를 비활성화하고 다시 활성화합니다.
Windows Server 2016 VM이 vCPU 핫플러그 후 작동하지 않는 경우가 있습니다.
현재 Windows Server 2016 게스트 운영 체제에서 실행 중인 VM(가상 머신)에 vCPU를 할당하면 VM이 예기치 않게 종료되거나 응답하지 않거나 재부팅과 같은 다양한 문제가 발생할 수 있습니다. 현재 이 문제에 대한 해결방법이 없습니다.
Jira:RHELPLAN-63771[1]
NVIDIA 패스스루 장치가 있는 VM에서 중복 오류 메시지
RHEL 9.2 이상 운영 체제가 있는 Intel 호스트 머신을 사용하는 경우 NVDIA GPU 장치를 통해 전달되는 VM(가상 머신)은 다음 오류 메시지를 기록하는 경우가 많습니다.
Spurious APIC interrupt (vector 0xFF) on CPU#2, should never happen.
Spurious APIC interrupt (vector 0xFF) on CPU#2, should never happen.
그러나 이 오류 메시지는 VM 기능에 영향을 미치지 않으며 무시할 수 있습니다. 자세한 내용은 Red Hat knoweldgeBase 를 참조하십시오.
Jira:RHELPLAN-141042[1]
호스트에서 OVS 서비스를 다시 시작하면 실행 중인 VM에서 네트워크 연결이 차단될 수 있습니다.
OVS(Open vSwitch) 서비스가 호스트에서 다시 시작되거나 중단되면 이 호스트에서 실행 중인 VM(가상 머신)은 네트워킹 장치의 상태를 복구할 수 없습니다. 결과적으로 VM이 패킷을 수신하지 못할 수 있습니다.
이 문제는 virtio 네트워킹 스택에서 패키징된 virtqueue 형식을 사용하는 시스템에만 영향을 미칩니다.
해결방법: virtio 네트워킹 장치 정의에서 packed=off 매개 변수를 사용하여 팩된 virtqueue를 비활성화합니다. 패키징된 virtqueue가 비활성화된 상태에서 네트워킹 장치의 상태는 RAM에서 복구할 수 있습니다.
중단된 VM 마이그레이션 복구에 실패할 수 있습니다.
VM(가상 머신)의 복사 후 마이그레이션이 중단되고 수신되는 동일한 포트에서 즉시 다시 시작되면 마이그레이션이 실패할 수 있습니다. 이미 사용 중인 주소
해결방법: 복사 후 마이그레이션을 다시 시작하거나 마이그레이션 복구를 위해 다른 포트로 전환하기 전에 10초 이상 기다립니다.
AMD EPYC CPU에서 NUMA 노드 매핑이 제대로 작동하지 않음
QEMU는 AMD EPYC CPU에서 NUMA 노드 매핑을 올바르게 처리하지 않습니다. 결과적으로 NUMA 노드 구성을 사용하는 경우 이러한 CPU가 있는 VM(가상 머신)의 성능에 부정적인 영향을 미칠 수 있습니다. 또한 VM에는 부팅 중에 다음과 유사한 경고가 표시됩니다.
sched: CPU #4's llc-sibling CPU #3 is not on the same node! [node: 1 != 0]. Ignoring dependency. WARNING: CPU: 4 PID: 0 at arch/x86/kernel/smpboot.c:415 topology_sane.isra.0+0x6b/0x80
sched: CPU #4's llc-sibling CPU #3 is not on the same node! [node: 1 != 0]. Ignoring dependency.
WARNING: CPU: 4 PID: 0 at arch/x86/kernel/smpboot.c:415 topology_sane.isra.0+0x6b/0x80
해결방법: NUMA 노드 구성에 AMD EPYC CPU를 사용하지 마십시오.
Jira:RHELPLAN-150884[1]
PCIe ATS 장치는 Windows VM에서 작동하지 않음
Windows 게스트 운영 체제를 사용하여 VM(가상 머신)의 XML 구성에서 PCIe 주소 변환 서비스(ATS) 장치를 구성할 때 게스트는 VM을 부팅한 후 ATS 장치를 활성화하지 않습니다. Windows는 현재 virtio 장치에서 ATS를 지원하지 않기 때문입니다.
자세한 내용은 Red Hat KnowledgeBase 를 참조하십시오.
Jira:RHELPLAN-118495[1]
virsh blkiotune --weight 명령이 올바른 cgroup I/O 컨트롤러 값을 설정하지 못했습니다.
현재 virsh blkiotune --weight 명령을 사용하여 VM weight가 예상대로 작동하지 않습니다. 이 명령은 cgroup I/O 컨트롤러 인터페이스 파일에 올바른 io.bfq.weight 값을 설정하지 못합니다. 현재는 해결방법이 없습니다.
Jira:RHELPLAN-83423[1]
NVIDIA A16 GPU로 VM을 시작하면 호스트 GPU가 작동하지 않는 경우가 있습니다.
현재 NVIDIA A16 GPU 패스스루 장치를 사용하는 VM을 시작하면 경우에 따라 호스트 시스템의 NVIDIA A16 GPU 물리적 장치가 작동하지 않습니다.
이 문제를 해결하려면 하이퍼바이저를 재부팅하고 GPU 장치의 reset_method 를 버스로 설정합니다.
echo bus > /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method cat /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method
# echo bus > /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method
# cat /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method
bus
자세한 내용은 Red Hat 지식베이스를 참조하십시오.
Jira:RHEL-7212[1]
스토리지 오류로 인해 Windows VM이 응답하지 않을 수 있음
Windows 게스트 운영 체제를 사용하는 VM(가상 머신)에서 I/O 로드가 높은 경우 시스템이 응답하지 않는 경우도 있습니다. 이 경우 시스템은 viostor Reset to device, \Device\RaidPort3 오류가 발생했습니다. 현재 이 문제에 대한 해결방법이 없습니다.
Jira:RHEL-1609[1]
특정 PCI 장치가 있는 Windows 10 VM이 부팅 시 응답하지 않을 수 있음
현재 로컬 디스크 백엔드가 VM에 연결된 virtio-win-scsi PCI 장치가 VM에 연결된 경우 Windows 10 게스트 운영 체제를 사용하는 VM(가상 머신)이 부팅 중에 응답하지 않을 수 있습니다.
해결방법: multi_queue 옵션이 활성화된 VM을 부팅합니다.
Jira:RHEL-1084[1]
메모리 balloon 장치가 설정된 Windows 11 VM은 재부팅 중에 예기치 않게 종료될 수 있습니다.
현재 Windows 11 게스트 운영 체제 및 메모리 풍선 장치를 사용하는 VM(가상 머신)을 재부팅하면 DRIVER POWER STAT FAILURE blue-screen 오류와 함께 실패합니다.
Jira:RHEL-935[1]
virtio balloon 드라이버는 Windows 10 및 Windows 11 VM에서 작동하지 않는 경우가 있습니다.
특정 상황에서는 virtio-balloon 드라이버가 Windows 10 또는 Windows 11 게스트 운영 체제를 사용하는 VM(가상 머신)에서 올바르게 작동하지 않습니다. 결과적으로 이러한 VM은 할당된 메모리를 효율적으로 사용하지 못할 수 있습니다.
Windows VM에서 virtio 파일 시스템의 최적의 성능이 있습니다.
현재 Windows 게스트 운영 체제를 사용하는 가상 머신(virtiofs)에 virtio 파일 시스템(virtiofs)이 구성된 경우 VM의 virtiofs 성능은 Linux 게스트를 사용하는 VM에서보다 훨씬 더 심각합니다. 현재 이 문제에 대한 해결방법이 없습니다.
Jira:RHEL-1212[1]
Windows VM에서 스토리지 장치를 핫플러그 해제하는 데 실패할 수 있습니다.
Windows 게스트 운영 체제를 사용하는 VM(가상 머신)에서 VM이 실행 중일 때 스토리지 장치를 제거합니다(장치 핫 언플러그라고도 함). 결과적으로 스토리지 장치는 VM에 연결된 상태로 유지되고 디스크 관리자 서비스가 응답하지 않을 수 있습니다. 현재 이 문제에 대한 해결방법이 없습니다.
Windows VM에 CPU를 핫플러그하면 시스템 오류가 발생할 수 있습니다.
대규모 페이지가 활성화된 Windows VM(가상 머신)에 최대 CPU 수를 핫 플러그로 연결하면 게스트 운영 체제가 다음 중지 오류와 충돌할 수 있습니다.
PROCESSOR_START_TIMEOUT
PROCESSOR_START_TIMEOUT
현재 이 문제에 대한 해결방법이 없습니다.
Windows VM에서 virtio 드라이버 업데이트 실패
Windows 가상 머신(VM)에서 KVM 반가상화(virtio) 드라이버를 업데이트할 때 업데이트로 인해 마우스의 작동이 중지되고 새로 설치된 드라이버가 서명되지 않을 수 있습니다. 이 문제는 파일의 일부인 virtio -win.isovirtio-win-guest-tools 패키지에서 설치하여 virtio 드라이버를 업데이트할 때 발생합니다.
해결방법: Windows 장치 관리자를 사용하여 virtio 드라이버를 업데이트합니다.
Jira:RHEL-574[1]
vhost-kernel을 사용하는 VM에서는 TX 대기열 크기를 변경할 수 없습니다.
현재는 vhost-kernel 을 virtio 네트워크 드라이버의 백엔드로 사용하는 KVM 가상 머신(VM)에 TX 대기열 크기를 설정할 수 없습니다. 결과적으로 TX 큐에 기본값인 256만 사용할 수 있으므로 VM 네트워크 처리량을 최적화하지 못할 수 있습니다. 현재 이 문제에 대한 해결방법이 없습니다.
Jira:RHEL-1138[1]
VM에서 AMD EPYC 모델에서 spec_rstack_overflow 매개변수의 취약한 상태를 잘못 보고
호스트를 부팅하면 spec_rstack_overflow 매개변수의 취약점을 탐지하지 않습니다. 로그에 대한 매개변수를 쿼리한 후 메시지가 표시됩니다.
cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow Mitigation: Safe RET
# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
Mitigation: Safe RET
동일한 호스트에서 VM을 부팅한 후 VM은 spec_rstack_overflow 매개변수에서 취약점을 감지합니다. 로그에 대한 매개변수를 쿼리하면 다음과 같은 메시지가 표시됩니다.
cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow Vulnerable: Safe RET, no microcode
# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
Vulnerable: Safe RET, no microcode
그러나 이는 잘못된 경고 메시지이며 VM 내부의 /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow 파일의 상태를 무시할 수 있습니다.
Jira:RHEL-17614[1]
상태가 e1000e 또는 igb 모델 인터페이스로 다운 된 경우에도 VM에 link 상태가 표시됩니다.
VM을 부팅하기 전에 e1000 또는 igb 모델 네트워크 인터페이스에 대한 이더넷 링크의 상태를 아래로 설정합니다. 이 경우에도 VM이 부팅된 후에도 네트워크 인터페이스는 상태를 유지합니다. 이더넷 링크의 상태를 중단한 다음 VM을 중지했다가 다시 시작하면 VM이 자동으로 다시 설정되기 때문입니다. up 결과적으로 네트워크 인터페이스의 올바른 상태가 유지 관리되지 않습니다.
해결방법: 명령을 사용하여 VM 내부에서 네트워크 인터페이스 상태를 down 으로 설정합니다.
ip link set dev eth0 down
# ip link set dev eth0 down
또는 VM이 실행되는 동안 이 네트워크 인터페이스를 제거하고 다시 추가할 수 있습니다.
SeaBIOS는 4096바이트 섹터 크기가 있는 디스크에서 부팅할 수 없습니다.
SeaBIOS를 사용하여 4096바이트의 논리 또는 물리적 섹터 크기를 사용하는 디스크에서 VM(가상 머신)을 부팅하면 부팅 디스크가 사용 가능한 것으로 표시되지 않고 VM 부팅에 실패합니다. 이러한 디스크에서 VM을 부팅하려면 SeaBIOS 대신 UEFI를 사용합니다.
CPU당 128개 이상의 코어를 사용하는 경우 Windows Server 2019 가상 머신이 부팅 시 충돌
Windows Server 2019 게스트 운영 체제를 사용하는 VM(가상 머신)은 현재 단일 가상 CPU(vCPU)에 128개 이상의 코어를 사용하도록 구성된 경우 부팅에 실패합니다. VM은 부팅하는 대신 파란색 화면에 중지 오류를 표시합니다.
해결방법: vCPU당 128코어 미만을 사용합니다.
Jira:RHELDOCS-18863[1]
VBS 및 IOMMU 장치가 있는 Windows VM이 부팅되지 않음
VDO(가상화 기반 보안)가 활성화되고 qemu-kvm 유틸리티를 사용하여 IIOMMU(Input-Output Memory Management Unit) 장치를 사용하여 Windows VM을 부팅하면 부팅 시퀀스에 부팅 화면만 표시되어 부팅 프로세스가 불완전합니다.
해결방법: VM 도메인 XML이 다음과 같이 구성되었는지 확인합니다.
그렇지 않으면 Windows VM을 부팅할 수 없습니다.
Jira:RHEL-45585[1]
5단계 페이지 병합 및 많은 메모리가 있는 VM이 시작되지 않는 경우가 있습니다.
host-phys-bits-limit 매개변수를 49 이상으로 설정하면 다음 구성을 사용하는 VM이 부팅되지 않습니다.
- VM에는 1TB 이상의 할당된 메모리가 있습니다.
- VM은 5단계 페이지 병합 기능을 사용합니다.
- 호스트는 펌웨어에서SMM(System Management Mode)을 사용합니다.
대신 ERROR: Out of aligned Page와 함께 VM을 부팅하려고 하면 실패합니다.
해결방법: host-phys-bits-limit 매개변수를 48 이하로 설정합니다.
많은 양의 부팅 가능한 데이터 디스크가 있는 가상 머신을 시작하지 못할 수 있습니다.
많은 양의 부팅 가능한 데이터 디스크로 VM(가상 머신)을 시작하려고 하면 VM이 부팅되지 못할 수 있습니다. 일부 오류가 발생했습니다. import_mok_state() failed: Volume Full
해결방법: 부팅 가능한 데이터 디스크 수를 해제하고 하나의 시스템 디스크를 사용합니다. 시스템 디스크가 부팅 순서대로 먼저 있는지 확인하려면 XML 구성에서 시스템 디스크의 장치 정의에 부팅 순서=1 을 추가합니다. 예를 들면 다음과 같습니다.
시스템 디스크에 대해서만 부팅 순서를 설정합니다.
Windows 2025 VM은 많은 수의 vCPU로 할당된 경우 속도가 느려집니다.
32개 이상의 vCPU로 할당되면 Windows Server 2025 가상 머신(VM)이 Red Hat Enterprise Linux 호스트에서 느려집니다. 결과적으로 VM이 다수의 vCPU로 구성된 경우 부팅 중에 Windows VM이 느리게 부팅되거나 중단될 수 있습니다.
해결방법: 고유한 위험에서 해결 방법을 사용할 수 있습니다. Windows Server에서 plaformclock을 비활성화하는 vCPU 수가 적은 부팅 VM. 관리자 권한이 있는 명령 프롬프트에서 다음을 실행합니다.
bcdedit /set useplatformclock no
bcdedit /set useplatformclock no
그런 다음 VM을 종료하고 원하는 수의 vCPU로 재구성합니다. 또한 대규모 VM을 다시 시작하기 전에 hv-time 옵션이 활성화되어 있는지 확인합니다.
Jira:RHEL-62742[1]
대용량 메모리가 있는 VM은 AMDGenoa CPU를 사용하여 SEV-SNP 호스트에서 부팅할 수 없습니다.
현재 VM(가상 머신)은 4세대 AMD EPYC 프로세서(Genoa라고도 함)를 사용하는 호스트에서 부팅할 수 없으며 SEV-SNP(Secure Nested Paging) 기능이 활성화된 AMD Secure Encrypted Virtualization이 활성화되어 있습니다. 부팅 대신 VM에서 커널 패닉이 발생합니다.
Jira:RHEL-32892[1]
VirtIO-Win 번들 설치는 취소할 수 없습니다
현재 Windows 게스트 운영 체제의 VirtIO-Win 설치 관리자 번들에서 virtio-win 드라이버 설치를 시작하면 설치 중 취소 버튼을 클릭해도 올바르게 중지되지 않습니다. 설치 프로그램 마법사 인터페이스에 "Setup Failed" 화면이 표시되지만 드라이버가 설치되고 게스트의 IP 주소가 재설정됩니다.
Jira:RHEL-53962, Jira:RHEL-53965
다시 시작할 때 하이퍼바이저 시작 유형으로 설정된 Sapphire Rapids CPU에서 실행 중인 Windows VM이 부팅되지 않을 수 있습니다.
Sapphire Rapids CPU에서 실행되는 Windows VM(가상 머신)에서 하이퍼바이저 시작 유형을 auto 로 설정하면 재시작 시 VM이 부팅되지 않을 수 있습니다. 예를 들어 bcdedit /set hypervisorlaunchtype Auto 명령을 사용하여 하이퍼바이저 시작 유형을 auto 로 설정할 수 있습니다.
해결방법: Windows VM에서 하이퍼바이저 시작 유형을 auto 로 설정하지 마십시오.
Jira:RHEL-67699[1]
VBS를 사용하는 Windows 게스트에 vCPU 및 메모리 핫플러그가 작동하지 않음
현재 Windows 가상화 기반 보안(VBS)은 핫플러그 CPU 및 메모리 리소스와 호환되지 않습니다. 결과적으로 VBS가 활성화된 실행 중인 Windows 가상 머신(VM)에 메모리 또는 vCPU를 연결하려고 하면 게스트 시스템을 다시 시작한 후 VM에 리소스가 추가됩니다.
Jira:RHEL-66229, Jira:RHELDOCS-19066
NetworkManager-wait-online.service가 가속 네트워킹이 있는 Azure VM에서 시작되지 않음
SR-IOV(Single Root Input Output Virtualization)라고도 하는 가속 네트워킹 기능을 사용하여 Azure 플랫폼의 Red Hat Enterprise Linux VM을 시작하면 여러 네트워크 인터페이스 카드의 MAC 주소가 같을 수 있습니다. 결과적으로 VM이 DHCP 서버에서 IP 주소를 얻지 못할 수 있으며 부팅 시 NetworkManager-wait-online.service 가 시작되지 않을 수 있습니다.
해결방법: 기존 장치의 이름을 기존 장치 이름으로 변경하지 않도록 initscripts-rename-device 패키지를 설치하지 마십시오.
Jira:RHEL-79783[1]
EUS ( Extended Master Secret TLS Extension)가 FIPS 지원 시스템에서 적용됩니다.
RHSA-2023:3722 권고가 릴리스되면서 TLS 확장 마스터 시크릿 (ECDSA) 확장(RFC 7627)은 FIPS 지원 RHEL 9 시스템에서 TLS 1.2 연결에 필요합니다. 이는 FIPS-140-3 요구 사항에 따라 수행됩니다. TLS 1.3은 영향을 받지 않습니다.
ECDSA 또는 TLS 1.3을 지원하지 않는 레거시 클라이언트는 이제 RHEL 9 및 10에서 실행되는 FIPS 서버에 연결할 수 없습니다. 마찬가지로 FIPS 모드의 RHEL 9 및 10 클라이언트는 Cryostat 없이 TLS 1.2만 지원하는 서버에 연결할 수 없습니다. 실제로 이러한 클라이언트는 RHEL 6, RHEL 7 및 비 RHEL 레거시 운영 체제의 서버에 연결할 수 없습니다. 이는 OpenSSL의 기존 1.0.x 버전이 ECDSA 또는 TLS 1.3을 지원하지 않기 때문입니다.
또한 FIPS 지원 RHEL 클라이언트에서 VMWare ESX와 같은 하이퍼바이저에 연결하는 것은 이제 하이퍼바이저에서 TLS 1.2 없이 TLS 1.2를 사용하는 경우 공급자 루틴::ems not enabled 오류와 함께 실패합니다. 이 문제를 해결하려면 ECDSA 확장을 사용하여 TLS 1.3 또는 TLS 1.2를 지원하도록 하이퍼바이저를 업데이트합니다. VMWare vSphere의 경우 이는 버전 8.0 이상을 의미합니다.
자세한 내용은 Red Hat Enterprise Linux 9.2 이상에서 적용된 TLS 확장 "확장 마스터 시크릿"을 참조하십시오.
Jira:RHEL-13340[1]