하이퍼바이저: Type 1 vs Type 2

가상화의 중재자, 하이퍼바이저

가상화가 필요하다는 건 알겠는데, "하드웨어 하나를 어떻게 여러 OS가 나눠 쓰지?"라는 의문이 생긴다. 내 로컬 맥북에서 VirtualBox로 우분투를 돌리면 맥OS와 우분투가 동시에 실행되는데, 둘 다 CPU를 써야 하고 메모리도 써야 한다. 누가 이걸 조율하는 걸까?

처음 VirtualBox를 설치했을 때 VM에 CPU 코어를 몇 개 할당할지, 메모리를 얼마나 줄지 설정하는 화면이 나왔다. "아, 이 소프트웨어가 하드웨어 자원을 나눠주는구나." 그런데 회사 서버실에 가보니 서버 한 대에 OS가 아예 없고, 부팅하면 바로 VM 관리 화면이 뜬다. 이건 또 다른 방식인 것 같았다.

하이퍼바이저는 가상 머신(VM)을 생성하고 관리하는 소프트웨어 계층이다. 물리 하드웨어 자원(CPU, 메모리, 디스크, 네트워크)을 여러 VM에게 나눠주고, 각 VM이 독립적인 OS처럼 동작하게 만든다. 중요한 건 하이퍼바이저가 어디에 설치되느냐인데, 이에 따라 Type 1과 Type 2로 나뉜다.

Type 1 하이퍼바이저 - Bare Metal 방식

"하드웨어 바로 위에 올라간다"

Type 1 하이퍼바이저는 하드웨어 위에 직접 설치된다. 일반 OS가 없다. 부팅하면 하이퍼바이저가 뜬다. 마치 하이퍼바이저 자체가 OS처럼 동작한다.

┌─────────────────────────────────────┐
│  VM 1 (Ubuntu)  │  VM 2 (Windows)  │
│  Guest OS       │  Guest OS         │
├─────────────────────────────────────┤
│      Type 1 Hypervisor (ESXi)       │ ← 직접 하드웨어 제어
├─────────────────────────────────────┤
│   Physical Hardware (CPU, RAM)      │
└─────────────────────────────────────┘

대표적인 예가 VMware ESXi, Microsoft Hyper-V(서버용), Xen, KVM(Kernel-based Virtual Machine) 등이다. 클라우드 제공자들(AWS, GCP, Azure)은 대부분 Type 1을 사용한다. AWS EC2는 예전엔 Xen을 썼고, 지금은 Nitro 하이퍼바이저(KVM 기반)를 쓴다.

왜 빠른가?

중간 매개체가 없다. VM에서 디스크를 읽으려면 하이퍼바이저가 바로 하드웨어에 명령을 보낸다. 일반 OS가 거치지 않으므로 오버헤드가 최소화된다.

# KVM 예시 (Ubuntu 서버)
# 1. KVM 설치
sudo apt install qemu-kvm libvirt-daemon-system

# 2. VM 생성
virt-install \
  --name ubuntu-vm \
  --ram 2048 \
  --disk path=/var/lib/libvirt/images/ubuntu-vm.img,size=20 \
  --vcpus 2 \
  --os-type linux \
  --os-variant ubuntu20.04 \
  --network bridge=virbr0 \
  --graphics none \
  --cdrom /path/to/ubuntu.iso

# 3. VM 시작
virsh start ubuntu-vm

# 4. VM 목록 확인
virsh list --all

KVM은 리눅스 커널 자체가 하이퍼바이저 역할을 한다. 커널 모듈(kvm-intel 또는 kvm-amd)을 로드하면 CPU의 하드웨어 가상화 기능(Intel VT-x, AMD-V)을 활용해 VM을 실행한다. Host OS가 있긴 하지만, 커널 레벨에서 직접 가상화를 처리하므로 Type 1에 가깝다. (학술적으론 하이브리드라고도 부른다.)

하드웨어 지원 가상화

Intel VT-x와 AMD-V는 CPU가 하드웨어 레벨에서 가상화를 지원하는 기술이다. 예전엔 하이퍼바이저가 소프트웨어적으로 Guest OS의 특권 명령어(privileged instructions)를 가로채야 했다. 이걸 Binary Translation 방식이라고 하는데, 느렸다. VT-x/AMD-V가 나오면서 CPU가 직접 VM의 명령어를 처리할 수 있게 됐다.

