11.16. 가상화
경우에 따라 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'
이 문제를 해결하려면 호스트에 qemu-kvm-block-curl 및 qemu-kvm-block-ssh 를 설치하여 https 및 ssh 프로토콜 지원을 활성화합니다. 또는 다른 연결 프로토콜 또는 다른 설치 소스를 사용합니다.
가상 머신에서 NVIDIA 드라이버를 사용하면 Wayland가 비활성화됨
현재 NVIDIA 드라이버는 Wayland 그래픽 세션과 호환되지 않습니다. 결과적으로 NVIDIA 드라이버를 사용하는 RHEL 게스트 운영 체제는 자동으로 Wayland를 비활성화하고 대신 Xorg 세션을 로드합니다. 이는 주로 다음 시나리오에서 발생합니다.
- NVIDIA GPU 장치를 RHEL VM(가상 머신)에 전달하는 경우
- NVIDIA vGPU 미디어 장치를 RHEL VM에 할당하는 경우
Jira:RHELPLAN-117234[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 을 켭니다.
Bugzilla:2077767[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에서 커널 패닉이 트리거됩니다.
Bugzilla:2005173[1]
네트워크 인터페이스 재설정 후 Windows VM에서 IP 주소를 얻지 못했습니다
경우에 따라 자동 네트워크 인터페이스를 재설정한 후 Windows 가상 머신이 IP 주소를 얻지 못하는 경우가 있습니다. 결과적으로 VM이 네트워크에 연결되지 못합니다. 이 문제를 해결하려면 Windows 장치 관리자에서 네트워크 어댑터 드라이버를 비활성화하고 다시 활성화합니다.
Windows Server 2016 VM이 vCPU 핫플러그 후 작동하지 않는 경우가 있습니다.
현재 Windows Server 2016 게스트 운영 체제에서 실행 중인 VM(가상 머신)에 vCPU를 할당하면 VM이 예기치 않게 중지되거나 응답하지 않거나 재부팅되는 등 다양한 문제가 발생할 수 있습니다.
NVIDIA 패스스루 장치가 있는 VM에서 중복 오류 메시지
RHEL 9.2 이상 운영 체제가 있는 Intel 호스트 머신을 사용하는 경우 NVDIA GPU 장치를 통해 전달되는 VM(가상 머신)은 다음 오류 메시지를 기록하는 경우가 많습니다.
Spurious APIC interrupt (vector 0xFF) on CPU#2, should never happen.
그러나 이 오류 메시지는 VM 기능에 영향을 미치지 않으며 무시할 수 있습니다. 자세한 내용은 Red Hat knoweldgeBase 를 참조하십시오.
Bugzilla:2149989[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
이 문제를 해결하려면 NUMA 노드 구성에 AMD EPYC CPU를 사용하지 마십시오.
VM 마이그레이션 중 NFS 실패로 인해 마이그레이션 실패 및 소스 VM 코어 덤프
현재 VM(가상 머신) 마이그레이션 중에 NFS 서비스 또는 서버가 종료되면 다시 실행을 시작할 때 소스 VM의 QEMU가 NFS 서버에 다시 연결할 수 없습니다. 결과적으로 마이그레이션이 실패하고 소스 VM에서 코어dump가 시작됩니다. 현재는 사용할 수 있는 해결방법이 없습니다.
PCIe ATS 장치는 Windows VM에서 작동하지 않음
Windows 게스트 운영 체제를 사용하여 VM(가상 머신)의 XML 구성에서 PCIe 주소 변환 서비스(ATS) 장치를 구성할 때 게스트는 VM을 부팅한 후 ATS 장치를 활성화하지 않습니다. Windows는 현재 virtio 장치에서 ATS를 지원하지 않기 때문입니다.
자세한 내용은 Red Hat KnowledgeBase 를 참조하십시오.
virsh blkiotune --weight 명령이 올바른 cgroup I/O 컨트롤러 값을 설정하지 못했습니다.
현재 virsh blkiotune --weight 명령을 사용하여 VM weight가 예상대로 작동하지 않습니다. 이 명령은 cgroup I/O 컨트롤러 인터페이스 파일에 올바른 io.bfq.weight 값을 설정하지 못합니다. 현재는 해결방법이 없습니다.
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 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]
경우에 따라 postcopy VM 마이그레이션을 다시 시작할 수 없습니다.
현재 VM(가상 머신)의 postcopy 마이그레이션을 수행할 때 마이그레이션의 RECOVER 단계에서 프록시 네트워크 오류가 발생하면 VM이 응답하지 않고 마이그레이션을 다시 시작할 수 없습니다. 대신 복구 명령은 다음과 같은 오류를 표시합니다.
error: Requested operation is not valid: QEMU reports migration is still running
virtio balloon 드라이버는 Windows 10 VM에서 작동하지 않는 경우가 있습니다.
특정 상황에서는 virtio-balloon 드라이버가 Windows 10 게스트 운영 체제를 사용하는 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
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]
가상 머신에서 AMD SRSO 취약점을 잘못 보고
AMD September 3 및 4 CPU 아키텍처가 있는 RHEL 9 호스트에서 실행되는 RHEL 9.4 가상 머신(VM)은 Speculative Return Stack Overflow (SRSO) 공격에 취약점을 잘못 보고합니다.
# lscpu | grep rstack
Vulnerability Spec rstack overflow: Vulnerable: Safe RET, no microcode
이 문제는 누락된 cpuid 플래그로 인해 발생하며 실제로 다음과 같은 조건에서 VM에서 취약점이 완전히 완화됩니다.
-
여기에 설명된 대로 호스트에 업데이트된
linux-firmware패키지가 있습니다. cve-2023-20569. -
호스트 커널에는 기본 동작인 완화 기능이 활성화되어 있습니다. 완화 조치가 활성화되면 호스트의
lscpu명령 출력에Safe RET가 표시됩니다.
Jira:RHEL-26152[1]
많은 양의 vCPU 및 가상 디스크가 있는 가상 머신이 실패할 수 있습니다.
현재 많은 양의 vCPU 및 가상 디스크를 RHEL 가상 머신(VM)에 할당하면 VM이 부팅되지 않을 수 있습니다.
이 문제를 해결하려면 가능한 경우 블록 장치 대신 SCSI(Small Computer System Interface) 가상 스토리지 장치를 사용하십시오. 자세한 내용은 CLI를 사용하여 vHBA 장치를 사용하여 SCSI 기반 스토리지 풀 생성을참조하십시오.
가상 블록 장치를 사용해야 하는 경우 -global virtio-blk-pci.vectors= <number-of-vectors> QEMU 옵션으로 VM을 시작하여 인터럽트벡터 수 를 줄일 수도 있습니다. VM을 성공적으로 부팅할 수 있는 인터럽트 벡터가 충분히 적습니다.
Jira:RHEL-32990[1]
상태가 e1000e 또는 igb 모델 인터페이스로 다운 된 경우에도 VM에 link 상태가 표시됩니다.
VM을 부팅하기 전에 e1000 또는 igb 모델 네트워크 인터페이스에 대한 이더넷 링크의 상태를 아래로 설정합니다. 이 경우에도 VM이 부팅된 후에도 네트워크 인터페이스는 상태를 유지합니다. 이더넷 링크의 상태를 중단한 다음 VM을 중지했다가 다시 시작하면 VM이 자동으로 다시 설정되기 때문입니다. up 결과적으로 네트워크 인터페이스의 올바른 상태가 유지 관리되지 않습니다. 이 문제를 해결하려면 명령을 사용하여 네트워크 인터페이스 상태를 VM 내부에서 down 으로 설정합니다.
# ip link set dev eth0 down
또는 VM이 실행되는 동안 이 네트워크 인터페이스를 제거하고 다시 추가할 수 있습니다.
NBD를 사용하여 TLS 연결을 통해 VM 스토리지를 마이그레이션하면 제대로 작동하지 않음
현재 TLS 연결을 통해 NBD(Network Block Device) 프로토콜을 사용하여 VM(가상 머신) 및 스토리지 장치를 마이그레이션할 때 TLS 핸드셰이크의 데이터 경쟁으로 인해 마이그레이션이 성공한 것처럼 보일 수 있습니다. 그러나 대상 VM의 QEMU 프로세스가 추가 상호 작용에 응답하지 않게 됩니다.
네트워크를 신뢰할 수 있는 경우 VM 스토리지 마이그레이션 중에 사용되는 NBD 프로토콜에 TLS 연결 대신 일반 텍스트를 사용하여 이 문제를 해결할 수 있습니다.
AMD SEV-SNP가 있는 가상 머신에서 kdump 실패
현재 kdump는 SEV(Secure Encrypted Virtualization)를 SNP(Secure Nested Paging) 기능과 함께 사용하는 RHEL 9 VM(가상 머신)에서 실패합니다.
Jira:RHEL-10019[1]
VM에서 AMD EPYC 모델에서 spec_rstack_overflow 매개변수의 취약한 상태를 잘못 보고
호스트를 부팅하면 spec_rstack_overflow 매개변수의 취약점을 탐지하지 않습니다. 로그에 대한 매개변수를 쿼리한 후 메시지가 표시됩니다.
# 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
그러나 이는 잘못된 경고 메시지이며 VM 내부의 /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow 파일의 상태를 무시할 수 있습니다.
Jira:RHEL-17614[1]
