Virtualization and Hypervisors (가상화와 하이퍼바이저)

"한 대의 물리 머신에서 여러 운영체제를 동시에 돌리려면, 게스트 OS의 특권 명령과 메모리 접근을 누가 어떻게 가로채야 하는가?" 이 페이지는 그 질문에 답한다. 가상화는 컴퓨터 자원을 논리적으로 추상화해, 사용자나 응용 프로그램이 실제 하드웨어·OS의 세부를 모르게 하는 기술이다.^[1] 이 페이지는 무엇을 가상화하는지(프로세스 VM과 시스템 VM), 누가 관리하는지(하이퍼바이저), 특권 명령과 메모리 주소를 어떻게 처리하는지(CPU·메모리 가상화), 그리고 커널을 공유하는 컨테이너가 어디에 놓이는지를 차례로 다룬다. 메모리 주소 변환의 기본은 Operating System Memory Management를 전제로 한다.

왜 가상화하나

하이퍼바이저(소프트웨어)가 하나의 물리 머신에서 가상 머신(VM)을 만든다. VM은 물리 머신의 컴퓨팅 자원을 쓰면서 물리 머신과 같은 역할을 하고, 하이퍼바이저가 필요에 따라 각 VM에 자원을 할당한다.^[2]
원문은 대부분의 서버가 용량의 10~15%만 쓰며, 서버 가상화로 효용률이 "70% up" 된다고 적는다. 효용률이 높아지면 같은 처리량에 필요한 컴퓨터 수가 줄어든다.^[2:1] "70% up"이 증가 폭인지 도달 수치인지는 원문에 없다.
클라우드 서비스에서의 장단점은 다음과 같다.^[1:1]

장점	단점
적은 하드웨어 구매로 비용 절감	가상화 소프트웨어·지원 하드웨어의 초기 투자 비용
쉬운 백업과 재해 복구	소프트웨어 라이선스 비용
중단 없는 비즈니스, 효율적인 IT 운영	초기 교육 필요

어느 층을 가상화하나: 프로세스 VM과 시스템 VM

가상화는 ABI 수준이나 ISA 수준에서 적용할 수 있다.^[1:2]
- ABI 수준 (프로세스 VM): 사용자 응용 관점의 가상화다. 예: JVM.
- ISA 수준 (시스템 VM): 하드웨어 명령어 수준의 가상화다. 게스트 OS가 하이퍼바이저 위에서 동작한다.
프로세스 VM은 게스트와 호스트의 ISA가 같은지에 따라 다시 나뉜다.^[1:3]

유형	설명	ISA	예시
Multiprogrammed System	단일 프로세스가 CPU·메모리·디스크 전체를 독점하는 것처럼 보이게 한다	동일	-
Same ISA Binary Optimizer	게스트와 호스트의 ISA가 같을 때 최적화해 실행한다	동일	Dynamo
Emulator	다른 ISA를 변환한다. 인터프리터는 명령어를 하나씩 해석해 시작 오버헤드가 없지만 느리고, 바이너리 트랜슬레이터는 블록 단위로 변환해 시작 오버헤드가 있지만 빠르다	다름	QEMU
High-Level Language VM	언어 독립 실행 환경으로, 하드웨어와 OS 의존을 최소화한다	다름	JVM, CLR

하이퍼바이저

하이퍼바이저는 가상화 소프트웨어이며 가상 머신 모니터(VMM)라고도 한다. 하이퍼바이저가 설치되는 물리 시스템이 호스트 머신, 하이퍼바이저가 관리하는 VM이 게스트 머신이다.^[1:4]
타입은 물리 시스템에 직접 설치되는지로 나뉜다.^[1:5]

구분	Type 1 (bare metal, native)	Type 2 (hosted)
설치 위치	물리 하드웨어에 직접 설치, 물리 시스템의 OS 역할	호스트 OS 위에 애플리케이션처럼 설치
특징	대규모 클라우드용, 확장·축소가 빠른 확장성, VM과 호스트 간 빠른 통신, 하드웨어 가상화 지원 활용	단일 물리 시스템에서 설치·운영이 편리
한계	-	하드웨어 직접 접근이 어렵고 Type 1보다 오버헤드가 크다
예시	KVM, Xen, Hyper-V	-

