작성자 Matt Connor
VPS에서 중첩 가상화 및 Proxmox 실행 가능 여부 확인
VPS에서 Proxmox를 실행하려면 CPU 가상화 플래그 노출이 필수입니다. kvm-ok 명령어로 vmx 또는 svm 플래그를 확인하는 방법과 하이퍼바이저 설정에 따른 가상화 제한 사항, 그리고 실제 구동 시 발생하는 오류 메시지를 상세히 정리했습니다.
간단한 답변
중첩 가상화(Nested virtualization)는 가상 머신 내부에서 실행되는 하이퍼바이저를 의미합니다. 즉, 이미 게스트 상태인 VPS가 또 다른 게스트를 호스팅하려는 상황입니다. 이는 서비스 제공업체의 하이퍼바이저가 CPU의 가상화 확장 기능을 인스턴스에 의도적으로 노출할 때만 작동합니다. /proc/cpuinfo에서 vmx 플래그(Intel) 또는 svm(AMD)이 있는지 확인하십시오. 이 중 아무것도 나타나지 않는다면 VPS 내부에서 어떤 설정을 하더라도 해결할 수 없습니다.
먼저 기대치를 명확히 하겠습니다. Docker는 이 기능이 전혀 필요하지 않습니다. 컨테이너는 VPS의 커널을 공유하며 /dev/kvm에 접근하지 않습니다. 만약 실제 목표가 "서버에서 여러 서비스를 컨테이너로 실행하는 것"이라면, 이미 필요한 모든 것을 갖추고 있는 셈입니다. 중첩 가상화가 필요한 경우는 두 번째 커널이 필요하거나, Proxmox 랩, Windows 게스트, Firecracker microVM, Android 에뮬레이터, 실제 VM 기반의 Kubernetes 테스트베드, 또는 VM 이미지를 부팅하는 CI 러너를 운영하려는 경우입니다.
실제로 중첩되는 대상
세 개의 계층이 존재합니다.
- L0: 물리 서버에서 동작하는 공급자의 하이퍼바이저입니다. 사용자는 이 계층에 접근할 수 없습니다.
- L1: 사용자의 VPS입니다. L0의 관점에서는 하나의 게스트일 뿐입니다.
- L2: VPS 내부에서 실행하려는 VM입니다.
하드웨어 가상화는 Intel의 경우 VT-x(vmx 플래그)와 EPT, AMD의 경우 AMD-V / SVM(svm)과 RVI/NPT를 사용합니다. 하이퍼바이저는 이러한 명령어를 사용하여 게스트 모드로 진입하고 CPU가 두 개의 페이지 테이블을 동시에 참조하도록 합니다.
이 기술들은 원래 재진입(re-entrant)을 고려하여 설계되지 않았으므로 중첩은 에뮬레이션 방식으로 구현됩니다. L1이 VMLAUNCH나 VMRESUME과 같은 VMX 명령어를 실행하면 L0로 트랩(trap)이 발생하며, L0는 L1을 대신하여 L2를 위한 섀도우 구조를 유지합니다. VMCS 섀도잉을 지원하는 CPU에서는 L1의 VMREAD와 VMWRITE가 종료(exit) 과정 없이 처리될 수 있어 트래픽이 크게 줄어들지만, 나머지 작업은 여전히 종료 과정을 거쳐야 합니다. KVM은 이를 잘 처리하지만, 모든 종료 시마다 L0가 추가 작업을 수행해야 하므로 공급자가 직접 기능을 활성화해야 합니다.
L0가 KVM인 경우, 가속화된 L2를 사용하려면 다음 두 가지 조건이 모두 충족되어야 합니다.
- L0의 KVM 모듈이
nested=1옵션으로 로드되어야 합니다. - L0가 VPS에 해당 플래그를 포함한 CPU 모델을 제공해야 합니다. 이는 libvirt에서는
<cpu mode='host-passthrough'/>, Proxmox에서는cpu: host, 원시 QEMU에서는-cpu host로 설정합니다. 일반적인 에뮬레이션 모델(qemu64,kvm64)은 중첩 기능이 전역적으로 켜져 있더라도vmx를 숨깁니다.
다른 하이퍼바이저들도 각자의 전환 스위치를 가지고 있습니다. 예를 들어 Hyper-V는 VM 내부의 중첩 하이퍼바이저를 위해 가상화 확장 기능을 에뮬레이션하지만, 이는 중첩 기능이 개별적으로 활성화된 VM에서만 작동합니다.
1분 안에 VPS 확인하기
# 1. Are you in a VM, and under what?
systemd-detect-virt # kvm, vmware, xen, microsoft, or "none" on metal
# 2. Does the CPU expose the extensions to you?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i -E 'virtual|hypervisor'
# 3. The definitive check
sudo apt update && sudo apt install -y cpu-checker
kvm-ok
# 4. The device node the whole stack depends on
ls -l /dev/kvm사용 가능한 인스턴스는 vmx 또는 svm을 출력하며, kvm-ok은 KVM acceleration can be used를 반환하고, /dev/kvm은 root:kvm 모드 660로 존재합니다. 플래그는 존재하지만 장치 노드가 없다면 모듈을 수동으로 로드하고 커널 로그를 확인하십시오:
sudo modprobe kvm_intel # or kvm_amd
sudo dmesg | tail -n 20한 파일이 지속적으로 인용되지만 널리 오독되고 있습니다:
cat /sys/module/kvm_intel/parameters/nested # Y or NVPS 내부의 이 설정은 사용자의 KVM 모듈 설정이며, L2 게스트가 3단계 중첩을 수행할 수 있는지 여부를 결정합니다. 이는 L0가 사용자에게 중첩 기능을 활성화했는지와는 무관하며, /proc/cpuinfo 및 kvm-ok이 그 해답을 제공합니다. nested 매개변수는 사용자가 직접 소유한 머신에서 설정하는 제어 항목입니다:
echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intelVM이 실행 중일 때는 모듈 제거가 거부되므로 먼저 게스트를 종료하십시오. 해당 머신이 Proxmox 호스트인 경우, Proxmox VE 9에서 중첩 가상화 활성화하기 문서에서 동일한 modprobe.d 변경 사항과 게스트 내부에서 플래그를 표시하기 위한 VM별 cpu: host 설정을 다룹니다.
대부분의 VPS 호스팅 업체가 이 기능을 비활성화하는 이유
- 라이브 마이그레이션.
vmx을 제공한다는 것은 해당 플래그를 포함하는 CPU 모델을 노출한다는 의미입니다. 해당 CPU 기능을 사용하는 게스트는 해당 기능이 없는 장비로 안전하게 마이그레이션할 수 없습니다. 고객의 가상 머신을 마이그레이션하여 노드를 비우는 호스트는 중첩 가상화를 활성화하는 순간 이 기능을 포기해야 합니다. - 공격 표면. 중첩된 VMX/SVM 경로는 커널 가상화 계층에서 가장 복잡한 코드 중 하나이며, 그에 걸맞은 CVE 이력을 가지고 있습니다.
- L0가 KVM이 아닐 수 있음.
systemd-detect-virt명령의 결과가vmware,xen또는microsoft라면, 중첩 가상화 규칙은 KVM이 아닌 해당 스택의 규칙을 따릅니다.
인스턴스에 플래그가 보이지 않습니까? 고객 지원팀에 문의하거나(일부 업체는 VM별로 활성화해 줍니다), 중첩 가상화를 명시하는 요금제를 선택하거나, 전용 서버로 이전하십시오. 이 가이드의 나머지 부분은 해당 플래그가 확인되는 장비의 root 권한을 가지고 있다고 가정합니다.
libvirt를 사용하여 L2 게스트 실행하기
sudo apt install -y qemu-system-x86 libvirt-daemon-system virtinst ovmf
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER" # log out and back in
virt-install \
--name guest1 \
--memory 2048 \
--vcpus 2 \
--cpu host-passthrough \
--disk path=/var/lib/libvirt/images/guest1.qcow2,size=20,format=qcow2,bus=virtio \
--network network=default,model=virtio \
--os-variant debian13 \
--location https://deb.debian.org/debian/dists/trixie/main/installer-amd64/ \
--graphics none \
--console pty,target_type=serial \
--extra-args 'console=ttyS0,115200n8'그래픽 세션은 필요하지 않습니다. 직렬(serial) 설치는 시간이 다소 소요되므로 지속 가능한 셸 환경에서 시작하십시오. VPS에서 Claude Code 세션을 유지하는 tmux 워크플로를 사용하면 SSH 연결이 끊겨도 virt-install 콘솔을 계속 연결된 상태로 유지할 수 있습니다. --os-variant debian13 명령이 거부된다면 사용 중인 osinfo-db 버전이 해당 릴리스보다 이전인 경우이므로, osinfo-query os을 실행하여 존재하는 이름을 선택하십시오. --cpu host-passthrough는 vmx를 L2 내부로 전달하며, L2에서 중첩 가상화(nested virtualization)를 수행해야 할 때만 필요합니다. virsh autostart guest1을 사용하여 게스트의 부팅 안전성을 확보하십시오.
디스크와 NIC에 사용하는 virtio 버스는 단순한 장식이 아닙니다. 에뮬레이션된 IDE 및 e1000 장치는 virtio 큐보다 하이퍼바이저로의 트랩(trap)이 훨씬 빈번하게 발생합니다. 중첩 가상화 환경에서는 L0가 스스로 완료할 수 없는 종료(exit)가 발생하면 L1으로 전달되며, 이를 처리하는 과정에서 추가적인 종료가 연쇄적으로 발생할 수 있습니다.
네트워킹: 튜토리얼에서 생략하는 부분
VPS는 하나의 공인 IP를 가지며 알 수 없는 MAC 주소를 차단하는 패브릭 뒤에 위치합니다. 이로 인해 두 가지 결과가 발생합니다.
L2 게스트를 공인 네트워크에 브리지로 연결하는 것은 일반적으로 작동하지 않습니다. 공인 NIC에 br0을 설정하고 게스트에 고유한 MAC 주소를 부여해도, ARP 요청은 나가지만 응답은 돌아오지 않습니다. 제공자의 스위치가 할당하지 않은 MAC 주소에서 오는 프레임을 폐기하기 때문입니다. 이러한 증상이 나타나면 브리지 디버깅을 중단하십시오. 이는 네트워크 구조상의 메커니즘입니다.
NAT 네트워크를 사용하십시오. libvirt는 default를 제공합니다: virbr0, 192.168.122.0/24, dnsmasq 임대, 아웃바운드 즉시 작동. 인바운드 연결의 경우, L1에서 TLS를 종료하고 프록시를 통과시키십시오. 아래의 인증서 경로는 Nginx에서 Certbot으로 Let's Encrypt 인증서 발급하기에서 가져온 것입니다:
server {
listen 443 ssl;
server_name lab.example.com;
ssl_certificate /etc/letsencrypt/live/lab.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/lab.example.com/privkey.pem;
location / {
proxy_pass http://192.168.122.50:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}먼저 게스트에 고정 임대(virsh net-edit default)를 부여하여 proxy_pass의 주소가 변경되지 않도록 하십시오.
관리 인터페이스는 인터넷에 노출하지 마십시오: 5900 포트의 VNC와 8006 포트의 Proxmox 웹 UI는 루프백에 두어야 하며, SSH 터널(ssh -N -L 8006:127.0.0.1:8006 you@your-vps)이나 VPS로 연결되는 자체 호스팅 WireGuard VPN을 통해 접근해야 합니다. 이렇게 하면 전체 192.168.122.0/24 게스트 대역이 하나의 사설 홉 거리에 위치하게 됩니다. 방화벽은 sudo ufw allow 22,80,443/tcp로 좁게 유지하고, 다른 포트는 열지 마십시오. ufw를 활성화한 직후 게스트의 아웃바운드 연결이 끊긴다면, 일반적인 원인은 /etc/default/ufw의 DEFAULT_FORWARD_POLICY="DROP" 설정입니다. 이를 ACCEPT로 변경하고 ufw를 다시 로드하십시오.
VPS에서의 Proxmox
Proxmox VE 9은 기반이 Debian 13이므로, pve-no-subscription 저장소를 추가하고 proxmox-ve 패키지를 설치하여 Debian VPS에 설치할 수 있습니다. 저장소와 키링 라인은 반드시 Proxmox의 현재 공식 문서에서 가져와야 하며, 오래된 블로그 게시물에서 복사한 URL은 설치 오류를 유발합니다. 아래의 네트워크 설정을 시작하기 전에 Proxmox를 임대 서버에 설치하는 것이 적절한지 고려해 볼 가치가 있으며, 가정용 Proxmox 서버와 임대 VPS 간의 비용 및 성능 비교 문서는 전력과 하드웨어 계산이 이미 완료된 상태에서 해당 질문에 대한 답을 제시합니다.
패키지 설치는 어려운 부분이 아닙니다. Proxmox는 물리 NIC에 브리지된 vmbr0를 기대하지만, 이는 앞서 언급한 MAC 필터링 문제라는 막다른 길로 이어집니다. VPS에서 작동하는 구성은 물리 포트가 연결되지 않은 NAT 또는 라우팅 방식의 vmbr0를 사용하고, 게스트를 사설 대역에 배치한 뒤, 공개 서비스는 호스트의 DNAT 규칙이나 리버스 프록시를 통해 처리하는 것입니다. 공개 서비스가 VM이 아닌 컨테이너인 경우, 하나의 Docker Compose 파일로 여러 앱을 서비스하는 Traefik 설정이 자동 인증서 발급과 함께 동일한 라우팅 작업을 수행합니다. 먼저 /etc/network/interfaces를 스냅샷으로 저장하십시오. 잘못된 브리지 설정은 콘솔 접근 권한이 없을 수도 있는 서버에서 사용자를 차단할 수 있습니다.
성능에 대한 솔직한 고찰
중첩 가상화는 단일 계층보다 느리며, 그 원인은 광범위하기보다 구체적입니다. 비용은 일반적인 명령어가 아닌, 가상 머신 종료(exit)와 주소 변환 과정에서 발생합니다. EPT/NPT가 활성화된 경우, L0는 L2를 위한 L1의 페이지 테이블과 자신의 페이지 테이블을 하나의 섀도 테이블로 통합하므로 TLB 히트 시에는 하드웨어 속도로 동작합니다. TLB 미스가 발생하면 비용이 증가합니다. 하드웨어가 게스트의 페이지 테이블과 섀도 테이블을 함께 탐색해야 하며, L1이 자신의 테이블을 변경할 때마다 L0가 섀도 테이블을 재동기화하기 위해 가상 머신 종료가 강제로 발생하기 때문입니다. 게스트 모드를 벗어나는 모든 작업, 즉 I/O, 타이머 인터럽트, MMIO, 프로세서 간 인터럽트가 비용을 발생시킵니다. L2의 종료는 L0가 처리하며, 다시 L1을 거쳐 반영될 수 있기 때문입니다. 작은 작업 집합을 다루는 CPU 집약적 작업은 네이티브와 유사한 성능을 보이지만, 메모리 사용량이 큰 작업은 TLB 미스로 인한 성능 저하가 발생하며, 시스템 콜, 패킷 처리, 디스크 I/O가 주를 이루는 작업은 계층 구조의 영향을 크게 받습니다.
따라서 모든 장치에 virtio를 사용해야 합니다. 또한 qcow2 파일이 이미 공급자가 가상화한 디스크 위에 존재한다면, 두 개의 씬 프로비저닝 계층이 쌓이게 됩니다. 이때 게스트 디스크에서 cache=none을 사용하면 동일한 블록이 두 개의 페이지 캐시에 동시에 머무르는 것을 방지할 수 있습니다. 벤치마크 수치는 제공하지 않습니다. 본인의 인스턴스에서 직접 워크로드를 측정하십시오.
실패 유형 및 확인되는 메시지
INFO: /dev/kvm does not exist / KVM acceleration can NOT be used (kvm-ok에서 발생). 모듈이 로드되지 않았거나 플래그가 노출되지 않은 상태입니다. 먼저 /proc/cpuinfo를 확인하십시오.
kvm: disabled by bios (dmesg에서 발생). 베어메탈 환경이라면 펌웨어 설정에서 VT-x/SVM을 활성화하십시오. VPS 내부에서 발생한다면 L0가 확장 기능을 제공하지 않는 것이며, 게스트에서 어떤 설정을 변경해도 해결되지 않습니다.
modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. 커널이 인식하는 CPU에 vmx가 없습니다. 이 역시 L0의 결정 사항입니다.
Could not access KVM kernel module: Permission denied. 하드웨어 문제가 아닌 권한 문제입니다. ls -l /dev/kvm의 그룹이 kvm이고 모드가 660인지 확인하십시오. 해당 그룹에 사용자를 추가한 뒤 새로운 로그인 셸을 시작하십시오. 그룹 멤버십은 이미 실행 중인 세션에 즉시 적용되지 않습니다.
kvm: Device or resource busy (QEMU 시작 시 발생). 다른 하이퍼바이저 모듈이 CPU를 점유하고 있습니다. lsmod를 실행하여 kvm_intel과 함께 vboxdrv 또는 VMware 모듈이 있는지 확인하고, 불필요한 모듈을 언로드하십시오.
/var/run/libvirt/libvirt-sock: No such file or directory (virsh에서 발생). 데몬이 중지된 상태입니다. sudo systemctl enable --now libvirtd를 실행하십시오.
Proxmox: KVM virtualisation configured, but not available. 하드웨어 가속을 제공할 수 없는 호스트에서 게스트의 KVM 가속 옵션이 켜져 있습니다. 중첩 가상화(nesting)를 수정하거나, 해당 옵션을 끄고 에뮬레이션을 사용하십시오.
Android emulator: x86_64 emulation currently requires hardware acceleration! /dev/kvm와 동일한 문제이며, 보통 그룹 권한 문제입니다.
오류는 없으나 매우 느리게 작동함. 가속기 플래그 없이 실행된 QEMU는 소프트웨어 에뮬레이터인 TCG로 대체됩니다. 정상 작동하지만 속도가 매우 느려, 수 초 걸리던 부팅이 수 분으로 늘어납니다. -accel kvm을 명시적으로 전달하여, QEMU가 조용히 에뮬레이션하는 대신 오류를 발생시키고 중단하도록 설정하십시오.
실행 도중 게스트가 사라짐. dmesg에서 Out of memory: Killed process ... qemu-system-x86_64를 확인하십시오. L2 게스트는 L1의 프로세스로 간주되므로, OOM killer가 일반 프로세스와 동일하게 처리합니다. L2의 RAM은 L1의 고정 할당량에서 차감되며, 호스트로부터 추가로 빌려올 수 없습니다.
운영: 백업, 업그레이드, 제한
백업. 실행 중인 게스트의 qcow2 파일을 복사하면 데이터 불일치가 발생할 위험이 있습니다. 게스트가 읽기 작업 중에도 계속 데이터를 쓰기 때문입니다. virsh shutdown guest1를 실행한 뒤 virsh domstate guest1이 shut off을 보고할 때까지 기다렸다가(종료 명령은 게스트가 완전히 멈추기 전에 반환될 수 있습니다) 복사하십시오. 또는 외부 스냅샷(virsh snapshot-create-as guest1 snap1 --disk-only --atomic)을 생성하여 쓰기 작업이 오버레이로 향하게 한 뒤, 정지된 베이스 이미지를 복사하고 virsh blockcommit guest1 vda --active --pivot으로 병합하는 방법도 있습니다. 복사본은 VPS 외부로 전송하십시오. 동일한 디스크에 저장된 스냅샷은 어떠한 장애로부터도 보호해주지 못합니다.
업그레이드. apt full-upgrade는 새로운 kvm_intel/kvm_amd 모듈을 설치하지만, 재부팅하기 전까지 실행 중인 커널은 이전 모듈을 계속 사용합니다. 이전 커널을 유지하고 커널 변경 시마다 kvm-ok을 다시 실행하십시오. vmx 없이 부팅된 호스트는 부팅 항목을 하나만 변경하면 즉시 정상 상태로 복구할 수 있습니다.
확장성의 한계. 하나의 공인 IP를 사용하면 모든 L2 서비스는 프록시나 L1의 DNAT 규칙을 통해서만 외부와 통신할 수 있습니다. 라이브 마이그레이션은 지원되지 않습니다. CPU 경합이 발생하면 중첩된 종료 경로(nested exit path)에서 가장 먼저 성능 저하가 나타납니다. 또한 여러 게스트를 운영하는 하이퍼바이저는 이미 RAM을 모두 할당한 상태이므로, 중첩된 VM은 고정된 할당량을 초과하여 메모리를 오버커밋할 수 없습니다. 랩 환경이 이 범위를 벗어나면 중첩 스택을 더 높게 쌓는 것이 답이 아닙니다. 그때는 사용자가 L0가 되어 이 모든 제약이 적용되지 않는 전용 장비를 도입해야 합니다.
FAQ
VPS에서 Docker를 실행하려면 중첩 가상화(nested virtualization)가 필요한가요?
아니요. 컨테이너는 VPS의 커널을 공유하며 /dev/kvm를 열지 않으므로, vmx이나 svm 플래그가 없는 일반 인스턴스에서도 Docker와 Docker Compose를 문제없이 실행할 수 있습니다. 중첩 가상화는 Proxmox 랩, Windows 게스트, Firecracker microVM, Android 에뮬레이터 또는 VM 이미지를 부팅하는 CI 러너와 같이 두 번째 커널이 필요한 경우에만 고려하면 됩니다.
내 VPS가 중첩 가상화를 지원하는지 어떻게 확인하나요?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u를 실행한 다음 cpu-checker 패키지의 kvm-ok을 실행하십시오. 사용 가능한 인스턴스라면 vmx(Intel) 또는 svm(AMD)이 출력되고, kvm-ok은 KVM acceleration can be used을 보고하며, kvm 그룹과 660 모드를 가진 /dev/kvm가 존재합니다. 이 질문과 관련하여 /sys/module/kvm_intel/parameters/nested는 무시하십시오. 해당 파일은 제공자의 하이퍼바이저가 노출한 정보가 아니라 사용자의 KVM 모듈 자체를 설명합니다.
왜 대부분의 VPS 제공자는 중첩 가상화를 비활성화하나요?
vmx을 노출한다는 것은 해당 플래그를 포함한 CPU 모델을 게스트에게 전달한다는 의미입니다. 해당 CPU 기능을 사용하는 게스트는 해당 기능이 없는 머신으로 라이브 마이그레이션할 수 없으므로, 고객을 이동시켜 노드를 비우는 제공자는 이 기능을 포기하게 됩니다. 또한 중첩 VMX/SVM 코드 경로는 긴 CVE 이력을 가지고 있습니다. 일부 호스트는 요청 시 VM별로 이를 활성화해주기도 하며, 일부는 요금제 기능으로 중첩 가상화를 명시하기도 합니다.
중첩 VM이 공용 브리지에서 네트워크를 사용할 수 없습니다. 무엇이 문제인가요?
제공자의 스위치는 할당되지 않은 MAC 주소에서 오는 프레임을 차단합니다. 따라서 공용 NIC에 브리지된 L2 게스트가 ARP를 보내도 응답을 받을 수 없습니다. br0 디버깅을 중단하고, libvirt의 NAT default 네트워크(virbr0, 192.168.122.0/24)를 사용하십시오. 게스트에게 고정 IP를 할당하고, 공개가 필요한 서비스는 VPS 자체의 리버스 프록시나 DNAT 규칙을 통해 노출하십시오.
중첩 VM은 얼마나 느린가요?
성능 저하는 VM 종료(VM exit)와 주소 변환에서 발생합니다. EPT/NPT가 활성화된 상태에서 L2 내부의 명령어와 TLB 히트는 하드웨어 속도로 실행되지만, TLB 미스가 발생하면 추가 페이지 테이블을 탐색해야 합니다. 또한 I/O, 타이머 인터럽트, MMIO, IPI는 L0에서 처리되며 L1을 거쳐 다시 전달될 수 있습니다. 작은 작업 세트를 가진 CPU 집약적 작업은 네이티브와 비슷하게 보이지만, 대규모 메모리 작업 세트나 시스템 호출, 패킷, 디스크 부하가 많은 작업은 모든 계층의 영향을 받습니다. 모든 곳에 virtio 장치를 사용하고 게스트 디스크에 cache=none을 설정한 뒤, 직접 워크로드를 측정해 보십시오.