# VT-x/AMD-V 지원 확인 (Linux)
egrep -o '(vmx|svm)' /proc/cpuinfo

# vmx → Intel VT-x
# svm → AMD-V

Full Virtualization vs Para-virtualization

• Full Virtualization: Guest OS가 자신이 가상화되었다는 걸 모른다. 하이퍼바이저가 모든 명령어를 가로채서 처리한다. 하드웨어 지원 가상화(VT-x)가 있으면 빠르다. (예: VMware ESXi, KVM)
• Para-virtualization: Guest OS가 자신이 VM이라는 걸 알고, 하이퍼바이저와 협력한다. Guest OS 커널을 수정해서 하이퍼바이저 API를 직접 호출한다. 오버헤드가 더 적다. (예: Xen PV, 과거 리눅스 배포판)

요즘은 하드웨어 지원 가상화가 보편화되어 Full Virtualization이 대세다.

Live Migration

Type 1의 장점 중 하나가 Live Migration이다. VM을 끄지 않고 다른 물리 서버로 옮길 수 있다. 서버 유지보수를 해야 할 때, VM을 다른 서버로 옮기고 기존 서버를 끈다. 사용자는 서비스 중단을 느끼지 못한다.

# KVM에서 Live Migration (libvirt)
virsh migrate --live ubuntu-vm qemu+ssh://target-host/system

내부적으론 메모리 페이지를 점진적으로 복사하고, 마지막 순간 아주 짧은 시간(수십 ms) 동안만 VM을 멈춰서 나머지 메모리를 동기화한 뒤 대상 서버에서 재개한다.

용도

• 클라우드 서비스 (AWS EC2, Azure VM, GCP Compute Engine)
• 기업 데이터센터 (VMware vSphere, Hyper-V Server)
• 고성능 가상화가 필요한 환경

Type 2 하이퍼바이저 - Hosted 방식

"일반 OS 위에 앱처럼 설치된다"

Type 2는 Host OS(Windows, macOS, Linux) 위에 소프트웨어로 설치된다. VirtualBox, VMware Workstation, Parallels가 여기 속한다. 우리가 "VM 소프트웨어 설치했다"고 할 때 대부분 Type 2다.

┌────────────────────────────────────────┐
│      VM (Ubuntu)                       │
│      Guest OS                          │
├────────────────────────────────────────┤
│  Type 2 Hypervisor (VirtualBox)        │ ← 애플리케이션 계층
├────────────────────────────────────────┤
│  Host OS (macOS)                       │ ← 이 OS가 하드웨어 제어
├────────────────────────────────────────┤
│  Physical Hardware (CPU, RAM)          │
└────────────────────────────────────────┘

VM이 디스크를 읽으려면:

1. Guest OS가 하이퍼바이저에 요청
2. 하이퍼바이저가 Host OS에 요청
3. Host OS가 하드웨어에 명령

경로가 길다. 오버헤드가 크다.

# VirtualBox 예시 (macOS/Linux/Windows)
# 1. VM 생성
VBoxManage createvm --name "Ubuntu-VM" --ostype "Ubuntu_64" --register

# 2. 메모리와 CPU 할당
VBoxManage modifyvm "Ubuntu-VM" --memory 2048 --cpus 2

# 3. 가상 디스크 생성
VBoxManage createhd --filename ~/VirtualBox\ VMs/Ubuntu-VM/Ubuntu-VM.vdi --size 20480

# 4. 디스크 연결
VBoxManage storagectl "Ubuntu-VM" --name "SATA Controller" --add sata --controller IntelAhci
VBoxManage storageattach "Ubuntu-VM" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium ~/VirtualBox\ VMs/Ubuntu-VM/Ubuntu-VM.vdi

# 5. ISO 연결
VBoxManage storageattach "Ubuntu-VM" --storagectl "SATA Controller" --port 1 --device 0 --type dvddrive --medium ~/ubuntu-20.04.iso

# 6. VM 시작
VBoxManage startvm "Ubuntu-VM" --type headless

# 7. VM 목록 확인
VBoxManage list vms