KVM은 리눅스 커널 모듈로 동작한다. 리눅스가 설치된 뒤 동작하므로 Type 2에 가깝지만, KVM 모듈이 올라간 리눅스 자체를 Type 1 하이퍼바이저로 볼 수도 있다.^[1:6]
Xen은 케임브리지 대학 연구 프로젝트에서 반가상화 하이퍼바이저로 시작했고, 이후 하드웨어 지원 전가상화도 지원한다. 장치에 접근할 수 있는 특권 도메인(Dom 0)과 일반 VM인 게스트 도메인(Dom U)을 나누며, CPU·메모리·인터럽트는 직접 처리하고 장치 처리는 Dom 0이 하이퍼콜로 맡는다.^[1:7]

가상화 방식: 전가상화, 반가상화, 하이브리드, OS 레벨

방식	특징	장점	단점
전가상화 (Full)	게스트 OS를 수정하지 않아 가상화 환경임을 모른다. 하드웨어 관련 명령을 하이퍼바이저가 가로채 처리한다. SW 기반과 HW 지원 기반으로 나뉜다	기존 OS를 그대로 쓴다	트랩과 에뮬레이션에 따른 성능 저하
반가상화 (Para)	게스트 OS가 하이퍼콜로 하이퍼바이저와 직접 통신한다	성능 향상	OS 수정 필요
하이브리드	HW 지원 전가상화에 반가상화 드라이버를 더한다	성능과 호환성 절충	구현이 복잡
OS 레벨 (컨테이너)	여러 컨테이너가 커널 하나를 공유한다	가볍고 빠르다	이기종 OS 불가

위 표는 원문 표를 옮긴 것이다.^[1:8] 원문의 분류 그림(그림 10.18)은 다음과 같이 재구성할 수 있다.^[1:9]

flowchart TB
    V[가상화] --> OS[운영체제 가상화: 컨테이너]
    V --> FV[에뮬레이션 / 전가상화: 게스트 OS 수정 없음]
    V --> PV[반가상화: 게스트 OS 수정]
    V --> HY[하이브리드 반가상화: 하드웨어 지원 + 게스트 OS 수정]
    FV --> HW[하드웨어 지원 가상화: VT-x, AMD-V]
    FV --> SW[소프트웨어 지원 가상화: 바이너리 트랜슬레이션, QEMU]
    HW --> T1[네이티브·베어메탈: 하이퍼바이저 타입 1]
    HW --> T2a[호스티드: 하이퍼바이저 타입 2]
    SW --> T2b[호스티드]

CPU 가상화: 특권 명령을 누가 처리하나

x86은 Ring 0(커널)부터 Ring 3(사용자)까지 특권 레벨을 둔다. 하이퍼바이저는 게스트 OS보다 높은 특권이 필요하므로, 게스트 OS는 Ring 0에서 돌기를 기대하지만 실제로는 그보다 낮게 내려간다.^[1:10]
문제는 일부 명령이 트랩을 일으키지 않는다는 점이다. 예를 들어 POPF로 인터럽트 플래그를 바꿔도 트랩이 나지 않으면, 하이퍼바이저는 상태 변화를 알아채지 못하고 결과를 예측할 수 없게 된다.^[1:11]
이 문제를 푸는 방식은 네 가지다. 원문 그림 10.13~10.15의 특권 배치를 같은 표에 정리했다.^[1:12]

기법	처리 방식	게스트 OS 위치	대표 기술
에뮬레이션	ISA를 변환한다. 느리다	-	QEMU
바이너리 트랜슬레이션 (SW 전가상화)	트랩이 안 걸리는 명령을 안전한 명령으로 바꾸고, 특권 명령은 트랩으로 하이퍼바이저에 넘긴다	Ring 1 (VMM이 Ring 0)	VMware
하이퍼콜 (반가상화)	수정된 게스트 OS가 하이퍼바이저에 직접 요청한다	수정된 커널	Xen
HW 지원 가상화	VT-x·AMD-V로 root/non-root 모드를 나누고, 민감한 요청이 오면 VMM으로 트랩한다	non-root 모드의 Ring 0 (VMM은 root 모드)	KVM 등

특권 명령 실행을 일으키는 이벤트는 세 가지다.^[1:13]

이벤트	발생 위치	예
트랩	사용자 프로그램	`printf()` → write 시스템 콜 → 사용자 모드에서 커널 모드로 전환
인터럽트	하드웨어, 비동기	USB 연결, NIC 패킷 수신, 키보드 입력
익셉션	CPU	divide by zero. 복구 가능한 폴트와 불가능한 어보트로 나뉜다

