11.15. 가상화
많은 수의 큐를 사용하면 Windows 가상 머신이 실패할 수 있습니다.
vTPM(가상 신뢰할 수 있는 플랫폼 모듈) 장치가 활성화되고 다중 대기열 virtio-net 기능이 250개 이상의 큐를 사용하도록 구성된 경우 Windows 가상 머신(VM)이 실패할 수 있습니다.
이 문제는 vTPM 장치의 제한으로 인해 발생합니다. vTPM 장치에는 열린 파일 설명자의 최대 수에 하드 코딩된 제한이 있습니다. 모든 새 큐에 대해 여러 파일 설명자가 열리기 때문에 내부 vTPM 제한을 초과하여 VM이 실패할 수 있습니다.
이 문제를 해결하려면 다음 두 가지 옵션 중 하나를 선택합니다.
- vTPM 장치를 계속 활성화하되 250개 미만의 대기열을 사용합니다.
- 250개 이상의 대기열을 사용하도록 vTPM 장치를 비활성화합니다.
Jira:RHEL-13336[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:2077770[1]
AMD EPYC에서 호스트 패스스루 모드를 사용할 때 VM에서 SMT CPU 토폴로지가 탐지되지 않음
가상 머신(VM)이 AMD EPYC 호스트에서 CPU 호스트 패스스루 모드로 부팅되는 경우 Django OEXT CPU 기능 플래그가 존재하지 않습니다. 결과적으로 VM은 코어당 여러 스레드가 있는 가상 CPU 토폴로지를 감지할 수 없습니다. 이 문제를 해결하려면 호스트 패스스루 대신 EPYC CPU 모델로 VM을 부팅합니다.
virtio-blk를 사용하여 가상 머신에 LUN 장치를 연결하면 작동하지 않음
q35 시스템 유형은 전환 virtio 1.0 장치를 지원하지 않으므로 RHEL 8에서는 virtio 1.0에서 더 이상 사용되지 않는 기능을 지원하지 않습니다. 특히 RHEL 8 호스트에서 virtio-blk 장치에서 SCSI 명령을 보낼 수 없습니다. 결과적으로 virtio-blk 컨트롤러를 사용하는 경우 물리적 디스크를 가상 머신에 LUN 장치로 연결합니다.
물리적 디스크는 여전히 게스트 운영 체제로 전달할 수 있지만 device='lun' 이 아닌 device='disk' 옵션으로 구성해야 합니다.
Bugzilla:1777138[1]
많은 virtio-blk 디스크를 사용할 때 가상 머신이 시작되지 않는 경우가 있습니다.
가상 시스템(VM)에 다수의 virtio-blk 장치를 추가하면 플랫폼에서 사용 가능한 인터럽트 벡터 수가 소모될 수 있습니다. 이 경우 VM의 게스트 OS가 부팅되지 않고 dracut-initqueue[392]: Warning: Could not boot 오류가 표시됩니다.
IBM POWER에서 iommu_platform=on 이 있는 가상 머신이 시작되지 않음
RHEL 8은 현재 IBM POWER 시스템에서 VM(가상 머신)의 iommu_platform=on 매개변수를 지원하지 않습니다. 결과적으로 IBM POWER 하드웨어에서 이 매개변수를 사용하여 VM을 시작하면 부팅 프로세스 중에 VM이 응답하지 않습니다.
ibmvfc 드라이버를 사용할 때 IBM POWER 호스트가 올바르게 작동함
PowerVM 논리 파티션(LPAR)에서 RHEL 8을 실행하는 경우 이전에는 ibmvfc 드라이버의 문제로 인해 다양한 오류가 발생할 수 있었습니다. 결과적으로 다음과 같이 특정 상황에서 호스트에서 커널 패닉이 트리거됩니다.
- LPM(Live Partition Cryostat) 기능 사용
- 호스트 어댑터 재설정
- SCSI 오류 처리(SCSI EH) 함수 사용
이번 업데이트를 통해 ibmvfc 처리가 수정되었으며 설명된 커널 패닉이 더 이상 발생하지 않습니다.
Bugzilla:1961722[1]
IBM POWER Systems에서 perf kvm 레코드를 사용하면 VM이 충돌할 수 있습니다.
IBM POWER 하드웨어의 little-endian 변형에 RHEL 8 호스트를 사용하는 경우 perf kvm record 명령을 사용하여 KVM 가상 머신(VM)의 추적 이벤트 샘플을 수집하는 경우 VM이 응답하지 않습니다. 이 문제는 다음과 같은 경우에 발생합니다.
-
perf유틸리티는 권한이 없는 사용자가 사용하고-p옵션은 VM(예:perf kvm 레코드 -e trace_cycles -p 12345)을 식별하는 데 사용됩니다. -
VM은
virsh쉘을 사용하여 시작되었습니다.
이 문제를 해결하려면 perf kvm 유틸리티를 -i 옵션과 함께 사용하여 virsh 쉘을 사용하여 만든 VM을 모니터링합니다. 예를 들면 다음과 같습니다.
# perf kvm record -e trace_imc/trace_cycles/ -p <guest pid> -i
i 옵션을 사용하면 하위 작업이 카운터를 상속하지 않으므로 스레드가 모니터링되지 않습니다.
Bugzilla:1924016[1]
특정 CPU 모델을 사용할 때 Hyper-V가 활성화된 Windows Server 2016 가상 머신이 부팅되지 않음
현재 Windows Server 2016을 게스트 운영 체제로 사용하는 VM(가상 머신)을 부팅할 수 없으며 Hyper-V 역할이 활성화되어 있으며 다음 CPU 모델 중 하나를 사용합니다.
- EPYC-IBPB
- EPYC
이 문제를 해결하려면 EPYC-v3 CPU 모델을 사용하거나 VM에 대해 xsaves CPU 플래그를 수동으로 활성화합니다.
Bugzilla:1942888[1]
POWER9 게스트를 RHEL 7-ALT 호스트에서 RHEL 8로 마이그레이션 실패
현재 POWER9 가상 머신을 RHEL 7-ALT 호스트 시스템에서 RHEL 8로 마이그레이션하면 마이그레이션 상태: active 상태로 응답하지 않습니다.
이 문제를 해결하려면 RHEL 7-ALT 호스트에서 THP(Transparent Huge Pages)를 비활성화하여 마이그레이션이 성공적으로 완료될 수 있습니다.
Bugzilla:1741436[1]
virt-customize 를 사용하면 guestfs-firstboot 가 실패하는 경우가 있습니다.
virt-customize 유틸리티를 사용하여 VM(가상 머신) 디스크 이미지를 수정한 후 일부 경우 guestfs-firstboot 서비스가 잘못된 SELinux 권한으로 인해 실패합니다. 이로 인해 사용자 생성 또는 시스템 등록 실패와 같은 VM을 시작하는 동안 다양한 문제가 발생합니다.
이 문제를 방지하려면 --selinux-relabel 옵션과 함께 virt-customize 명령을 사용하십시오.
macvtap 가상 네트워크에서 전달 인터페이스를 삭제하면 이 네트워크의 모든 연결 수가 재설정됩니다.
현재 여러 전달 인터페이스가 있는 macvtap 가상 네트워크에서 전달 인터페이스를 삭제하면 네트워크의 다른 전달 인터페이스의 연결 상태도 재설정됩니다. 결과적으로 라이브 네트워크 XML의 연결 정보가 올바르지 않습니다. 그러나 가상 네트워크의 기능에는 영향을 미치지 않습니다. 이 문제를 해결하려면 호스트에서 libvirtd 서비스를 다시 시작하십시오.
SLOF가 있는 가상 머신은 netcat 인터페이스에서 부팅되지 않음
netcat(nc) 인터페이스를 사용하여 현재 Slimline Open Firmware(SLOF) 프롬프트에서 대기 중인 VM(가상 머신) 콘솔에 액세스하는 경우 사용자 입력이 무시되고 VM은 응답하지 않습니다. 이 문제를 해결하려면 VM에 연결할 때 nc -C 옵션을 사용하거나 대신 telnet 인터페이스를 사용합니다.
Bugzilla:1974622[1]
경우에 따라 virt-manager 의 가상 머신에 중재된 장치 연결 실패
virt-manager 애플리케이션은 현재 중재된 장치를 감지할 수 있지만 장치가 활성화되어 있는지 여부를 인식할 수 없습니다. 결과적으로 virt-manager 를 사용하여 실행 중인 VM(가상 머신)에 비활성 중재 장치를 연결합니다. 마찬가지로 비활성 중재 장치를 사용하는 새 VM을 생성하려고 하면 장치를 찾을 수 없는 오류와 함께 실패합니다.
이 문제를 해결하려면 virt-manager 에서 사용하기 전에 virsh nodedev-start 또는 mdevctl start 명령을 사용하여 중재된 장치를 활성화합니다.
RHEL 9 가상 머신이 POWER8 호환성 모드에서 부팅되지 않음
현재 VM에서 다음과 유사한 CPU 구성도 사용하는 경우 RHEL 9를 게스트 운영 체제로 실행하는 VM(가상 머신)을 부팅하는 데 실패합니다.
<cpu mode="host-model">
<model>power8</model>
</cpu>이 문제를 해결하려면 RHEL 9 VM에서 POWER8 호환성 모드를 사용하지 마십시오.
또한 POWER8 호스트에서 RHEL 9 VM을 실행할 수 없습니다.
virtiofs에서 SUID 및 SGID가 자동으로 삭제되지 않음
killpriv_v2 기능을 사용하여 virtiofsd 서비스를 실행하면 일부 파일 시스템 작업을 수행한 후 시스템에서 SUID 및 SGID 권한을 자동으로 지우지 못할 수 있습니다. 따라서 권한을 지우지 않으면 잠재적인 보안 위협으로 이어질 수 있습니다. 이 문제를 해결하려면 다음 명령을 입력하여 killpriv_v2 기능을 비활성화합니다.
# virtiofsd -o no_killpriv_v2
Bugzilla:1966475[1]
호스트에서 OVS 서비스를 다시 시작하면 실행 중인 VM에서 네트워크 연결이 차단될 수 있습니다.
OVS(Open vSwitch) 서비스가 호스트에서 다시 시작되거나 중단되면 이 호스트에서 실행 중인 VM(가상 머신)은 네트워킹 장치의 상태를 복구할 수 없습니다. 결과적으로 VM이 패킷을 수신하지 못할 수 있습니다.
이 문제는 virtio 네트워킹 스택에서 패키징된 virtqueue 형식을 사용하는 시스템에만 영향을 미칩니다.
이 문제를 해결하려면 virtio 네트워킹 장치 정의에서 packed=off 매개 변수를 사용하여 패키징된 virtqueue를 비활성화합니다. 패키징된 virtqueue가 비활성화된 상태에서 네트워킹 장치의 상태는 RAM에서 복구할 수 있습니다.
VM 마이그레이션 중 NFS 실패로 인해 마이그레이션 실패 및 소스 VM 코어 덤프
현재 VM(가상 머신) 마이그레이션 중에 NFS 서비스 또는 서버가 종료되면 다시 실행을 시작할 때 소스 VM의 QEMU가 NFS 서버에 다시 연결할 수 없습니다. 결과적으로 마이그레이션이 실패하고 소스 VM에서 코어dump가 시작됩니다. 현재는 사용할 수 있는 해결방법이 없습니다.
nodedev-dumpxml 이 특정 중재된 장치에 대해 속성을 올바르게 나열하지 않음
현재 nodedev-dumpxml 은 nodedev-create 명령을 사용하여 생성된 중재된 장치에 대해 속성을 올바르게 나열하지 않습니다. 이 문제를 해결하려면 nodedev-define 및 nodedev-start 명령을 대신 사용하십시오.
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-2451[1]
