11.17. 가상화
다수의 큐를 사용하면 Windows 가상 머신이 실패할 수 있습니다.
vTPM(가상 신뢰 플랫폼 모듈) 장치가 활성화되고, 250개 이상의 대기열을 사용하도록 멀티 큐 virtio-net 기능이 구성된 경우 VM(Windows 가상 머신)이 실패할 수 있습니다.
이 문제는 vTPM 장치의 제한으로 인해 발생합니다. vTPM 장치에는 열린 파일 설명자의 최대 수에 하드 코딩된 제한이 있습니다. 새 큐에 대해 여러 파일 설명자가 열리므로 내부 vTPM 제한을 초과하여 VM이 실패할 수 있습니다.
이 문제를 해결하려면 다음 두 가지 옵션 중 하나를 선택합니다.
- vTPM 장치를 활성화하되 250개 미만의 대기열을 사용합니다.
- 250개 이상의 대기열을 사용하도록 vTPM 장치를 비활성화합니다.
밀란 VM CPU 유형은 AMD Milan 시스템에서 사용할 수 없는 경우가 있습니다.
특정 AMD Milan 시스템에서는 강화된 REP MOVSB(erms) 및 Fast short REP MOVSB(fsrm) 기능 플래그가 기본적으로 BIOS에서 비활성화되어 있습니다. 결과적으로 이러한 시스템에서 밀란 CPU 유형을 사용할 수 없습니다. 또한 기능 플래그 설정이 다른 밀란 호스트 간에 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 PartitionECDHE) 기능 사용
- 호스트 어댑터 재설정
- SCSI 오류 처리(SCSI EH) 함수 사용
(BZ#1961722)
IBM POWER Systems에서 kvm에 perf kvm 레코드 를 사용하면 VM이 충돌할 수 있습니다.
IBM POWER 하드웨어의 little-endian 변형에서 RHEL 8 호스트를 사용하는 경우 perf kvm record 명령을 사용하여 KVM 가상 머신(VM)의 추적 이벤트 샘플을 수집하면 VM이 응답하지 않습니다. 이 상황은 다음과 같은 경우 발생합니다.
-
perf유틸리티는 권한이 없는 사용자가 사용하며-p옵션은 VM을 식별하는 데 사용됩니다(예:perf kvm 레코드 -e trace_cycles -pECDHE45). -
virsh쉘을 사용하여 VM이 시작되었습니다.
이 문제를 해결하려면 virsh 쉘을 사용하여 생성된 VM을 모니터링하려면 perf kvm 유틸리티를 -i 옵션과 함께 사용합니다. 예를 들어 다음과 같습니다.
# perf kvm record -e trace_imc/trace_cycles/ -p <guest pid> -i
i 옵션을 사용할 때 하위 작업은 카운터를 상속하지 않으므로 스레드는 모니터링되지 않습니다.
(BZ#1924016)
Hyper-V가 활성화된 Windows Server 2016 가상 머신은 특정 CPU 모델을 사용할 때 부팅되지 않습니다.
현재는 Windows Server 2016을 게스트 운영 체제로 사용하고 Hyper-V 역할이 활성화된 VM(가상 머신)을 부팅할 수 없으며 다음 CPU 모델 중 하나를 사용합니다.
- EPYC-IBPB
- EPYC
이 문제를 해결하려면 EPYC-v3 CPU 모델을 사용하거나 VM에 대한 xsaves CPU 플래그를 수동으로 활성화하십시오.
(BZ#1942888)
RHEL 7-ALT 호스트에서 RHEL 8로 POWER9 게스트 마이그레이션 실패
현재 RHEL 7-ALT 호스트 시스템에서 RHEL 8로 POWER9 가상 머신을 마이그레이션하는 경우 마이그레이션 상태: active 상태로 응답하지 않습니다.
이 문제를 해결하려면 RHEL 7-ALT 호스트에서 THP(Transparent Huge Pages)를 비활성화하여 마이그레이션이 성공적으로 완료되도록 합니다.
(BZ#1741436)
virt-customize 를 사용하면 guestfs-firstboot 가 실패하는 경우가 있습니다.
virt-customize 유틸리티를 사용하여 VM(가상 머신) 디스크 이미지를 수정한 후에는 잘못된 SELinux 권한으로 인해 guestfs-firstboot 서비스가 실패합니다. 이로 인해 VM 시작 중에 사용자 생성 실패 또는 시스템 등록 실패와 같은 다양한 문제가 발생합니다.
이 문제를 방지하려면 virt-customize 로 디스크 이미지를 수정한 후 VM의 커널 명령줄에 --selinux-relabel 을 추가합니다.
macvtap 가상 네트워크에서 전달 인터페이스를 삭제하면 이 네트워크의 모든 연결 수가 재설정됩니다.
현재 여러 개의 전달 인터페이스가 있는 macvtap 가상 네트워크에서 전달 인터페이스를 삭제하면 네트워크의 다른 전달 인터페이스의 연결 상태가 재설정됩니다. 결과적으로 라이브 네트워크 XML의 연결 정보가 올바르지 않습니다. 그러나 가상 네트워크의 기능에는 영향을 미치지 않습니다. 이 문제를 해결하려면 호스트에서 libvirtd 서비스를 다시 시작하십시오.
ECDHEOF가 있는 가상 머신은 netcat 인터페이스에서 부팅되지 않음
netcat(nc) 인터페이스를 사용하여 현재 Slimline Open Firmware(Slimline Open Firmware) 프롬프트에서 대기 중인 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을 실행할 수 없습니다.
호스트에서 OVS 서비스를 다시 시작하면 실행 중인 VM에서 네트워크 연결이 차단될 수 있습니다.
OVS(Open vSwitch) 서비스가 다시 시작되거나 호스트에서 충돌하면 이 호스트에서 실행 중인 가상 머신(VM)이 네트워킹 장치의 상태를 복구할 수 없습니다. 결과적으로 VM은 패킷을 완전히 수신할 수 없었습니다.
이 문제는 virtio 네트워킹 스택에서 패키징된 virtqueue 형식을 사용하는 시스템에만 영향을 미칩니다.
이 문제를 해결하려면 virtio 네트워킹 장치 정의에서 packed=off 매개변수를 사용하여 패키징된 virtqueue를 비활성화합니다. 패키징된 virtqueue가 비활성화된 경우 네트워킹 장치의 상태는 일부 상황에서 RAM에서 복구될 수 있습니다.
많은 virtio-blk 디스크를 사용할 때 가상 머신을 시작하지 못하는 경우가 있습니다.
다수의 virtio-blk 장치를 VM(가상 머신)에 추가하면 플랫폼에서 사용 가능한 인터럽트 벡터 수가 소진될 수 있습니다. 이 경우 VM의 게스트 OS가 부팅되지 않고 dracut-initqueue[392]: Warning: Could not boot 오류가 표시됩니다.
virtiofs에서 SUID 및 SGID가 자동으로 지워지지 않음
killpriv_v2 기능을 사용하여 virtiofsd 서비스를 실행하면 일부 파일 시스템 작업을 수행한 후 시스템에서 SUID 및 SGID 권한을 자동으로 지우지 못할 수 있습니다. 따라서 권한을 지우지 않으면 잠재적인 보안 취약점이 발생할 수 있습니다. 이 문제를 해결하려면 다음 명령을 입력하여 killpriv_v2 기능을 비활성화합니다.
# virtiofsd -o no_killpriv_v2
(BZ#1966475)
AMD EPYC에서 호스트 패스스루 모드를 사용할 때 SMT CPU 토폴로지가 VM에서 탐지되지 않음
가상 머신(VM)이 AMD EPYC 호스트에서 CPU 호스트 패스스루 모드로 부팅되면ECDHE OEXT CPU 기능 플래그가 없습니다. 결과적으로 VM은 코어당 여러 스레드가 있는 가상 CPU 토폴로지를 감지할 수 없습니다. 이 문제를 해결하려면 호스트 패스스루 대신 EPYC CPU 모델을 사용하여 VM을 부팅합니다.