반가상화가 나온 배경은 바이너리 트랜슬레이션의 비용이다. VMware가 개발한 바이너리 트랜슬레이션은 하이퍼바이저가 명령을 CPU가 알아듣는 형태로 바꿔야 해서 오버헤드가 크고 구현이 까다로웠고, Xen이 OS를 수정해 하이퍼콜을 쓰는 방식을 제안했다.^[1:14]
반가상화가 HW 기반 전가상화보다 유리한 예는 타이머다. 전가상화에서는 하이퍼바이저가 주기적으로 타이머 인터럽트를 만들어 줘야 해서 오버헤드와 불안정성이 생기지만, 반가상화에서는 게스트 OS의 유휴 코드에 "일정 시간 뒤 타이머 인터럽트를 달라"는 요청을 넣으면 된다.^[1:15]
반가상화의 단점은 가상 CPU 처리다. CPUID처럼 사용자 공간에서도 쓰는 명령은 가상화 여부와 관계없이 같은 결과를 내야 하는데, 물리 CPU와 가상 CPU의 처리 방식이 다르면 문제가 생긴다.^[1:16]
원문의 결론은 하드웨어 지원 가상화를 기본으로 쓰고, I/O·메모리 집약 작업에는 반가상화 디바이스 드라이버를 쓰는 조합이다.^[1:17]

VT-x 생명주기와 VMCS

flowchart LR
    ON[VMXON: VMX 명령 실행 단계 진입] --> VMM[VMM, root 모드]
    VMM -->|VM Entry: VMLAUNCH / VMRESUME| G[게스트 VM, non-root 모드]
    G -->|VM Exit: 예외·인터럽트·I/O| VMM
    VMM --> OFF[VMXOFF: VMM 종료]

VMM은 root 모드에서, VM은 non-root 모드에서 실행되며, 두 모드 사이 전환이 자주 일어난다. VMM은 한 번에 하나의 VM을 실행하고, VM Exit로 제어를 돌려받은 뒤 VM Entry로 다시 실행한다.^[1:18] 위 흐름은 원문 그림 10.9(VMM Software Life Cycle)를 재구성한 것이다.
Intel에서는 /proc/cpuinfo의 vmx 플래그로, AMD에서는 svm 플래그로 하드웨어 가상화 지원을 확인한다.^[1:19]
VMCS(Virtual Machine Control Structure)는 VM마다 메모리에 하나씩 있으며, 문맥 전환 때 상태를 저장한다. 여섯 개의 논리 그룹으로 이루어진다.^[1:20]

영역	역할
Guest State Area	VM Exit·Entry 때 프로세서 상태를 저장한다
Host State Area	VM Exit 때 로드할 프로세서 상태
VM Execution Control Fields	non-root 모드에서 실행되는 명령을 제어한다
VM Exit Control Fields	VM Exit을 제어한다
VM Entry Control Fields	VM Entry를 제어한다
VM Exit Information Fields	VM Exit 원인 정보를 저장한다

메모리 가상화

CPU는 가상 주소를 쓰고 MMU가 이를 물리 주소로 바꾼다. 가상화 환경에서는 여기에 한 단계가 더 붙는다.^[1:21]

Guest Virtual Address (GVA) → Guest Physical Address (GPA) → Host Physical Address (HPA)

방식	설명	장점	단점
TLB 에뮬레이션	하이퍼바이저가 TLB를 직접 에뮬레이션	간단	TLB miss 등 성능 저하
Shadow Page Table	VMM이 게스트와 별도로 page table을 관리	호환성이 높다	유지 비용이 크다
Direct PT Access (반가상화)	게스트가 머신 주소를 직접 쓴다	성능이 높다	OS 수정 필요
HW 지원 (Nested Page Table)	Intel EPT, AMD NPT로 2단계 주소 변환	고성능, OS 수정 불필요	주소 변환에 메모리 접근이 여러 번 필요

원문은 Nested Page Table의 메모리 접근이 "최대 5번" 필요할 수 있다고 적는다.^[1:22]^[3] 보완책으로 TLB 캐시, Large Pages(HugeTLB), VM 사이 TLB 공유를 위한 ASID를 든다.^[1:23]

컨테이너: 커널을 공유하는 OS 레벨 가상화

