10.16. 가상화
가상 머신의 네트워크 트래픽 성능이 저하될 수 있습니다.
경우에 따라 RHEL 8.6 게스트 가상 머신(VM)이 높은 수준의 네트워크 트래픽을 처리할 때 성능이 다소 감소했습니다.
(BZ#2069047)
대량의 큐를 사용하면 Windows 가상 머신이 실패할 수 있습니다.
가상 신뢰할 수 있는 플랫폼 모듈(vTPM) 장치가 활성화되고 다중 대기열 virtio-net 기능이 250개를 초과하도록 구성된 경우 Windows 가상 머신(VM)이 실패할 수 있습니다.
이 문제는 vTPM 장치의 제한으로 인해 발생합니다. vTPM 장치는 열린 파일 설명자의 최대 수에 하드 코딩된 제한이 있습니다. 모든 새 큐에 대해 여러 파일 설명자가 열리므로 내부 vTPM 제한을 초과할 수 있으므로 VM이 실패합니다.
이 문제를 해결하려면 다음 두 가지 옵션 중 하나를 선택합니다.
- vTPM 장치를 활성화하지만 250개 미만의 대기열을 사용합니다.
- 250개 이상의 대기열을 사용하려면 vTPM 장치를 비활성화합니다.
장애 조치(failover) VF가 있는 VM의 실시간 복사 후 마이그레이션이 작동하지 않음
현재 VM에서 VF(가상 기능) 장애 조치 기능이 활성화된 장치를 사용하는 경우 실행 중인 VM(가상 머신) 마이그레이션 후 VM이 실패합니다. 이 문제를 해결하려면 복사 후 마이그레이션이 아닌 표준 마이그레이션 유형을 사용하십시오.
(BZ#2054656)
RHEL 8의 이전 마이너 버전에서 RHEL 8.6 Intel 호스트로의 실시간 마이그레이션이 작동하지 않습니다.
Intel TSX(Transactional Synchronization Extensions) 기능이 더 이상 사용되지 않기 때문에 Intel 하드웨어의 RHEL 8.6 호스트에서 더 이상 hle 및 rtm CPU 플래그를 사용하지 않습니다. 결과적으로 소스 호스트에서 RHEL 8.5 또는 RHEL 8의 이전 마이너 버전을 사용하는 경우 VM(가상 머신)을 RHEL 8.6 호스트로 실시간 마이그레이션할 수 없습니다.
TSX 사용 중단에 대한 자세한 내용은 Red Hat KnowledgeBase 를 참조하십시오.
(BZ#2134184)
Milan VM CPU 유형은 AMD Milan 시스템에서 사용할 수 없는 경우가 있습니다.
특정 AMD Milan 시스템에서는 향상된 REP신SB (erms) 및 Fast Short REP RSSB (fsrm) 기능 플래그가 BIOS에서 기본적으로 비활성화되어 있습니다. 결과적으로 이러한 시스템에서 'Milan' CPU 유형을 사용할 수 없습니다. 또한 기능 플래그 설정이 다른 Milan 호스트 간에 VM 실시간 마이그레이션이 실패할 수 있습니다. 이러한 문제를 해결하려면 호스트의 BIOS에서 erms 및 fsrm 을 수동으로 설정합니다.
(BZ#2077770)
virtio-blk를 사용하여 LUN 장치를 가상 머신에 연결할 수 없습니다.
q35 시스템 유형은 전환 virtio 1.0 장치를 지원하지 않으므로 RHEL 8에서는 virtio 1.0에서 더 이상 사용되지 않는 기능을 지원하지 않습니다. 특히, RHEL 8 호스트에서 virtio-blk 장치에서 SCSI 명령을 보낼 수 없습니다. 결과적으로 virtio-blk 컨트롤러를 사용할 때 가상 머신에 물리적 디스크를 LUN 장치로 연결하면 실패합니다.
물리적 디스크를 게스트 운영 체제로 계속 전달할 수 있지만, device='lun' 보다는 device='disk' 옵션으로 구성해야 합니다.
(BZ#1777138)
iommu_platform=on 이 있는 가상 머신은 IBM POWER에서 시작되지 않습니다.
RHEL 8은 현재 IBM POWER 시스템에서 VM(가상 머신)에 대해 iommu_platform=on 매개변수를 지원하지 않습니다. 결과적으로 IBM POWER 하드웨어에서 이 매개변수를 사용하여 VM을 시작하면 부팅 프로세스 중에 VM이 응답하지 않게 됩니다.
IBM POWER 호스트는 ibmvfc 드라이버를 사용할 때 충돌할 수 있습니다.
LPAR(PowerVM 논리 파티션)에서 RHEL 8을 실행하는 경우 ibmvfc 드라이버의 문제로 인해 현재 다양한 오류가 발생할 수 있습니다. 결과적으로 호스트 커널은 다음과 같은 특정 상황에서 패닉을 일으킬 수 있습니다.
- LPM(Live Partition Mobility) 기능 사용
- 호스트 어댑터 재설정
- SCSI EH(SCSI EH) 함수 사용
(BZ#1961722)
IBM POWER Systems에서 kvm별 레코드를 사용하면 VM이 충돌할 수 있습니다.
IBM POWER 하드웨어의 little-endian 변형에서 RHEL 8 호스트를 사용하는 경우 kvm record 명령을 사용하여 KVM 가상 머신(VM)에 대한 추적 이벤트 샘플을 수집하는 경우 VM이 응답하지 않게 됩니다. 이 상황은 다음과 같은 경우에 발생합니다.
-
perf유틸리티는 권한이 없는 사용자가 사용하며-p옵션은 VM을 식별하는 데 사용됩니다(예:kvm별 레코드 -e trace_cycles -p 12345). -
VM은
virsh쉘을 사용하여 시작했습니다.
이 문제를 해결하려면 virsh 쉘을 사용하여 생성된 VM을 모니터링하려면 -i 옵션과 함께 perf kvm 유틸리티를 사용합니다. 예를 들어 다음과 같습니다.
# perf kvm record -e trace_imc/trace_cycles/ -p <guest pid> -i
i 옵션을 사용하면 하위 작업이 카운터를 상속하지 않으므로 스레드가 모니터링되지 않습니다.
(BZ#1924016)
Hyper-V가 활성화된 Windows Server 2016 가상 머신은 특정 CPU 모델을 사용할 때 부팅되지 않습니다.
현재 Windows Server 2016을 게스트 운영 체제로 사용하는 VM(가상 머신)을 부팅할 수 없으며 Hyper-V 역할이 활성화되어 있으며 다음 CPU 모델 중 하나를 사용합니다.
- EPYC-IBPB
- EPYC
이 문제를 해결하려면 EPYC-v3 CPU 모델을 사용하거나 VM에 대해 xsaves CPU 플래그를 수동으로 활성화합니다.
(BZ#1942888)
RHEL 7-ALT 호스트에서 RHEL 8로 POWER9 게스트 마이그레이션 실패
현재 POWER9 가상 머신을 RHEL 7-ALT 호스트 시스템에서 RHEL 8로 마이그레이션하면 Migration status: active 상태로 응답하지 않습니다.
이 문제를 해결하려면 RHEL 7-ALT 호스트에서 THP(Transparent Huge Pages)를 비활성화하여 마이그레이션을 성공적으로 완료할 수 있습니다.
(BZ#1741436)
virt-customize 를 사용하면 guestfs-firstboot 가 실패하는 경우가 있습니다.
virt-customize 유틸리티를 사용하여 VM(가상 머신) 디스크 이미지를 수정한 후 일부 경우 guestfs-firstboot 서비스가 잘못된 SELinux 권한으로 인해 실패합니다. 이로 인해 사용자 생성 또는 시스템 등록 실패와 같이 VM을 시작하는 동안 다양한 문제가 발생합니다.
이 문제를 방지하려면 virt-customize 명령에 --selinux-relabel 옵션을 추가합니다.
macvtap 가상 네트워크에서 전달 인터페이스를 삭제하면 이 네트워크의 모든 연결 수가 재설정됩니다.
현재 여러 개의 전달 인터페이스가 있는 macvtap 가상 네트워크에서 전달 인터페이스를 삭제하면 네트워크의 다른 전달 인터페이스의 연결 상태도 재설정됩니다. 결과적으로 라이브 네트워크 XML의 연결 정보가 올바르지 않습니다. 그러나 가상 네트워크의 기능에는 영향을 미치지 않습니다. 이 문제를 해결하려면 호스트에서 libvirtd 서비스를 다시 시작합니다.
SLOF가 있는 가상 머신은 netcat 인터페이스에서 부팅되지 않습니다.
netcat(nc) 인터페이스를 사용하여 현재 Slimline Open Firmware(SLOF) 프롬프트에서 대기 중인 가상 머신(VM)의 콘솔에 액세스하면 사용자 입력이 무시되고 VM이 응답하지 않습니다. 이 문제를 해결하려면 VM에 연결할 때 nc -C 옵션을 사용하거나 대신 telnet 인터페이스를 사용하십시오.
(BZ#1974622)
경우에 따라 virt-manager 의 가상 머신에 중재된 장치를 연결할 수 없습니다.
virt-manager 애플리케이션은 현재 중재된 장치를 감지할 수 있지만 장치가 활성화되어 있는지는 인식하지 못합니다. 결과적으로 virt-manager 를 사용하여 실행 중인 VM(가상 머신)에 비활성 미디어 장치를 연결하려고 하면 실패합니다. 마찬가지로 비활성 중재 장치를 사용하는 새 VM을 생성하려고 하면 장치를 찾을 수 없는 오류와 함께 실패합니다.
이 문제를 해결하려면 virsh nodedev-start 또는 mdevctl start 명령을 사용하여 virt-manager 에서 사용하기 전에 중재 장치를 활성화합니다.
RHEL 9 가상 머신이 POWER8 호환 모드에서 부팅되지 않음
현재 VM에서 다음과 유사한 CPU 구성을 사용하는 경우 게스트 운영 체제로 RHEL 9를 실행하는 VM(가상 머신)을 부팅합니다.
<cpu mode="host-model">
<model>power8</model>
</cpu>이 문제를 해결하려면 RHEL 9 VM에서 POWER8 호환성 모드를 사용하지 마십시오.
또한 POWER8 호스트에서 RHEL 9 VM을 실행할 수 없습니다.
많은 virtio-blk 디스크를 사용할 때 가상 머신이 시작되지 않는 경우가 있습니다.
가상 머신(VM)에 다수의 virtio-blk 장치를 추가하면 플랫폼에서 사용 가능한 인터럽트 벡터가 소진될 수 있습니다. 이 경우 VM의 게스트 OS가 부팅되지 않고 dracut-initqueue[392]: Warning: Could not boot 오류가 표시됩니다.
일부 경우 Windows Server 2022 게스트는 AMD Milan에서 매우 느리게 부팅됩니다.
Windows Server 2022 게스트 운영 체제 및 qemu64 CPU 모델을 사용하는 VM(가상 머신)은 현재 AMD EPYC7003 시리즈 프로세서( AMD Milan) 프로세서가 있는 호스트에서 부팅하는 데 시간이 오래 걸립니다.
이 문제를 해결하려면 RHEL 8의 VM에 지원되지 않는 설정이므로 qemu64 를 CPU 모델로 사용하지 마십시오. 예를 들어 대신 host-model CPU를 사용합니다.
AMD EPYC에서 호스트 패스스루 모드를 사용할 때 SMT CPU 토폴로지가 VM에 의해 감지되지 않음
VM(가상 머신)이 AMD EPYC 호스트에서 CPU 호스트 패스스루 모드로 부팅되면 top OEXT CPU 기능 플래그가 존재하지 않습니다. 결과적으로 VM은 코어당 여러 스레드로 가상 CPU 토폴로지를 감지할 수 없습니다. 이 문제를 해결하려면 호스트 패스스루 대신 EPYC CPU 모델을 사용하여 VM을 부팅합니다.
VM을 RHEL 8.6 이후 z-stream 버전으로 마이그레이션하는 경우가 있습니다.
대상 호스트에서 qemu-kvm 패키지 버전 6.2.0-11.module+el8.6.0+21121 이상과 함께 RHEL 8.6 버전을 사용하고 소스 호스트는 qemu-kvm 버전 6.2.0-11.module+el8.6.0+21120 이상을 RHEL 8.6에서 사용하는 경우 VM(가상 머신)을 마이그레이션하려고 합니다.
(JIRA:RHELDOCS-17666)