VirtualBox는 CLI(VBoxManage)와 GUI를 모두 제공한다. 개발자는 CLI로 VM을 자동화할 수 있다(예: Vagrant가 VirtualBox CLI를 사용).

장점 - 접근성

일반인도 쓸 수 있다. 맥에서 VirtualBox 설치 파일(.dmg) 다운로드하고 더블클릭하면 끝이다. VM에 리눅스를 깔아서 웹 서버를 띄우고, Host macOS에선 브라우저로 접속해본다. 개발 환경 실험에 최적이다.

단점 - 성능

Host OS가 자원을 먼저 쓴다. 내 맥북 RAM이 16GB인데, macOS가 8GB를 쓰고 있으면 VM에 줄 수 있는 건 최대 8GB다. 실제론 덜 준다. VM에서 무거운 작업을 하면 Host OS까지 느려진다.

Snapshot

Type 2의 강력한 기능이 Snapshot이다. VM의 상태를 저장해두고, 나중에 그 시점으로 되돌릴 수 있다. "이 실험 하다가 망가뜨리면 어쩌지?" → 스냅샷 찍어놓고 시도한다.

# VirtualBox 스냅샷
VBoxManage snapshot "Ubuntu-VM" take "before-experiment" --description "Clean state"

# 나중에 복원
VBoxManage snapshot "Ubuntu-VM" restore "before-experiment"

Type 1도 스냅샷을 지원하지만, Type 2가 개인 실험용으로 더 직관적이다.

Nested Virtualization

VM 안에서 또 VM을 돌리는 걸 Nested Virtualization이라고 한다. 예를 들어, VirtualBox(Type 2) 안에서 KVM(Type 1)을 돌려서 VM을 만드는 것. 성능은 끔찍하지만, 교육이나 테스트 목적으론 유용하다.

# VirtualBox에서 Nested Virtualization 활성화
VBoxManage modifyvm "Ubuntu-VM" --nested-hw-virt on

클라우드에서도 Nested Virtualization을 지원한다. AWS의 *.metal 인스턴스나 Azure의 Dv3/Ev3 시리즈에서 가능하다.

용도

• 개인 학습 (다양한 OS 실험)
• 개발/테스트 환경 (로컬에서 리눅스 서버 실행)
• 데모 및 교육

하이퍼바이저 vs 컨테이너 런타임

Docker를 쓰다 보면 "이것도 가상화 아닌가?"라는 생각이 든다. 비슷해 보이지만 다르다.

하이퍼바이저 (VM)
┌────────────┬────────────┐
│ VM 1       │ VM 2       │
│ Full OS    │ Full OS    │ ← 각각 커널 포함
├────────────┴────────────┤
│ Hypervisor              │
├─────────────────────────┤
│ Host OS / Hardware      │
└─────────────────────────┘

컨테이너 런타임 (Docker)
┌────────────┬────────────┐
│ Container 1│ Container 2│
│ App + Libs │ App + Libs │ ← 커널 공유
├────────────┴────────────┤
│ Container Runtime       │
├─────────────────────────┤
│ Host OS (Linux Kernel)  │
└─────────────────────────┘

• 하이퍼바이저: 각 VM이 독립된 OS 커널을 갖는다. 격리 수준이 높다. 무겁다.
• 컨테이너: Host OS 커널을 공유한다. 가볍다. 시작 속도가 빠르다. 격리는 네임스페이스/cgroup으로 한다.

클라우드에선 VM과 컨테이너를 함께 쓴다. VM으로 인프라를 격리하고, VM 안에서 Docker 컨테이너를 실행한다.

vCPU와 vRAM

하이퍼바이저는 물리 자원을 가상 자원으로 변환한다.

• vCPU (Virtual CPU): 물리 CPU 코어를 논리적으로 쪼개서 VM에 할당. 물리 코어 8개짜리 서버에 VM 4개를 만들고 각각 vCPU 4개씩 줄 수 있다. (총 16 vCPU, 오버커밋)
• vRAM: 물리 메모리를 VM에 할당. 64GB 서버에 VM 4개를 만들고 각각 16GB씩 주면 꽉 찬다.

# KVM에서 vCPU/vRAM 할당
virt-install \
  --name test-vm \
  --ram 4096 \        # vRAM 4GB
  --vcpus 2 \          # vCPU 2개
  --disk size=10 \
  --os-variant ubuntu20.04

