10장 가상화
1. 가상화 시스템의 구조 – 가짜가 진짜처럼 작동하는 원리
1) “한 기계 안에 또 다른 컴퓨터가 있다?” – 가상화란 무엇인가
요즘은 누구나 한 번쯤 이런 상황을 마주합니다:
윈도우에서 리눅스를 돌려본다든가,
개발 환경을 바꿔서 테스트하고 싶을 때,
클라우드에서 여러 운영체제를 동시에 운영할 때 등등.
이런 걸 가능하게 해주는 마법 같은 기능이 바로 가상화(Virtualization)입니다.
가상화란 말 그대로, 물리적인 것이 아닌 ‘가짜’를 만들어 마치 진짜처럼 작동하게 만드는 기술입니다. 그런데 이 ‘가짜 컴퓨터’가 진짜처럼 작동한다는 점이 중요합니다.
즉, 하나의 물리 기기에서 여러 개의 가상 컴퓨터(VM, Virtual Machine)가 동시에 실행될 수 있다는 뜻이죠.
가상화 기능은 PC나 서버 등의 물리적인 기기에서 가상 머신을 동작시키는 소프트웨어 기능 및 그런 동작을 돕는 하드웨어 기능의 조합
2) 왜 가상화가 필요했을까?
가상 머신은 단순히 재미로 만든 게 아닙니다. 분명한 목적과 필요가 있었기 때문이죠:
💡 가상 머신 활용 목적
하드웨어 최대 활용
하나의 서버에서 여러 시스템 운영 → 자원 낭비 ↓
머신 1대 에 가상 머신을 여러 개 만들고, 각각의 가상 머신을 고객이 빌려 쓰는
IaaS(Infrastructure as a Service)가 그 예
서버 통합
수십 대의 서버 → 몇 대의 가상 머신으로 대체 가능
레거시 시스템 수명 연장
오래된 OS도 새 기기에서 실행 가능 (지원 종료돼도 OK)
크로스 운영체제 사용
윈도우 안에서 리눅스를, 리눅스 안에서 윈도우를 실행 가능
개발 및 테스트 환경 분리
실환경을 흉내 낸 테스트 환경을 손쉽게 구성 가능
자동화 테스트 및 배포
커널 개발, CI/CD 시스템에 활용
요즘 개발자들이 가상 머신을 많이 사용하는 이유도 여기에 있죠.
"윈도는 써야 하지만, 리눅스 커널도 만져야 하고… 둘 다 필요해!"
3) 가상 머신의 구성 – 어떻게 만들어지나?
가상 머신을 가능하게 해주는 중심에는 바로 가상화 소프트웨어(Virtualization Software)가 있습니다. 이 친구가 물리 기기의 자원을 잘게 나누고, 각각의 가상 머신에 배분해주는 역할을 하죠.
📦 가상화 소프트웨어는 이렇게 생겼어요
가상 머신 입장에서는 CPU, 메모리, 저장장치가 모두 자신만의 것처럼 보입니다. 하지만 실제로는 물리 자원의 일부만을 쓰고 있는 것이죠.
물리 CPU → PCPU (Physical CPU)
가상 CPU → VCPU (Virtual CPU)
"진짜 CPU는 하나지만, 가상 머신에는 각각 CPU가 할당된 것처럼 보인다!"
가상화 소프트웨어와 가상 머신의 관계는 커널의 프로세스 관리 시스템과 프로세스의 관계와 무척 닮았습니다.
🖼️ 그림 설명: 가상화 소프트웨어 구조
💡 전체 구조 요약
[물리 기기] ──▶ [가상화 소프트웨어] ──▶ [가상 머신]가상화 소프트웨어는 물리 기기의 자원을 일정 부분 나눠서 가상 머신에게 할당해주는 역할을 합니다. 가상 머신 입장에선 자신만의 자원을 쓰는 것처럼 느끼게 되는 것이죠.
✅ 구성 요소별 설명
PCPU (Physical CPU)
물리 기기에 실제로 장착된 CPU. 가상 머신에서 요청하는 작업을 실행하는 실제 하드웨어
VCPU (Virtual CPU)
가상 머신에 제공되는 CPU. 실제론 PCPU를 시간 단위로 쪼개어 배정한 것
메모리
물리 기기 전체 메모리 중 일부를 잘라서 가상 머신에 제공. 가상 머신은 자기 메모리라고 생각함
저장 장치
HDD, SSD 등의 저장 장치. 이 역시 일부만 가상 머신이 사용하게끔 나눠줌
가상화 소프트웨어
이 모든 자원 분배를 제어하는 '매니저'. 사용자는 여러 VM을 만들고, 각각 원하는 만큼 자원을 배분
🔁 작동 방식 요약
물리 CPU(PCPU)는 가상 CPU(VCPU)에게 일부 처리 능력을 나눠줍니다. → 여러 가상 머신이 같은 CPU를 시간 단위로 번갈아 사용해요.
메모리도 마찬가지로, 실제 메모리에서 일부 구간을 잘라서 가상 머신에 제공해요. → 각 가상 머신은 자신이 ‘고유 메모리’를 가진 줄 압니다.
저장 장치도 파티션처럼 나눠서 가상 머신에 제공합니다. → 이게 바로 가상 하드디스크(Virtual Disk, .vmdk 등)의 개념이에요.
🧠 핵심 이해 포인트
가상 머신은 실제 자원을 100% 가진 게 아니다! → 가상화 소프트웨어가 일부만 ‘할당’해서 진짜처럼 보이게 해주는 것일 뿐
가상 머신은 독립된 컴퓨터처럼 보이지만, 실제로는 하나의 물리 기기 안에서 돌아가는 ‘논리적 컴퓨터’입니다.
가상화 소프트웨어는 운영체제의 커널처럼 자원을 나눠 쓰게 해주는 관리자 역할을 합니다.
🧩 비유로 쉽게 이해하기
이 구조를 "공유 오피스"에 비유하면 이렇습니다:
물리 기기
공유 오피스 전체 건물
PCPU
건물 안에 있는 회의실 (한 개뿐)
VCPU
각 팀이 예약해서 쓰는 회의 시간 (1011시, 1112시...)
메모리
각 팀에게 배정된 책상 수
저장 장치
각 팀에게 배정된 사물함 공간
가상 머신
독립된 스타트업 팀 (각자 자기 공간인 줄 알고 씀)
가상화 소프트웨어
공유 오피스 관리자, 공간과 자원을 배정해줌
🔚 요약
그림 10-02는 가상화 소프트웨어가 물리 자원을 가상 머신에 할당하는 구조를 시각화한 것입니다.
이 구조 덕분에 우리는 하나의 물리 컴퓨터에서 여러 개의 운영체제와 프로그램을 동시에 실행할 수 있습니다.
실제 자원은 나누어 쓰는 것이며, 가상 머신은 '진짜처럼 착각하도록' 정교하게 설계된 가짜 컴퓨터입니다.
4) 가상 머신은 어떻게 OS를 실행하는가?
우리가 컴퓨터에 리눅스를 설치하는 구조와 거의 같습니다.
💻 일반적인 구조 - 물리 기기에 os를 설치한 경우
🧩 가상 머신 위의 구조는? - 가상 머신에OS 설치한 경우
이처럼 가상화 소프트웨어 위에 [그림 10-03]에서 봤던 시스템이 올라가는 구조가 됩니다. 가상 머신과 물리 기기 는 장치 구성 등 일부를 제외하면 차이가 없으므로 가상 머신이 제공하는 각종 하드웨어를 지원 하는 OS가 있으면 뭐든지 설치할 수 있습니다.
즉, 각 가상 머신 위에 원하는 게스트 OS를 설치하고, 그 안에서 진짜 컴퓨터처럼 동작하게 하는 겁니다.
가상 소프프트웨어를 구현하는 방법
하드웨어에 직접 하이퍼바이저 hypervisor 가상화 소프트웨어를 설치하는 방법
기존 OS를 바탕으로 애플리케이션으로 동작하는 방법
유명한 소프트웨어
VM웨어VMware 사의 각종 제품
오라클Oracle 사의 버추얼박스VirtualBox
마이크로소프트 Microsoft 사의 하이퍼-VHyper-V
시트릭스 시스템즈Citrix Systems 사의 젠x
5) 가상화 소프트웨어의 3종 세트
이번 장에서는 리눅스 기반의 오픈소스 가상화 환경을 다루고 있습니다. 대표 구성은 이렇습니다:
KVM
리눅스 커널에 통합된 가상화 기능
QEMU
하드웨어(특히 CPU) 에뮬레이터 역할
virt-manager
GUI로 가상 머신 생성, 삭제, 조작 (QEMU 관리)
이 조합은 실제로 기업 환경에서도 많이 쓰이며, 완전히 무료로 사용 가능합니다.
리눅스에선
sudo apt install virt-manager한 줄이면 세팅 가능!
6) 가상 머신은 프로세스다? – 리눅스 커널이 바라보는 가상 머신
QEMU나 virt-manager는 결국 리눅스 프로세스입니다. 즉, 리눅스 입장에서는 가상 머신도 그냥 실행 중인 프로그램 하나인 거예요.
ps aux로 보면 QEMU가 떡하니 떠 있음top으로 보면 CPU 자원도 쓰고 있음
그러면 궁금해지죠?
“이 QEMU가 어떻게 리눅스, 윈도 같은 OS를 실행할 수 있는 걸까?”
그건 바로 KVM의 도움 덕분입니다.
QEMU는 하드웨어를 흉내 내고,
KVM은 CPU 실행을 하드웨어 수준에서 빠르게 처리합니다.
💡 요약
virt-manager: 가상 머신 정의 및 관리
QEMU: 실행자
KVM: 성능 최적화를 위한 가속기
7) 호스트 OS와 게스트 OS
호스트 OS
가상화 소프트웨어가 설치된 OS (실제 리눅스 등)
게스트 OS
가상 머신 안에 설치된 운영체제
게스트 OS는 자신이 가상 머신 위에 있다는 걸 몰라도 됩니다. 자신만의 CPU와 메모리를 가지고 있다고 믿죠.
그런데 실제로는…
CPU는 나눠쓴다 (스케줄링)
메모리도 나눠쓴다
입출력도 가상 장치를 통해 공유된다
즉, "분리된 듯 연결된 상태"에서 각 가상 머신이 돌아가는 거죠.
8) virt-manager는 ‘가짜 손’이다
virt-manager는 마치 가상의 손처럼 행동합니다.
가상 머신을 켜고 끄고,
마우스와 키보드 입력을 전달하고,
CD/DVD 장치를 마운트하거나 꺼내는 일도 할 수 있어요.
즉, 실제 사람이 컴퓨터를 조작하는 것처럼 → virt-manager가 그걸 대신해주는 거예요.
virt-manager와 QEMU는 리눅스 커널 입장에서는 그저 프로세스에 불과합니다. 따라서 가상 화 소프트웨어와 함께 일반적인 프로세스를 실행합니다.
┌──────────────┐
│ virt-manager │ ← 마우스/키보드, 화면 출력 연결
│ │
│ QEMU │ ← 가상 머신 실제 실행
└──────────────┘🔁 전체 흐름 순서
virt-manager가 가상 머신 설계도 작성
사용자에게 GUI를 제공하여 가상 머신의 사양을 설정함
CPU 개수
메모리 용량
디스크 이미지(.qcow2)
네트워크 구성
ISO 이미지 삽입 등
virt-manager가 QEMU 프로세스를 기동
사용자가 '가상 머신 시작' 버튼을 누르면,
QEMU가 백그라운드에서 새로운 가상 머신 인스턴스를 실행함
QEMU와 KVM이 함께 가상 머신을 실행
QEMU: CPU 에뮬레이션, 하드웨어 장치 흉내
KVM: CPU 가상화를 리눅스 커널 수준에서 직접 실행 (속도 빠름)
virt-manager가 전원 관리 및 삭제 기능 수행
사용자가 끄기/재시작/삭제 버튼을 누르면 QEMU와 커널에 요청을 전달
🧠 각 구성 요소의 역할
virt-manager
사용자가 가상 머신을 쉽게 만들고 관리하도록 도와주는 GUI 툴
QEMU
CPU, I/O, 네트워크 등 가상 하드웨어를 '에뮬레이션'해주는 프로그램
KVM
리눅스 커널 안에서 동작하는 고속 가상화 엔진 (QEMU와 연결해서 성능을 높임)
💡 virt-manager는 그냥 GUI일 뿐, 실제 실행은 QEMU/KVM이 합니다.
그림 10-06은 다음과 같은 구조를 보여줍니다:
🔧 virt-manager의 주요 기능 요약
디스플레이 출력 보기
가상 머신 내부 화면을 GUI로 보여줌
키보드/마우스 조작
마우스, 키보드 이벤트를 가상 머신으로 전달
전원 켜기/끄기/재시작
가상 머신의 전원 상태 관리
장치 추가/삭제
디스크, 네트워크, USB 등 장치를 가상 머신에 동적으로 붙이거나 제거
ISO 삽입/제거
가상 CD/DVD 드라이브에 이미지 삽입 또는 추출
📌 핵심 요약
virt-manager는 사용자와 QEMU/KVM 사이의 ‘조정자’입니다.
실제 가상 머신은 QEMU + KVM 조합으로 실행됩니다.
이 조합은 직접 명령어로 조작할 수도 있고, virt-manager로 간편하게 제어할 수도 있어요.
모든 동작은 결국 리눅스에서 돌아가는 하나의 프로세스처럼 취급됩니다.
9) Nested Virtualization – 가상 머신 안의 가상 머신
"가상 머신 안에서도 가상 머신을 만들 수 있을까?"
네, 요즘은 가능합니다! 이걸 중첩 가상화(nested virtualization)라고 합니다.
특히 클라우드 환경에서 많이 쓰입니다.
예: Google Cloud 위에 리눅스 가상 머신 생성
그 리눅스 가상 머신에서 또 다른 리눅스/윈도 설치
하지만…
하이퍼바이저(가상화 엔진)가 중첩 가상화를 지원해야 합니다
성능도 다소 떨어질 수 있습니다
“클라우드 속 가상 머신 안에서 또 다른 클라우드를 띄운다” 요즘 DevOps 환경에서 테스트나 CI/CD용으로 자주 사용됩니다.
✅ 마무리: 가상은 진짜가 될 수 있다
가상 머신은 이제 단순한 실험 도구를 넘어, 진짜 운영 환경의 핵심 인프라로 자리잡았습니다.
클라우드? = 가상 머신의 제국
서버 통합? = 가상화 없인 불가능
테스트 환경 구축? = 가상 머신이 없으면 너무 불편
이 모든 걸 가능하게 하는 건, OS와 커널이 만들어내는 철저한 격리와 가상화 기술 덕분입니다.
진짜처럼 보이는 가짜, 그러나 실제보다 더 유용한 그 무엇.
이것이 가상화의 매력이자, 우리가 반드시 알아야 할 시스템의 세계입니다.
2. CPU의 가상화 기능과 QEMU+KVM의 동작 구조 정리
1) 사용자 모드와 커널 모드의 CPU 동작
사용자 모드
일반 애플리케이션이 실행되는 영역→ 제한된 자원 접근만 가능
커널 모드
시스템 콜, 드라이버 등 OS 커널이 실행되는 영역→ 모든 자원 접근 가능
전환 조건
시스템 콜, 인터럽트 등 발생 시 사용자 → 커널 모드로 진입하고 복귀함
→ CPU는 보안과 안정성을 위해 사용자/커널 모드를 구분해서 자원 접근을 제한합니다.
2) 가상화 확장: VMX-root vs VMX-nonroot
가상화를 지원하는 CPU는 기존 사용자/커널 모드 구조를 확장하여 다음과 같은 상태를 가집니다.
VMX-root 모드
하이퍼바이저(KVM)나 호스트 커널이 동작하는 영역 물리 기기 처리를 하는 모드
VMX-nonroot 모드
가상 머신(게스트 OS)이 실행되는 상태게스트 입장에서 '자기 OS의 사용자/커널 모드'가 있음 가상 머신 처리 모드
전환 조건
게스트 OS가 하드웨어 접근 또는 특권 명령 실행 시 VMX-root로 전환됨 (트랩)
이 구조 덕분에 CPU는 가상 머신을 하드웨어 수준에서 분리하고 제어할 수 있습니다.
3) CPU 가상화 기술: VT-x와 SVM
Intel
VT-x (Intel Virtualization)
AMD
SVM (Secure Virtual Machine)
기능은 유사하지만 명령어셋이 다름
이렇게 아키텍처별로 달라지는 부분은 KVM이 해결 해주는데, 커널에서는 이를 KVM이 추상화해 처리함
VT-X 또는 SVM이 활성 여부 확인 명령어
egrep -c '^flags.*(vmx|svm)' /proc/cpuinfo출력이 1 이상이면 활성화 상태. 만약 0이라면 BIOS에서 해당 기능이 꺼져 있을 가능성이 있음.
4) QEMU + KVM 가상 머신의 동작 구조
1. 물리 환경에서 장치 접근 흐름
2. 가상 환경에서의 흐름 (QEMU + KVM)
가상 머신에서 보면 [그림 10-11]의 물리 기기와 똑같은 일을 하는 것처럼 보이지만(처리 1. 2, 7, 8) 무대 뒤를 보면 물리 기기에서 QEMU와 KVM이 하드웨어를 에뮬레이션하고 있습 니다(처리 3-6).
QEMU: 가상 하드웨어를 에뮬레이션하는 사용자 공간 프로그램 KVM: CPU 가상화, 메모리 보호 등을 커널에서 담당
🖼️ [그림 10-12] 가상 머신의 장치 접근 흐름
1️⃣ 가상 머신 내 프로세스가 시스템 콜 실행 → 파일이나 디바이스에 접근하기 위해 시스템 콜을 호출합니다. → 게스트 리눅스 커널로 진입 (게스트 OS의 커널 모드)
2️⃣ 게스트 커널이 장치에 접근하려고 함 → 하지만 이 장치는 실제 장치가 아니라 QEMU가 에뮬레이션하는 장치이므로, VM Exit 발생 (즉, CPU가 하드웨어 자원을 직접 사용할 수 없다고 판단)
3️⃣ KVM이 VM Exit을 감지하고 모드를 VMX-root로 전환 → KVM은 이 이벤트를 QEMU에게 전달 → QEMU는 사용자 공간에서 장치 접근을 에뮬레이션 처리
4️⃣ QEMU가 처리한 결과를 KVM으로 다시 전달하고 복귀
[그림 10-13] 위 흐름에 따른 CPU의 모드 전환 (시간 흐름)
1. 가상 머신 입장에서 본 CPU 상태 변화
시간축 →
┌──────────────────────────────────────────────┐
│ 가상 머신에서 CPU의 상태: 사용자 모드 → 커널 모드 → 복귀 │
└──────────────────────────────────────────────┘
- 가상 머신 내부에선 평범한 커널 모드 진입처럼 보임2. 물리 기기 입장에서 본 실제 CPU 상태 변화
시간축 →
┌──────────────────────────────────────────────┐
│ VMX-nonroot 사용자 모드 │
│ ↓ │
│ VMX-nonroot 커널 모드 ← (게스트 커널 진입) │
│ ↓ │
│ VM Exit → VMX-root 모드로 전환 (KVM으로 전환됨) │
│ ↓ │
│ QEMU (유저 공간)에서 장치 처리 │
│ ↓ │
│ 복귀 후 다시 VMX-nonroot → 게스트 OS로 복귀 │
└──────────────────────────────────────────────┘핵심 요약
[1]
게스트 사용자 모드
VMX-nonroot 사용자
[2]
게스트 커널 모드
VMX-nonroot 커널
[3]
장치 접근 → VM Exit 발생
VMX-root 커널 (KVM 진입)
[4]
QEMU 호출 → 에뮬레이션
사용자 공간 처리
[5]
완료 후 복귀
다시 VMX-nonroot 커널
[6]
게스트 사용자 모드로 복귀
VMX-nonroot 사용자
💡 결론 요약
게스트 OS 내부에서는 그냥 커널이 장치를 접근하는 평범한 시스템 콜처럼 보입니다.
하지만 물리 CPU 입장에서 보면 VMX-nonroot → VMX-root → 유저 공간(QEMU) → 복귀 과정을 반복하며 매우 복잡하게 작동합니다.
이 구조 덕분에 가상 머신은 실제 하드웨어처럼 보이면서도, 안전하게 격리되어 실행됩니다
CPU 가상화 기능이 없던 시절의 가상화는 어떻게 가능했을까?
✅ 배경
오늘날은 대부분의 CPU가 하드웨어 수준의 가상화 기능(VT-x for Intel, SVM for AMD)을 내장하고 있지만, 초창기에는 이런 기능 없이도 가상화 소프트웨어(VMware, VirtualBox 등)가 존재했습니다.
🔍 그런데 문제는?
가상 머신이 동작하기 위해서는 내부에서 하드웨어 자원(예: 장치, 레지스터 등)에 접근하려 할 때
이를 호스트(물리 기기)에서 감지하고 제어를 넘겨받아야 합니다.
예: 게스트 OS가
IN이나OUT명령으로 I/O 장치를 직접 조작하려 할 때, 그걸 호스트가 가로채지 못하면 위험하거나 충돌이 일어날 수 있음.
🛠️ 해결책 – 반가상화 (Para-Virtualization)
가상화 기능이 없던 시절에는 이런 문제를 소프트웨어적으로 해결했는데, 그 방식이 바로 반가상화입니다.
📌 반가상화란?
게스트 운영체제(커널 등)의 일부 코드를 수정해서,
하드웨어 자원에 직접 접근하지 않고,
특수한 API 또는 하이퍼바이저 호출(hypercall)을 통해 대신 처리하게 만듭니다.
🧠 예시
원래
mov명령으로 특정 레지스터에 접근할 게스트 커널이 있었다면, 반가상화에서는 그 부분을hypercall()함수로 교체해 호스트가 직접 개입할 수 있게 합니다.
⚠️ 단점
게스트 OS의 커널 코드를 수정해야 하기 때문에,
운영체제 수정이 가능하거나 오픈소스일 때만 사용 가능함 (예: 리눅스).
윈도우 같은 폐쇄형 OS에서는 어려움이 있음.
🔍 요약 표
방식
CPU가 직접 VM을 지원
소프트웨어가 직접 제어 (반가상화)
게스트 커널 수정
❌ 불필요
✅ 필요
예시 기술
KVM, Hyper-V
Xen (early version), VMware (early)
감지 방법
VM Exit 발생 시 자동 전환
실행 코드를 미리 바꿔서 호스트가 감지
📚 더 알아보고 싶다면?
검색 키워드:
Para-virtualization,Xen hypercall,VMware binary translation
5) 가상 머신은 프로세스다?
가상 머신을 실행하면 qemu-system-x86_64라는 하나의 프로세스로 리눅스 호스트에 나타납니다.
$ ps ax | grep qemu-systemqemu-system-x86_64
가상 머신 실행 프로세스
virt-manager
GUI 기반 가상 머신 관리 도구
virsh
CUI 기반 가상 머신 제어 도구 (libvirt)
📝 virsh list로 현재 실행 중인 가상 머신을 확인할 수 있고,
virsh dumpxml [vmname]으로 설정(XML)을 확인할 수 있습니다.
6) 가상 머신을 만드는 명령어 예시
virt-install --name ubuntu2004 \
--vcpus 1 --cpuset=0 \
--memory 8192 --os-variant ubuntu20.04 \
--graphics none --extra-args 'console=ttyS0'이 명령은 다음 설정을 가진 가상 머신을 생성합니다:
이름: ubuntu2004
CPU 1개
메모리 8GB
설치용 ISO를 통해 부팅
7) 가상 머신 1개 = qemu 프로세스 1개
2개의 가상 머신을 실행하면 다음과 같이 2개의 qemu 프로세스가 생깁니다.
$ ps ax | grep qemu-system
21945 ? Sl0:09 /usr/bin/qemu-system-x86_64 -name guest=ubuntu2004
22004 ? Sl0:07 /usr/bin/qemu-system-x86_64 -name guest=ubuntu2004-clone8.) IaaS & 오토 스케일링 구조
가상화가 중요한 이유 중 하나는 클라우드 자동화 및 스케일링에 필수이기 때문입니다.
1️⃣ 부하 감지
모니터링 시스템이 부하 상승 감지
2️⃣ 가상 머신 조작
관리 도구(libvirt 등)를 통해 자동 생성
3️⃣ 서비스 확장
자동으로 가상 머신 추가 후 트래픽 분산
📌 클라우드 시스템에서는 사람이 수동으로 가상 머신을 관리하지 않고, 프로그래밍 방식으로 VM을 조작할 수 있어야 합니다.
📌 핵심 요약
VMX-root
호스트 OS, 하이퍼바이저가 동작
VMX-nonroot
게스트 OS(가상 머신)가 실행되는 모드
KVM
커널 레벨 가상화 처리 담당
QEMU
사용자 공간의 가상 장치 에뮬레이션 담당
libvirt
가상 머신 제어 라이브러리 (virsh, virt-manager)
IaaS 오토스케일링
가상 머신을 자동으로 증설/축소할 수 있는 구조
3. 가상 머신은 호스트 OS에서 어떻게 보일까?
1) 가상 머신의 구성과 작성 방법
가상 머신을 만들기 위해선 다음과 같은 구성 요소를 정의합니다:
OS
우분투 20.04 / x86_64
가상 CPU
1개 (vCPU), PCPU 0번에 pin 지정
메모리
8GiB
디스크
기본 드라이버인 virtio 사용
🛠️ virt-manager 또는 CLI로 작성 가능
virt-install --name ubuntu2004 \
--vcpus 1 --cpuset=0 \
--memory 8192 \
--os-variant ubuntu20.04 \
--graphics none \
--extra-args 'console=ttyS0'위 명령은 GUI 없이 CLI에서 가상 머신을 만들기 위한 예시입니다.
console=ttyS0은 설치 진행 상황을 콘솔에서 확인하기 위한 옵션입니다.
2) 가상 머신 설정(XML)의 정체
virt-manager 또는 virsh는 XML 형식의 설정 파일을 기반으로 가상 머신을 구성합니다.
예시: virsh dumpxml ubuntu2004
<domain type='kvm' id='23'>
<name>ubuntu2004</name>
<memory unit='KiB'>8388608</memory>
<vcpu placement='static' cpuset='0'>1</vcpu>
<devices>
<disk type='file' device='disk'>
<source file='/var/lib/libvirt/images/ubuntu2004.qcow2'/>
</disk>
</devices>
</domain>주요 필드 요약
<name>
ubuntu200
가상 머신 이름 (식별자)
<memory>
8388608(8GIB
메모리 용량 (KiB 단위)
<vcpu>
1
vCPU 개수 및 CPU 핀 설정 cpuset attribute 값은 VCPU가 동작 가능한 VCPU 목록
devices
ㅡ
가상 머신에 설치된 하드웨어 목
<disk>
ㅡ
저장 장치. 이 뒤에 있는 file은 저장 장치에 대응하는 파일
이 XML은 내부적으로 qemu-system-x86_64 명령어로 변환되어 실행됩니다.
3) 실행 후 호스트에서의 가상 머신 인식
가상 머신 실행
virsh start ubuntu2004가상 머신 확인
virsh list출력 예:
Id Name State
-----------------------------
23 ubuntu2004 runningps 명령으로 확인
ps ax | grep qemu-system19904 ? Sl 3:06 /usr/bin/qemu-system-x86_64 -name guest=ubuntu2004 ...✔ 포인트: qemu-system-x86_64 프로세스 하나가 가상 머신 하나에 대응합니다.
가상 머신은 qemu-system-x86_64 프로세스에 1대1로 대응합니다.
4) XML ↔ qemu 명령어 매핑 구조
프로세스에는 수많은 명령줄 인수가 지정됩니다. 그중에 서 비교적 알아보기 쉽고 중요해 보이는 인수에 주목하면 cpu device, drive처럼 하드웨어와 관련된 내용이 많다는 것을 알 수 있습니다. 게다가 이런 값은 앞에서 본 XML 파일 내용과 상 당히 비슷합니다. 그건 virsh가 가상 머신의 XML 파일 내용을 qemu-system-x86_64 명령어 가 해석할 수 있는 형태로 변환해서 인수로 전달하기 때문입니다(그림 10-14).
virsh 또는 virt-manager → 내부적으로 XML 구성
libvirt → 이를 qemu 명령어로 변환
qemu-system-x86_64 → 실제 가상 머신 실행 프로세스
# 예시 명령어의 일부
/usr/bin/qemu-system-x86_64 \
-name guest=ubuntu2004 \
-smp 1 \
-m 8192 \
-drive file=ubuntu2004.qcow2 ...이렇게 가상 머신 1개 = qemu 프로세스 1개로 확인할 수 있습니다.
5) 여러 가상 머신을 실행하면?
복제 예시 (virt-clone 사용)
virt-clone -o ubuntu2004 -n ubuntu2004-clone --auto-clone두 가상 머신 실행 후 확인
virsh start ubuntu2004
virsh start ubuntu2004-clone
ps ax | grep qemu-system출력 예:
21945 ? Sl 0:09 /usr/bin/qemu-system-x86_64 -name guest=ubuntu2004 ...
22004 ? Sl 0:07 /usr/bin/qemu-system-x86_64 -name guest=ubuntu2004-clone ...2개의 가상 머신 = 2개의 qemu 프로세스
각각 독립된 가상 하드웨어, 메모리, CPU를 갖고 동작
6) IaaS 환경의 오토 스케일 구조와 libvirt
오토 스케일은 어떻게 동작할까?
IaaS(Infra as a Service) 환경에서는 시스템 부하에 따라 가상 머신을 자동으로 늘리거나 줄입니다.
부하 감지 → 스케일링 컨트롤러가 판단
libvirt나 Hypervisor API를 통해 가상 머신 조작
프로그램이 직접 가상 머신 생성을 명령
구조 흐름 요약
[서비스] → 부하 감지 → [오토 스케일 시스템] → libvirt 호출 → 가상 머신 생성이 방식으로 사람의 개입 없이도 자동으로 인프라를 구성할 수 있습니다.
laas 환경에서는 시스템 부하에 따라 시스템에 만들 가상 머신 수를 조절하는
오토 스케일(auto scale)기 능이 있습니다.
IaaS 서비스 제공자나 시스템 관리자가 직접 가상 머신을 조작하는 게 아니라 [그림 10- 16]처럼 시스템 부하에 변화가 생기면 프로그램에서 가상 머신을 높이거나 줄이는 방식으로 동작합니다.
✅ 요약 정리
가상 머신 실행
qemu-system-x86_64 프로세스로 나타남
virsh
가상 머신을 CLI로 조작하는 도구 (libvirt 기반)
XML 설정
가상 머신 하드웨어 및 메모리 설정을 정의
여러 가상 머신
각각 독립적인 qemu 프로세스로 운영됨
오토 스케일링
부하에 따라 자동으로 가상 머신 수 조절 가능 (IaaS 구조)
4. 가상화 환경과 프로세스 스케줄링 완전 정리
1) 가상 머신 위에서의 sched.py 동작
sched.py 동작
실험 시나리오
가상 머신에서
sched.py를 병렬도 2로 실행.각 프로세스는 100ms 동안 CPU를 사용하며, 교대로 실행됨.
실험 결과 요약
두 프로세스가 교대로 동작함.
실제 동작은 가상 머신의
VCPU0에서 돌아가며, 이는 호스트의qemu-system-x86의 스레드로 존재.
적어도 VCPU마다 하나 이상의 스레드가 있다는 점만 이해
동작 흐름 구조
게스트 OS
VCPU0에서 sched.py 실행
호스트 OS
qemu-system-x86 프로세스 내 VCPU0 스레드가 물리 CPU(PCPU0)에서 실행됨
2) inf-loop.py를 함께 돌리면?
inf-loop.py를 함께 돌리면?시나리오
호스트의 PCPU0에서
inf-loop.py를 강제로 실행 (taskset -c 0)동시에 가상 머신 내부에서
sched-virt.py 2실행
전제 구조
가상 머신의 VCPU0은 호스트 OS에서 qemu-system-x86_64 프로세스의 스레드로 실행됩니다.
이 VCPU0 스레드는 물리 CPU인 PCPU0 위에서만 동작하도록 핀 지정되어 있습니다.
그런데 이 PCPU0에서 다른 프로세스(예: inf-loop.py 같은 CPU를 100% 쓰는 프로그램)가 같이 동작하면 어떻게 될까요?
결과 요약
프로세스 0과 1 모두 일정 시간 멈춰 있는 구간이 생김
이는 호스트의
inf-loop.py가 VCPU 스레드를 밀어낸 결과
실행 흐름
PCPUO에서는 VCPUO 스레드 외에는 동작하는 게 없습니다.
3) 가상 머신 vs 물리 머신의 CPU 사용률 관찰 실험 정리
1. 실험 A – VCPU에서만 부하(inf-loop.py) - VCPU만 실행 중인 상태
호스트 PCPU에서는 아무것도 돌고 있지 않음
🖥️ 호스트에서 보는 sar 출력
%user: 100% %steal: 0%→ qemu 프로세스가 물리 CPU를 온전히 점유
🐧 게스트(가상 머신)에서 보는 sar 출력
%user: 거의 100% %steal: 0%→ VCPU가 자기 할당분을 온전히 사용 중
✅ 정상적인 환경 → 게스트가 기대하는 성능대로 잘 돌아가는 상태
2. 실험 B – VCPU와 호스트에서 동시에 부하
실행에 걸린 시간이 [그림 10- 17]에 비해 두 배 정도로 늘어난 점과 프로세스 0과 프로세스 1 어느 쪽도 진척이 없는 시간이 있다는 걸 그래프에서 확인할 수 있습니다
[그림 10-20]에서 프로세스 0과 프로세스 1 어느 쪽도 진척이 없는 시간은 호스트 OS의 loop.py 프로그램이 동작했다는 뜻
호스트 PCPU0에서
inf-loop.py실행 → VCPU와 CPU 자원 경쟁 발생🖥️ 호스트에서 보는 top
qemu-system-x86: 50% CPU inf-loop.py : 50% CPU🐧 게스트(가상 머신)에서 보는 sar 출력
%user: 50% %steal: 50%🟡
%steal은 "원래 내가 CPU를 쓰고 싶었지만, 다른 녀석이 써서 못 쓴 시간" → 게스트는 성능 저하를 경험하고 있음🐧 게스트에서 top 출력
inf-loop.py: 83% CPU 사용 (왜곡됨)→ top은 %steal을 고려하지 않아서, 실제보다 더 많이 사용한 것처럼 나옴
핵심 개념 정리
🔹 %steal이란?
VCPU가 실제 물리 CPU를 사용하고 싶었지만, 다른 프로세스에 의해 빼앗긴 시간의 비율
단지 CPU가 놀고 있는 시간이 아님!
sar로 측정 가능 (sar -P 0 1)
🔹 게스트 vs 호스트 관찰 차이
CPU 사용률
qemu 프로세스로 표현됨
게스트 내 프로세스 기준으로 표현됨
steal 값
의미 없음
VCPU의 사용 실패 비율을 %steal로 표현
top 결과
정확한 프로세스별 CPU 사용률
%steal 고려하지 않음 → 과장될 수 있음
시각적 흐름 요약
[PCPU0] ┌────────────┬────────────┬────────────┐
│ VCPU0 │ Host inf │ VCPU0 │ ...
└────────────┴────────────┴────────────┘
[게스트] ┌────────────┬──── ┬────────────┐
│ 사용 │ steal │ 사용 │
└────────────┴────────────┴────────────┘VCPU가 멈춘 시간은 게스트에서
%steal로 나타남CPU 성능 저하의 원인을 찾기 위해서는 물리 머신과 가상 머신 모두에서 관측이 필요
가상 머신에서 %steal은 성능 저하의 중요한 지표입니다. 게스트가 CPU를 원했지만 호스트에서 다른 작업이 돌아서 기다린 시간을 나타냅니다. 이를 통해 "가상 머신의 성능 저하 원인이 자원 부족 때문인가?"를 진단할 수 있습니다.
4) %steal 필드란? 발생하는 현상: VCPU가 밀려난다 → %steal 증가
%steal 증가%user
게스트가 CPU를 직접 사용한 시간
%steal
가상 머신(VCPU)이 사용하지 못하고 대기한 시간 (호스트에서 다른 프로세스가 CPU를 사용 중인 시간)
✅ steal 값이 높으면 호스트가 너무 바쁘거나 다른 VM이 경쟁 중이라는 뜻입니다.
동작 흐름
T0
VCPU0 스레드
T1
호스트의 inf-loop.py
T2
다시 VCPU0 스레드
T3
inf-loop.py
위처럼 PCPU0 자원을 두 개가 경쟁하게 되면, VCPU0은 어떤 시간 동안 CPU를 사용하지 못하게 됨 → 이 시간은 게스트 입장에선 도둑맞은 시간 = steal time
5) 실험용 도구 요약
sched-virt.py
sched-virt.py사용자가 엔터를 눌러 부하 시작 타이밍을 제어할 수 있음
CPU 자원 소모 시각화 그래프 자동 생성
plot_sched_virt.py
plot_sched_virt.pymatplotlib 기반 결과 시각화
6) 이게 의미하는 성능 영향
게스트 OS는 CPU가 느려졌다고 판단
top에서는 여전히99%로 나와 보이지만, 실제 시간 단위로 보면 밀려난 시간만큼 일 처리가 늦어짐
게스트 성능 저하
sched.py,build,DB 쿼리,웹 서버 응답 지연등 실제 성능이 떨어진다.
게스트 sar에서
%steal증가시스템이 과부하 상태이거나, 다른 가상 머신이 같은 PCPU에서 돌고 있을 때도 같은 현상 발생
✅ 전체 요약
PCPU0에서 VCPU0 스레드 이외의 처리가 동작하면, VCPU0이 밀리게 되고 이는 게스트 OS에서
%steal로 보이며 성능 저하가 발생합니다.
VCPU와 PCPU 관계
VCPU는 qemu 프로세스의 스레드이며, PCPU에서 실행됨
%steal의 의미
VCPU가 실행되지 못한 시간 비율
성능 측정 팁
sar, top 모두 호스트와 게스트 양쪽에서 확인해야 정확함
성능 차이 원인
호스트의 다른 프로세스(예: inf-loop.py)가 VCPU 실행을 방해 가능
따라서 성능을 보장해야 하는 VM에서는 다음과 같은 설정이 필요합니다:
VCPU당 전용PCPU를 할당 (pinning)하거나가상 머신의 동시 실행 수를 PCPU 수 이하로 제한
sar에서
%steal을 지속적으로 모니터링
5. 가상 머신의 저장 장치와 성능
1) 가상 머신 저장 장치의 기본 구조
저장 장치 구성
가상 머신의 저장 장치
게스트 OS에서는 /dev/sda, /dev/vda 등으로 보임
실제 물리 저장 장치
호스트 OS의 파일로 연결됨 (예: ubuntu2004.qcow2)
설정 방법
libvirt XML 파일에 <disk> 항목으로 정의됨
설명 파일명
/var/lib/libvirt/images/ubunty2004.qcom2가 가상 디스크를 저장하는 파일명이며, 이런 파일을 디스크 이미지라고 부른다.
예시: XML 설정
$ virsh dumpxml ubntu2004
(중략)
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/ubunty2004.qcom2'/>
</disk>2) 저장 장치의 동작 흐름
물리 기기의 저장소 입출력 흐름
위의 그림은 단순한 설명을 위해 페이지 캐시 존재를 무시하고, 데이터는 동기화 쓰기를 하는 상황을 가정한다.
ㄱ
저장 장치 쓰기 흐름 요약
가상 머신의 애플리케이션이 파일에 씀
게스트 OS의 파일 시스템과 디바이스 드라이버가 처리
QEMU가 가상 저장 장치를 에뮬레이션
호스트 OS의 파일 시스템이 디스크 이미지 파일을 처리
최종적으로 물리 저장 장치에 기록됨
→ 여러 단계의 중간 경로를 거치므로, 처리 속도가 느려질 수 있음
3) 성능 비교 실험
호스트 OS
약 1100 MiB/s
게스트 OS
약 350 MiB/s
→ 게스트 OS는 약 30% 수준의 속도만 나오는 결과
4) 저장소 I/O 성능 저하 원인
물리 기기에 비해서 저장소 입출력 성능이 나빠지는 건 아닐까? 성능은 대폭 떨어짐
성능 비교법
dd if=/dev/zeroof=/mnt/<테스트용 파일명>bs=1G count=1 oflag=direct, sync페이지 캐시를 사용하지 않고 동기적으로 1GiB 파일을 만들어서 스루풋 성능을 측정합니다.
실행하기 전에 호스트 OS, 게스트 OS 모두 루트 권한으로 echo 3> /proc/sys/vm/drop_
caches를 실행합니다.
호스트 OS, 게스트 OS 모두 루트 권한으로 echo 3> /proc/sys/vm/drop_
caches를 실행하는 이유는 뭘까?
echo 3 > /proc/sys/vm/drop_caches명령어는 리눅스에서 페이지 캐시, 디렉터리 엔트리 캐시(dentry), inode 캐시 등 모든 캐시를 비우는 명령어입니다.
이 명령을 호스트 OS와 게스트 OS 모두에서 실행하는 이유는 다음과 같습니다:
🔍 이유: 정확한 저장소 I/O 성능 측정
1) 캐시가 성능에 영향을 주기 때문입니다.
파일을 읽거나 쓰면 한 번 읽은 데이터는 메모리에 남습니다 → 이것이 페이지 캐시입니다.
두 번째부터는 디스크가 아니라 캐시에서 읽기 때문에 훨씬 빨라집니다.
2) 실험 목적은 디스크 성능 측정입니다.
dd명령어 같은 입출력 벤치마크는 디스크 자체의 속도를 확인하기 위해 사용됩니다.만약 캐시가 켜져 있다면 실제 디스크가 아닌 메모리 속도를 측정하게 됩니다 → 결과가 왜곡됩니다.
3) 가상 머신에서는 호스트의 캐시도 영향 미칩니다.
게스트 OS가 파일을 쓰면 호스트 OS의 페이지 캐시에 저장됩니다.
그래서 게스트에서 캐시를 비워도, 호스트에 캐시가 남아 있다면 성능이 과장되어 측정될 수 있습니다.
요약 정리
게스트 OS
게스트 내부 캐시를 비워서 게스트의 I/O 성능을 정확히 측정
호스트 OS
호스트의 캐시도 I/O에 영향을 주기 때문에 게스트 성능 측정에 간섭 방지
보충 팁
echo 3 > /proc/sys/vm/drop_caches는 캐시를 비우는 명령어지만, 안전한 작업입니다. 시스템이 동작 중인 프로세스나 커널에는 영향 없습니다.다만, 파일 시스템 버퍼를 버리는 것이므로 성능 저하가 있을 수 있고, 자주 사용하지 않는 것이 좋습니다.
주요 원인
단계가 많음: 애플리케이션 → 게스트 커널 → QEMU → 호스트 커널 → 물리 디스크
입출력 캐시 옵션:
writeback: 비동기, 빠르지만 데이터 유실 위험writethrough: 동기, 느리지만 안정성 높음
디스크 이미지가 호스트 파일 시스템 위에 존재: → 디스크 이미지 파일도 다른 파일들과 자원을 공유하므로 I/O 성능에 영향 받음
그래서 성능 향상을 위한 기술이 바로 KVM에는 반가상화 기술을 사용해서 입출력 속도를 향상시키는 기능이 있습니다.
가상 머신에서의 저장소 쓰기 처리 – 캐시 옵션에 따른 차이
가상 머신에서 파일을 쓸 때, 실제 물리 저장 장치에 언제, 어떤 방식으로 기록되는지는 libvirt의 설정에 따라 달라집니다.
이때 사용되는 설정이 바로:
1) 입출력 캐시 옵션 (I/O cache option)
libvirt XML 설정 파일에서 <driver> 태그에 있는 cache 속성을 말합니다.
예시:
<driver name='qemu' type='qcow2' cache='writeback'/>🔧 주요 입출력 캐시 옵션 비교
writeback
- 기본값. - 페이지 캐시를 사용하고, 비동기 쓰기를 합니다. - 가상 머신 내에서 동기화(write sync)를 요청하더라도, 호스트 OS에서는 아직 기록되지 않을 수 있음. - 성능은 좋지만, 정전 시 데이터 손실 위험이 있습니다.
writethrough
- 페이지 캐시는 사용하지만, 쓰기는 동기화해서 진행됩니다. - 가상 머신이 동기화 요청하면 즉시 호스트 저장 장치까지 기록됩니다. - 안정성은 높지만 성능은 떨어질 수 있습니다.
none
- 페이지 캐시를 사용하지 않고 직접 입출력을 합니다. - O_DIRECT 방식으로 작동하여, 가장 낮은 캐시 간섭을 보장합니다. - 데이터 무결성을 제어하기 좋고, DB처럼 캐시를 자체적으로 관리하는 서비스에 적합합니다.
💡 정리
writeback 옵션은 속도는 빠르지만,
가상 머신에서 write()와 sync()를 해도
실제 디스크에 즉시 기록되는 게 아니라 호스트의 페이지 캐시에 남아 있을 수 있음
이 때문에 데이터 정합성이나 장애 대응이 중요한 시스템에서는
writethrough 혹은 none 옵션이 더 적절합니다.
✅ 실제로 어떤 설정이 적절한가?
일반적인 데스크탑 가상 머신
writeback (속도 중시)
DB 서버, NAS 등 중요 데이터
writethrough 또는 none (신뢰성 중시)
자체적으로 캐시 관리하는 애플리케이션
none
5) 성능 향상 기술 – 반가상화 (Para-Virtualization)
반가상화란?
게스트 OS의 저장소 입출력이 느려지는 문제를 극복하기 위해서 반가상화 기술을 사용
하드웨어를 완전히 에뮬레이션하지 않고, 호스트와 게스트가 직접 통신하는 방식
가상화 소프트웨어와 가 상 머신이 특별한 인터페이스로 접속해서 성능을 개선하는 기술
게스트가 더 빠르게 저장 장치나 네트워크를 사용할 수 있도록 도와줌
이 기술을 사용하는 저장 장치를 반가상화 장치, 그런 디바이스 드라이버를 반가상화 드라이버라고 부릅니다.
수많은 반가상화 드라이버가 있지만 책에서는 virtio동작 구조를 따르는 virtio-blk 드라이버 를 설명합니다
물리 기기의 저장 장치와 완전 가상화 장치는 보통 /dev/sd<x>가 파일명이지만, virtio-blk
장치는 /dev/vd<x>가 됩니다.
대표 기술: virtio-blk
virtio-blk일반 장치
/dev/sda
전통적인 SCSI 방식
virtio 장치
/dev/vda
반가상화 기반 빠른 장치
6) 왜 가상 머신에서 읽기 속도가 더 빠르게 나올까?
1) 실험 조건 정리
처리 1)
dd명령어로 1GiB 파일을 직접 입출력 방식(oflag=direct, sync)으로 생성
처리 2)
방금 만든 1GiB 파일을 한 번에 읽어들이는 작업
2) 처리 결과 비교 - 실험: 물리 vs 가상 머신 (읽기 성능)
물리 기기
1.1 GB/s
약 1.1 GB/s
가상 머신
358 MB/s
922 MB/s ← 더 빠름!
분석: 왜 읽기는 가상 머신이 더 빠를까?
✅ 이유는 바로 writeback 캐시 옵션 때문입니다.
writeback 옵션을 사용하면, → 게스트 OS가 저장 장치에 데이터를 쓰더라도 → 실제 물리 저장 장치까지 쓰지 않고 → 호스트 OS의 페이지 캐시에만 남기고 끝납니다.
🔁 처리 1 이후 상태:
파일이 디스크에 쓰이지 않고 호스트 OS의 메모리(페이지 캐시)에만 저장됨
✅ 처리 2를 수행하면?
물리 디스크에 접근하지 않고, → 이미 메모리에 남아 있는 데이터를 읽음 → 결과적으로 읽기 속도는 매우 빠르게 측정됨 → 물리 기기에서는 디스크에서 직접 읽어야 하므로 상대적으로 느림
💡 왜 echo 3 > /proc/sys/vm/drop_caches를 실행했는가? - 위의 해결 방법
echo 3 > /proc/sys/vm/drop_caches를 실행했는가? - 위의 해결 방법이 명령은 호스트 OS나 게스트 OS의 페이지 캐시를 강제로 삭제합니다.
echo 3 > /proc/sys/vm/drop_caches→ 실험 전 캐시를 초기화해 성능 측정을 정확히 할 수 있도록 함
➤ 그 이유는?
처리 2에서 페이지 캐시의 영향을 없애기 위해서입니다.
실험 조건을 공정하게 만들고,
물리 디스크에서 진짜 데이터를 읽는 성능만을 측정하기 위함입니다.
✅ 결론 정리
왜 성능 역전이 일어나는가?
writeback 옵션 덕분에 가상 머신은 캐시에서 데이터를 읽기 때문에 더 빠름
진짜 디스크 성능을 측정하려면?
echo 3 > /proc/sys/vm/drop_caches 명령으로 캐시 제거 후 측정
캐시 옵션 중요성
I/O 성능 실험 시 캐시 설정 여부가 성능에 절대적 영향을 줌
7) 입출력 캐시 옵션 요약
writeback
비동기
사용함
빠르지만 비안정적
writethrough
동기
사용함
느리지만 안전
none
비동기
사용 안함
직접 I/O, 고신뢰
directsync
동기
사용 안함
신뢰성과 성능 절충
6. 가상 머신 저장 장치의 성능 향상 방식 요약
1) 완전 가상화 장치 (Full Virtualized Device)
동작 방식:
게스트 OS는 실제 물리 장치가 아닌 에뮬레이션된 디바이스에 접근
접근마다 VMX 모드 전환 발생:
VMX-nonroot → VMX-root → VMX-nonroot
각 쓰기 동작마다 세 번 이상 장치에 접근 필요:
쓰기할 데이터 위치 전달
디바이스 위치 지정
실제 쓰기 실행
단점:
CPU 모드 전환이 빈번함
입출력 속도가 느림
2) virtio-blk: 반가상화 장치 (Paravirtualized Device)
동작 방식:
게스트 OS와 호스트 OS가 virtio 드라이버를 통해 협력
명령을 큐(queue)에 여러 개 한꺼번에 삽입 가능
VMX 모드 전환을 한 번만 수행해 다수의 작업 처리 가능
장점:
효율적인 I/O 명령어 처리
CPU 오버헤드 감소
완전 가상화보다 2배 가까이 성능 향상 가능
실측 결과 (표 10-05):
호스트 OS
1100
게스트 OS (완전 가상화)
350
게스트 OS (virtio-blk)
663
3) PCI 패스스루 (PCI Passthrough)
동작 방식:
게스트 OS에 실제 물리 장치를 직접 할당
가상 장치가 아니라 진짜 장치를 직접 조작
장점:
거의 호스트와 동일한 입출력 성능
가상화 계층을 거치지 않음
단점:
하드웨어와 설정 제약 많음
특정 PCI 장치만 지원됨 (GPU, NIC 등)
VM 간 공유 불가, 고정 할당
4) 핵심 요약 비교
완전 가상화
많음
느림
처리 단순, 모드 전환 잦음
virtio-blk
1회 (일괄 처리)
보통~좋음
큐에 명령어 다중 삽입 가능
PCI 패스스루
없음
매우 빠름
진짜 하드웨어 직접 사용
Last updated