컨테이너는 애플리케이션과 실행 환경(라이브러리, 설정)을 격리된 공간에 묶은 실행 단위다. 호스트 OS의 커널을 공유하고, namespace와 cgroup으로 격리한다.^[1:24]

기술	역할
Namespace	프로세스, 네트워크, 사용자, 파일 시스템 격리
cgroup	CPU, 메모리 등 자원 사용량 제한
UnionFS	계층형 파일 시스템, 이미지와 컨테이너 상태 분리

항목	VM	컨테이너
OS 실행	Guest OS 실행	호스트 OS 커널 공유
부팅 시간	수 분 이상	수 초 내외
자원	무겁고 개별 할당	가볍고 공유
활용 예	다양한 OS 실행	마이크로서비스, DevOps, CI/CD

커널을 공유하므로 오버헤드가 거의 없는 대신 이기종 OS는 돌릴 수 없다.^[1:25]
개발과 운영 환경을 같게 맞춰야 할 때, 빠른 배포·복구가 중요할 때, 마이크로서비스, 수명이 짧고 반복 배포하는 애플리케이션에 적합하다.^[1:26]

테스트 질문

Type 1과 Type 2 하이퍼바이저는 무엇으로 구분하며, KVM은 어느 쪽인가?
POPF 같은 명령이 트랩을 일으키지 않으면 왜 문제가 되고, 이를 해결하는 방식 네 가지는 무엇인가?
컨테이너가 VM보다 빠르게 뜨지만 다른 OS를 돌릴 수 없는 이유는 무엇인가?

출처

가상화/개념정리.md — Chapter 10 "가상화는 컴퓨터 자원의 논리적 추상화이다.", ABI 레벨(JVM)·ISA 레벨 구분, 프로세스 VM 유형 표와 동일/다른 ISA 그룹핑, 하이퍼바이저 용어, Type 1·Type 2 특징, KVM·Xen 설명, 클라우드 장단점, 가상화 타입 4가지 표, "하이퍼바이저는 가상머신에 설치된 OS보다 더 높은 특권레벨 필요", SW 기반 전가상화 동작방식(게스트 OS Ring 1, Ring 0 하이퍼바이저), 트랩·인터럽트·익셉션, 반가상화 등장 배경("바이너리 트랜슬레이션은 VMWare에서 개발", "Xen이 위 단점을 보완하기 위해 OS를 수정한 하이퍼콜 방식을 제안"), HW 기반 전가상화(비루트 모드 Ring 0, 루트 모드 하이퍼바이저), 반가상화 장점(타이머 인터럽트)·단점(CPUID), 하이브리드 가상화와 결론, VT-x 라이프 사이클·VMCS 6개 그룹·vmx/svm flag; Chapter 11 "일부 비트 조작 명령어(예: POPF)는 트랩이 발생하지 않음", CPU 가상화 기법 요약 표, GVA → GPA → HPA, 메모리 가상화 구현 방식 표, "메모리 접근이 최대 5번 필요할 수 있음", 보완 방법(TLB 캐시, Large Pages, ASID); Chapter 14 컨테이너 정의, 구성 기술 표, VM vs 컨테이너 표, 적합한 경우; 그림 10.9, 10.12, 10.13, 10.14, 10.15, 10.18(Raw/media/Knowledge/Computing/의 Pasted image 6개, 2026-10-01 육안 확인) ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
기술/가상화.md — "하이퍼바이저(소프트웨어)를 사용하여 하나의 물리적 머신에서 가상 머신(VM)을 만드는 프로세스", "VM은 물리적 머신과 동일한 역할과 성능 수행", "하이퍼바이저는 필요에 따라 각 VM에 컴퓨팅 리소스 할당", "대부분의 서버 = 용량의 10~15%만 사용", "서버의 효용률 70% up", "높은 효용률 -> 동일한 처리량을 위한 컴퓨터 수를 줄여줌" ↩︎ ↩︎
출처 매핑 미확인 — 원문은 Nested Page Table의 접근 횟수를 "최대 5번"(GVA → GPA → HPA → Memory)으로 적지만, 그 수치가 몇 단계 page table을 전제로 한 것인지는 원문에 없다. 실제 접근 횟수는 게스트·호스트 page table의 단계 수에 따라 달라지므로, 이 수치는 강의 자료의 단순화일 수 있으며 공식 자료로 확인하지 않았다. ↩︎