오버커밋(Over-commit)은 물리 자원보다 많은 가상 자원을 할당하는 것. 예를 들어 물리 CPU 코어 4개에 vCPU를 총 8개 할당. 모든 VM이 동시에 100% CPU를 쓰지 않는다는 가정 하에 작동한다. 클라우드 제공자들은 이걸 활용해서 비용을 절감한다.

---

7.5. 새로운 흐름: MicroVM (Firecracker)

최근에는 Type 1과 Type 2, 그리고 컨테이너의 장점을 합친 MicroVM이 뜨고 있습니다. 대표적인 예가 AWS의 Firecracker입니다.

• 배경: AWS Lambda(Serverless)를 운영하려니, 기존 VM은 너무 무겁고(부팅 느림), 컨테이너는 보안이 불안했습니다(커널 공유).
• 해결: 필요한 기능만 남긴 초경량 KVM 기반 VM을 만들었습니다.
• 성능: 부팅 시간 125ms 미만. 메모리 오버헤드 5MB 미만.

이제 "VM은 무겁다"는 편견도 깨지고 있습니다. 기술은 계속 돌고 돕니다.

7.9. 보안 제대로 파보기 - Type 2가 위험한 이유

보안 관점에서 Type 1이 Type 2보다 훨씬 안전합니다.

• Type 2 (Hosted): 해커가 Host OS(Windows 등)를 뚫으면, 그 위에 떠 있는 모든 VM도 위험해집니다. 공격 표면(Attack Surface)이 Host OS 전체입니다.
• Type 1 (Bare Metal): 하이퍼바이저 코드가 매우 작습니다(수십 MB 수준). 코드가 작을수록 버그도 적고, 해킹당할 구멍도 적습니다.

그래서 기업 환경에서는 절대 Type 2를 메인 서버로 쓰지 않는 것입니다.

---

---

메모리 가상화의 마법 (Shadow Page Table vs EPT) 한 걸음 더

CPU 가상화보다 더 복잡한 게 메모리 가상화입니다. 게스트 OS는 자기가 물리 메모리(0번지~)를 독점한다고 착각하지만, 실제로는 호스트 메모리의 일부일 뿐입니다.

1. 초기 방식 (Shadow Page Tables): 하이퍼바이저가 게스트의 페이지 테이블을 몰래 섀도우(Shadow)로 복사해서, 실제 물리 주소와 매핑합니다. 게스트가 페이지 테이블을 건드릴 때마다 하이퍼바이저가 개입해야 해서 오버헤드가 큽니다.
2. 하드웨어 지원 (Intel EPT / AMD RVI): CPU가 2차원 페이징을 지원합니다. "게스트 가상 주소 -> 게스트 물리 주소 -> 호스트 물리 주소" 변환을 하드웨어가 직접 처리합니다. 이 기술 덕분에 가상화 성능이 비약적으로 향상되었습니다.

5.8. 가상화의 미래: Unikernel

도커가 OS를 공유해서 가볍다면, Unikernel은 아예 OS를 라이브러리처럼 애플리케이션에 링크해버립니다. 불필요한 커널 기능을 싹 걷어내고, 내 앱에 필요한 기능(예: 네트워크 스택)만 넣어서 컴파일합니다. 부팅 시간이 밀리초 단위고, 보안성도 뛰어납니다. 아직은 실험적이지만 클라우드 네이티브의 끝판왕이 될 수도 있습니다.

---

마치며

하이퍼바이저를 이해하니 클라우드의 작동 원리가 보인다. AWS에서 EC2 인스턴스를 띄우면, 사실 Nitro 하이퍼바이저가 물리 서버 하나에서 내 VM을 만들어주는 것이다. 내가 t3.medium을 선택하면 vCPU 2개, vRAM 4GB를 할당받는다. 이 서버엔 내 VM 말고도 수십 개의 다른 VM이 돌고 있을 것이다.

로컬에선 Type 2를 쓴다. VirtualBox에 우분투 VM을 만들어서 쿠버네티스 클러스터를 실험해본다. 망가뜨려도 스냅샷으로 복구하면 된다. 이 환경에서 충분히 테스트한 뒤, 실제 서비스는 클라우드의 Type 1 환경(EC2)에 배포한다.

