VM은 어떻게 하나의 물리 서버 안에서 또 하나의 컴퓨터로 동작할까?
물리 서버 하나에 여러 개의 가상 머신(VM)을 띄워 사용하는 것은 현대 인프라의 기본입니다. 그렇다면 VM은 어떻게 물리 자원을 공유하면서도 자신만의 독립된 CPU, RAM, Disk를 가지고 있다고 믿게 만드는 것일까요? 가상화(Virtualization)의 작동 원리와 핵심 메커니즘을 정리합니다.
1. VM의 본질: 소프트웨어로 추상화된 컴퓨터
VM은 거창한 하드웨어가 아니라 실제 컴퓨터의 주요 장치들을 소프트웨어로 추상화한 모델입니다. Guest OS 입장에서는 독자적인 하드웨어를 소유한 것처럼 보이지만, 실제로는 가상화 레이어가 물리 자원을 분할 및 매핑하여 전달합니다.
Physical Server (16 Core CPU, 64GB RAM, 1TB Disk)
│
▼
Hypervisor
┌─────┼─────┐
▼ ▼ ▼
VM 1 VM 2 VM 3 (각 4 vCPU, 16GB RAM)
Guest OS가 인식하는 vCPU, Guest Memory, Virtual Disk(/dev/vda), Virtual NIC(eth0)는 모두 하드웨어 인터페이스를 흉내 낸 Virtual Device에 불과합니다.
2. CPU 가상화의 난제: Privilege Level과 Ring 0의 충돌
x86 CPU는 보안과 자원 보호를 위해 4단계의 권한 수준(Privilege Level, Ring 0~3)을 가집니다.
- Ring 0 (Kernel Mode): 가장 높은 권한. 하드웨어 직접 제어 가능.
- Ring 3 (User Mode): 가장 낮은 권한. 일반 애플리케이션 실행.
[ 전통적인 구조 ]
Application (Ring 3) ──System Call──> Linux Kernel (Ring 0) ──> Hardware
문제 발생: VM 내부의 Guest Kernel도 자신이 시스템의 주 주인이라고 생각해 Ring 0에서 실행되기를 원합니다. 그러나 물리 CPU의 Ring 0은 이미 Host Kernel이 점유하고 있습니다.
- 과거의 해결책 (Trap-and-Emulate): Guest의 특권 명령(Privileged Instruction) 시도를 CPU Trap으로 잡아 Hypervisor가 대신 처리했습니다. 그러나 모든 명령을 중계하느라 심각한 성능 저하가 발생했습니다.
- 현대의 해결책 (하드웨어 지원 가상화): CPU 제조사가 가상화를 전폭 지원하기 시작했습니다. Intel은 VT-x (VMX Root / Non-root Mode), AMD는 SVM 기술을 통해 Host와 Guest의 실행 환경을 CPU 하드웨어 차원에서 완전 격리했습니다.
3. Hypervisor의 역할과 분류
하이퍼바이저는 물리 하드웨어와 Guest OS 사이에서 가상 환경을 제공하고 자원을 조율하는 핵심 소프트웨어입니다.
| 구분 | Type 1 (Bare-metal) | Type 2 (Hosted) | KVM (Kernel-based VM) |
| 구조 | 하드웨어 위에 직접 구동 | Host OS의 애플리케이션으로 구동 | Linux 커널 자체를 Hypervisor로 전환 |
| 특징 | 오버헤드가 적고 성능이 뛰어남 | 설치가 쉽고 데스크톱 환경에 적합 | 리눅스 커널 모듈을 통해 Type 1급 성능 제공 |
| 대표 예시 | VMware ESXi, Xen, Hyper-V | VirtualBox, VMware Workstation | Linux KVM + QEMU |
4. 메모리, 디스크, 네트워크의 가상화
- 메모리 가상화 (2단계 주소 변환): Guest OS는 자신만의 연속된 메모리 공간(Guest Physical Address)이 있다고 생각합니다. 하이퍼바이저는 이를 실제 물리 메모리(Host Physical Address)로 변환해야 하며, 이 과정은 Intel EPT / AMD NPT 하드웨어 기술을 통해 고속 처리됩니다.
- 디스크 가상화: Guest의 /dev/vda 블록 요청을 QEMU와 virtio-blk 드라이버가 수신하여 Host의 실제 저장소 파일(qcow2, raw)이나 NVMe 장치로 매핑합니다.
- 네트워크 가상화: Guest 내부의 eth0 패킷은 virtio-net ➔ TAP 디바이스 ➔ Linux Bridge를 거쳐 물리 NIC로 전달됩니다.
5. 모든 것은 KubeVirt로 연결된다
가상화의 기본 원리는 현대 클라우드 네이티브 기술인 KubeVirt로 그대로 이어진다.
Kubernetes API ──> KubeVirt ──> virt-launcher Pod ──> QEMU / KVM ──> Physical Hardware
KubeVirt는 하드웨어 가상화 메커니즘(KVM/QEMU)을 쿠버네티스의 API와 선언형 컨테이너 오케스트레이션 모델 안으로 통합한 기술입니다.
오늘 꼭 기억해야 할 핵심 5가지
- 소프트웨어 추상화: VM은 실제 하드웨어를 복제한 소프트웨어 모델이다.
- 하이퍼바이저: Guest OS에게 하드웨어 인터페이스를 모방하여 제공한다.
- CPU 특권 문제 해결: Guest Kernel의 특권 명령 처리를 위해 하드웨어 지원 가상화(Intel VT-x / AMD-V)가 필수적이다.
- 이중 주소 변환: 메모리는 Guest 주소에서 Host 물리 주소로의 2단계 변환(EPT/NPT)을 거친다.
- 인터페이스 매핑: Disk와 NIC는 virtio 및 TAP/Bridge 기술을 통해 Host의 실제 자원과 연결된다.
'Virtualization' 카테고리의 다른 글
| 학습 목차 (0) | 2026.08.19 |
|---|