Type 1은 속도와 효율을 위해, Type 2는 편의성과 실험을 위해 존재한다. 둘 다 "하드웨어 자원을 여러 OS가 나눠 쓰게 한다"는 목표는 같지만, 설치 위치와 성능 트레이드오프가 다르다. 이제 "하이퍼바이저가 뭐야?"라는 질문엔 "어디에 설치되냐에 따라 다르다"고 답할 수 있다.

---

The Hypervisor Decision

I was setting up a local development environment. I needed to test a Linux server configuration before deploying it to production. Someone suggested VirtualBox. I installed it, created an Ubuntu VM, allocated 2 CPU cores and 4GB RAM, and it worked. But it was slow. Opening a terminal in the VM had noticeable lag.

Then I visited a data center. A server had no operating system. I pressed the power button, and instead of Windows or Linux, a VM management interface appeared. I could create VMs directly from there. No host OS. The technician said, "This is ESXi. We run 30 VMs on this one server. It's fast." Same concept—virtualization—but completely different architecture.

That's when I realized: hypervisors come in two types, and the difference matters.

What Is a Hypervisor?

A hypervisor is software that creates and manages virtual machines. It takes physical hardware resources (CPU, memory, disk, network) and divides them among multiple VMs, allowing each VM to run its own operating system independently. The critical distinction is where the hypervisor is installed, which determines whether it's Type 1 or Type 2.

Type 1: Bare Metal Hypervisor

Type 1 runs directly on hardware. No host OS. You boot the machine, and the hypervisor starts. The hypervisor itself acts as the operating system.

┌─────────────────────────────────────┐
│  VM 1 (Ubuntu)  │  VM 2 (Windows)  │
│  Guest OS       │  Guest OS         │
├─────────────────────────────────────┤
│      Type 1 Hypervisor (ESXi)       │ ← Controls hardware directly
├─────────────────────────────────────┤
│   Physical Hardware (CPU, RAM)      │
└─────────────────────────────────────┘

Examples: VMware ESXi, Microsoft Hyper-V (Server), Xen, KVM (Kernel-based Virtual Machine). Cloud providers use Type 1. AWS EC2 used Xen, now uses Nitro Hypervisor (KVM-based). Google Cloud uses KVM. Azure uses Hyper-V.

Why Is It Fast?

No middleman. When a VM needs to read from disk, the hypervisor sends the command directly to hardware. No host OS in between. Minimal overhead.

# KVM Example (Ubuntu Server)
# 1. Install KVM
sudo apt install qemu-kvm libvirt-daemon-system

# 2. Create VM
virt-install \
  --name ubuntu-vm \
  --ram 2048 \
  --disk path=/var/lib/libvirt/images/ubuntu-vm.img,size=20 \
  --vcpus 2 \
  --os-type linux \
  --os-variant ubuntu20.04 \
  --network bridge=virbr0 \
  --graphics none \
  --cdrom /path/to/ubuntu.iso

# 3. Start VM
virsh start ubuntu-vm

# 4. List VMs
virsh list --all

KVM is interesting. It's a Linux kernel module. Load kvm-intel or kvm-amd, and the kernel itself becomes the hypervisor. It uses CPU hardware virtualization (Intel VT-x or AMD-V) to run VMs. Technically, Linux is the host OS, but since virtualization happens at the kernel level, it's classified as Type 1 (or hybrid).

Hardware-Assisted Virtualization

Intel VT-x and AMD-V are CPU features that enable hardware-level virtualization. Before these, hypervisors had to intercept privileged instructions using software techniques (Binary Translation). It was slow. With VT-x/AMD-V, the CPU handles VM instructions directly.

# Check VT-x/AMD-V support (Linux)
egrep -o '(vmx|svm)' /proc/cpuinfo

# vmx → Intel VT-x
# svm → AMD-V

If you don't see vmx or svm, your CPU doesn't support hardware virtualization, or it's disabled in BIOS.

Full Virtualization vs Para-virtualization

• Full Virtualization: The guest OS doesn't know it's virtualized. The hypervisor intercepts all instructions. With hardware support (VT-x), this is fast. (e.g., VMware ESXi, KVM)
• Para-virtualization: The guest OS knows it's a VM and cooperates with the hypervisor. The guest OS kernel is modified to call hypervisor APIs directly. Lower overhead. (e.g., Xen PV, older Linux distros)

Nowadays, with widespread hardware virtualization support, full virtualization is standard.

Live Migration

One advantage of Type 1 is live migration. You can move a running VM from one physical server to another without shutting it down. During server maintenance, you migrate all VMs to another server, then power down the original. Users experience no downtime.

# KVM Live Migration (libvirt)
virsh migrate --live ubuntu-vm qemu+ssh://target-host/system

Internally, the hypervisor copies memory pages incrementally, then pauses the VM for a very brief moment (tens of milliseconds) to synchronize the remaining memory, and resumes on the target server.

Use Cases

• Cloud services (AWS EC2, Azure VM, GCP Compute Engine)
• Enterprise data centers (VMware vSphere, Hyper-V Server)
• High-performance virtualization environments

Type 2: Hosted Hypervisor

Type 2 is installed as software on top of a host OS (Windows, macOS, Linux). VirtualBox, VMware Workstation, Parallels Desktop are Type 2. When we say "I installed VM software," it's usually Type 2.

┌────────────────────────────────────────┐
│      VM (Ubuntu)                       │
│      Guest OS                          │
├────────────────────────────────────────┤
│  Type 2 Hypervisor (VirtualBox)        │ ← Application layer
├────────────────────────────────────────┤
│  Host OS (macOS)                       │ ← Controls hardware
├────────────────────────────────────────┤
│  Physical Hardware (CPU, RAM)          │
└────────────────────────────────────────┘

When a VM wants to read from disk:

1. Guest OS requests the hypervisor
2. Hypervisor requests the host OS
3. Host OS sends command to hardware

Longer path. Higher overhead.

# VirtualBox Example (macOS/Linux/Windows)
# 1. Create VM
VBoxManage createvm --name "Ubuntu-VM" --ostype "Ubuntu_64" --register

# 2. Allocate memory and CPU
VBoxManage modifyvm "Ubuntu-VM" --memory 2048 --cpus 2

# 3. Create virtual disk
VBoxManage createhd --filename ~/VirtualBox\ VMs/Ubuntu-VM/Ubuntu-VM.vdi --size 20480

# 4. Attach disk
VBoxManage storagectl "Ubuntu-VM" --name "SATA Controller" --add sata --controller IntelAhci
VBoxManage storageattach "Ubuntu-VM" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium ~/VirtualBox\ VMs/Ubuntu-VM/Ubuntu-VM.vdi

# 5. Attach ISO
VBoxManage storageattach "Ubuntu-VM" --storagectl "SATA Controller" --port 1 --device 0 --type dvddrive --medium ~/ubuntu-20.04.iso

# 6. Start VM
VBoxManage startvm "Ubuntu-VM" --type headless

# 7. List VMs
VBoxManage list vms

VirtualBox provides both CLI (VBoxManage) and GUI. Developers can automate VMs using CLI (Vagrant uses VirtualBox CLI).

Advantage: Accessibility

Anyone can use it. Download VirtualBox installer, double-click, done. Install Linux in a VM, run a web server, access it from the host OS browser. Perfect for experimentation.

Disadvantage: Performance

The host OS consumes resources first. If my MacBook has 16GB RAM and macOS is using 8GB, the VM can only get up to 8GB. Usually less. Running heavy tasks in the VM slows down the host OS too.

Snapshots

A powerful Type 2 feature is snapshots. You can save the VM's state and restore it later. "What if this experiment breaks the VM?" → Take a snapshot, then experiment.

# VirtualBox snapshot
VBoxManage snapshot "Ubuntu-VM" take "before-experiment" --description "Clean state"

# Restore later
VBoxManage snapshot "Ubuntu-VM" restore "before-experiment"

Type 1 also supports snapshots, but Type 2 makes it more intuitive for personal use.

Nested Virtualization

Running a VM inside a VM is called nested virtualization. For example, running KVM (Type 1) inside VirtualBox (Type 2) to create VMs. Performance is terrible, but it's useful for education or testing.

# Enable nested virtualization in VirtualBox
VBoxManage modifyvm "Ubuntu-VM" --nested-hw-virt on

Cloud providers also support nested virtualization. AWS *.metal instances and Azure Dv3/Ev3 series allow it.

Use Cases

• Personal learning (experimenting with different OSes)
• Development/testing environments (running a local Linux server)
• Demos and education

Hypervisor vs Container Runtime

When using Docker, I wondered, "Isn't this also virtualization?" They look similar but are different.

Hypervisor (VM)
┌────────────┬────────────┐
│ VM 1       │ VM 2       │
│ Full OS    │ Full OS    │ ← Each includes kernel
├────────────┴────────────┤
│ Hypervisor              │
├─────────────────────────┤
│ Host OS / Hardware      │
└─────────────────────────┘

Container Runtime (Docker)
┌────────────┬────────────┐
│ Container 1│ Container 2│
│ App + Libs │ App + Libs │ ← Share kernel
├────────────┴────────────┤
│ Container Runtime       │
├─────────────────────────┤
│ Host OS (Linux Kernel)  │
└─────────────────────────┘

• Hypervisor: Each VM has an independent OS kernel. High isolation. Heavy.
• Container: Shares the host OS kernel. Lightweight. Fast startup. Isolation via namespaces/cgroups.

In the cloud, VMs and containers are used together. VMs isolate infrastructure, and Docker containers run inside VMs.

vCPU and vRAM

Hypervisors convert physical resources into virtual resources.

• vCPU (Virtual CPU): Logical slices of physical CPU cores allocated to VMs. An 8-core server can have 4 VMs with 4 vCPUs each (16 vCPUs total, over-committed).
• vRAM: Physical memory allocated to VMs. A 64GB server with 4 VMs, each getting 16GB, uses all memory.

# KVM vCPU/vRAM allocation
virt-install \
  --name test-vm \
  --ram 4096 \        # 4GB vRAM
  --vcpus 2 \          # 2 vCPUs
  --disk size=10 \
  --os-variant ubuntu20.04

Over-commit means allocating more virtual resources than physical resources. For example, 4 physical cores but 8 vCPUs total. This works because not all VMs use 100% CPU simultaneously. Cloud providers use over-commit to reduce costs.

---

7.5. The New Wave: MicroVM (Firecracker)

Recently, MicroVMs have emerged, combining the best of Type 1, Type 2, and Containers. The most famous example is AWS Firecracker.

• Context: AWS needed to run Lambda (Serverless). Traditional VMs were too slow to boot, and Containers were not secure enough (shared kernel).
• Solution: Build an ultra-lightweight KVM-based VM with only essential features.
• Performance: Boot time under 125ms. Memory overhead under 5MB.

The stereotype that "VMs are heavy" is shattered. Technology cycles continue.

7.9. Security Deep Dive: Why Type 2 is Risky

From a security perspective, Type 1 is vastly superior to Type 2.

• Type 2 (Hosted): If a hacker compromises the Host OS (e.g., Windows), all VMs running on it are at risk. The Attack Surface is the entire Host OS.
• Type 1 (Bare Metal): The hypervisor code is tiny (tens of MBs). Smaller code means fewer bugs and fewer holes to exploit.

This is why enterprises never use Type 2 for critical production work.

---

---

6.5. Deep Dive: Magic of Memory Virtualization (EPT/RVI)

Virtualizing the CPU is hard, but virtualizing Memory is a nightmare. Guest OS thinks it owns physical memory starting from address 0, but it actually lives in a slice of Host memory.

1. The Old Way (Shadow Page Tables): The hypervisor maintained a "Shadow Page Table" that mapped Guest Virtual Addresses directly to Host Physical Addresses. It had to trap every time the Guest OS modified its page table. Slow and complex.
2. The Hardware Way (Intel EPT / AMD RVI): Modern CPUs support Second Level Address Translation (SLAT). The hardware handles the nested translation: "Guest Virtual -> Guest Physical -> Host Physical". This removed the massive overhead of software memory virtualization.

6.8. Future of Virtualization: Unikernels

If Docker creates a lightweight userspace, Unikernels strip down the Kernel itself. You compile your application with a minimal kernel library customized for just that app. No unused drivers, no multi-user support, no shell. Just your code and the bare metal essentials. It boots in milliseconds and has a tiny attack surface. It's still niche, but it represents the ultimate optimization of cloud workloads.