Virtual Machines: From Hypervisors to Containers

Virtualization technology creates multiple independent execution environments on a single physical machine to increase resource utilization and provide isolation. This article examines everything from traditional hypervisor-based VMs to modern containers.

1. Benefits of Virtual Machines

┌──────────────────────────────────────────┐
│          Key Benefits of VMs             │
│                                          │
│  Isolation:                              │
│  - Complete isolation between VMs        │
│  - One VM failure doesn't affect others  │
│                                          │
│  Consolidation:                          │
│  - Multiple servers on one physical host │
│  - Hardware utilization: 15% → 70%+      │
│                                          │
│  Portability:                            │
│  - VM images can move between hosts      │
│  - Hardware independent                  │
│                                          │
│  Dev/Test:                               │
│  - Run multiple OS environments          │
│  - Quick restore with snapshots          │
│                                          │
│  Security:                               │
│  - Run suspicious software in VMs        │
│  - Discard VM on compromise              │
└──────────────────────────────────────────┘

2. Type 1 Hypervisor (Bare-Metal)

A hypervisor that runs directly on physical hardware.

┌────────────┐ ┌────────────┐ ┌────────────┐
│ Guest OS 1 │ │ Guest OS 2 │ │ Guest OS 3 │
│ (Linux)    │ │ (Windows)  │ │ (FreeBSD)  │
├────────────┤ ├────────────┤ ├────────────┤
│ Virtual HW │ │ Virtual HW │ │ Virtual HW │
└──────┬─────┘ └──────┬─────┘ └──────┬─────┘
       │              │              │
┌──────┴──────────────┴──────────────┴──────┐
│         Type 1 Hypervisor                │
│    (VMware ESXi, Xen, Hyper-V, KVM)     │
├───────────────────────────────────────────┤
│              Physical Hardware            │
│    (CPU, Memory, Disk, NIC)              │
└───────────────────────────────────────────┘

Major Type 1 Hypervisors

Name	Vendor	Features
VMware ESXi	VMware	Enterprise market leader
KVM	Linux kernel	Linux kernel module, open source
Xen	Linux Foundation	Paravirt pioneer, early AWS
Hyper-V	Microsoft	Windows Server integration

3. Type 2 Hypervisor (Hosted)

A hypervisor that runs on top of an existing operating system.

┌────────────┐ ┌────────────┐
│ Guest OS 1 │ │ Guest OS 2 │
│ (Ubuntu)   │ │ (Windows)  │
├────────────┤ ├────────────┤
│ Virtual HW │ │ Virtual HW │
└──────┬─────┘ └──────┬─────┘
       │              │
┌──────┴──────────────┴───────────┐
│    Type 2 Hypervisor             │
│  (VirtualBox, VMware Workstation)│
├─────────────────────────────────┤
│       Host OS (macOS, etc.)     │
├─────────────────────────────────┤
│         Physical Hardware       │
└─────────────────────────────────┘

Type 1 vs Type 2 Comparison

Property	Type 1	Type 2
Runs on	Hardware directly	On host OS
Performance	High (low overhead)	Moderate (via host OS)
Use case	Servers, cloud	Dev/test, desktop
Isolation	High	Moderate
Management	Dedicated tools	Host OS application

4. Hardware-Assisted Virtualization

VT-x (Intel Virtualization Technology)

Provides hardware-level support for virtualization to improve efficiency.

Software virtualization (binary translation):
┌─────────────────────────────────┐
│ Guest OS executes privileged    │
│ instruction                     │
│        ↓                        │
│ Hypervisor traps                │
│        ↓                        │
│ Binary translation/emulation    │
│        ↓                        │
│ Execute translated code         │
│ → High overhead                 │
└─────────────────────────────────┘

Hardware-assisted (VT-x):
┌─────────────────────────────────┐
│ VMX root mode (hypervisor)      │
│ VMX non-root mode (Guest OS)    │
│                                 │
│ Guest OS executes privileged    │
│ instruction                     │
│        ↓                        │
│ VM Exit → switch to hypervisor  │
│        ↓                        │
│ Hypervisor handles              │
│        ↓                        │
│ VM Entry → return to Guest OS   │
│ → Hardware handles switch, fast │
└─────────────────────────────────┘

Memory Virtualization - EPT (Extended Page Tables)

Software (Shadow Page Tables):
Guest virtual → Guest physical (Guest page table)
Guest physical → Host physical (Hypervisor managed)
→ Two translations needed, hypervisor maintains shadow table

Hardware (EPT / AMD NPT):
Guest virtual → Guest physical → Host physical
                                  ↑ CPU auto-translates
→ Hardware handles directly without hypervisor intervention

5. Paravirtualization

Modifies the guest OS kernel to communicate directly with the hypervisor.

Full virtualization:              Paravirtualization:
Guest OS (unmodified)             Guest OS (modified)
    │                               │
    ├→ Execute privileged instr.    ├→ Hypercall invocation
    │                               │   (similar to syscall)
    ├→ Trap (hardware)              ├→ Direct hypervisor call
    │                               │
    └→ Hypervisor emulation         └→ Hypervisor handles

Paravirt advantage: Faster (no trap overhead)
Paravirt disadvantage: Requires guest OS kernel modification

// Xen 반가상화 하이퍼콜 예시 (의사 코드)
// Guest OS 커널에서 직접 하이퍼바이저 호출

// 기존 (전가상화): 특권 명령어 사용
// cli  (인터럽트 비활성화 - Trap 발생)

// 반가상화: 하이퍼콜 사용
void disable_interrupts_paravirt() {
    // 하이퍼바이저에 직접 요청
    HYPERVISOR_event_channel_op(EVTCHNOP_mask, &mask_params);
}

// 페이지 테이블 업데이트도 하이퍼콜로
void update_page_table_paravirt(pte_t *pte, pte_t new_val) {
    // 직접 메모리 쓰기 대신 하이퍼콜
    HYPERVISOR_mmu_update(&mmu_update, 1, NULL, DOMID_SELF);
}

6. Containers

Containers are OS-level virtualization that isolates processes while sharing the kernel.

VM vs Container

VM:                              Container:
┌──────┐ ┌──────┐ ┌──────┐     ┌──────┐ ┌──────┐ ┌──────┐
│App A │ │App B │ │App C │     │App A │ │App B │ │App C │
├──────┤ ├──────┤ ├──────┤     ├──────┤ ├──────┤ ├──────┤
│Bins/ │ │Bins/ │ │Bins/ │     │Bins/ │ │Bins/ │ │Bins/ │
│Libs  │ │Libs  │ │Libs  │     │Libs  │ │Libs  │ │Libs  │
├──────┤ ├──────┤ ├──────┤     └──┬───┘ └──┬───┘ └──┬───┘
│GuestOS│ │GuestOS│ │GuestOS│        │       │       │
└──┬───┘ └──┬───┘ └──┬───┘   ┌──────┴───────┴───────┴──────┐
   │        │        │       │       Container Runtime      │
┌──┴────────┴────────┴──┐    │       (Docker Engine)        │
│     Hypervisor        │    ├──────────────────────────────┤
├───────────────────────┤    │         Host OS              │
│     Host OS           │    │      (shared kernel)        │
├───────────────────────┤    ├──────────────────────────────┤
│     Physical HW       │    │       Physical HW            │
└───────────────────────┘    └──────────────────────────────┘

VM: Full OS included (GB)        Container: App + libs only (MB)
Boot: Minutes                    Start: Seconds

Docker Basic Usage

# Docker 이미지 빌드
# Dockerfile 예시
# FROM ubuntu:22.04
# RUN apt-get update && apt-get install -y nginx
# COPY index.html /var/www/html/
# EXPOSE 80
# CMD ["nginx", "-g", "daemon off;"]

# 이미지 빌드
docker build -t my-nginx .

# 컨테이너 실행
docker run -d -p 8080:80 --name web my-nginx

# 실행 중인 컨테이너 확인
docker ps

# 컨테이너 로그 확인
docker logs web

# 컨테이너 중지 및 삭제
docker stop web
docker rm web

Container Isolation Technologies (Linux)

┌──────────────────────────────────────────────┐
│       Linux Container Isolation              │
│                                              │
│  Namespaces (Isolation):                     │
│  ┌────────────┬───────────────────────────┐  │
│  │ PID        │ Process ID isolation      │  │
│  │ NET        │ Network stack isolation   │  │
│  │ MNT        │ Filesystem mount isolat.  │  │
│  │ UTS        │ Hostname isolation        │  │
│  │ IPC        │ IPC resource isolation    │  │
│  │ USER       │ User/group ID isolation   │  │
│  │ CGROUP     │ Cgroup view isolation     │  │
│  └────────────┴───────────────────────────┘  │
│                                              │
│  Control Groups (cgroups - Resource Limits): │
│  ┌────────────┬───────────────────────────┐  │
│  │ CPU        │ CPU usage limits          │  │
│  │ Memory     │ Memory usage limits       │  │
│  │ I/O        │ Disk I/O bandwidth limits │  │
│  │ Network    │ Network bandwidth limits  │  │
│  └────────────┴───────────────────────────┘  │
└──────────────────────────────────────────────┘

// 네임스페이스를 이용한 프로세스 격리 (의사 코드)
#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define STACK_SIZE (1024 * 1024)

int child_func(void *arg) {
    // 새로운 PID 네임스페이스에서 실행
    // 이 프로세스는 PID 1로 보임
    printf("Child PID (in namespace): %d\n", getpid());

    // 새로운 호스트이름 설정
    sethostname("container", 9);

    // 프로그램 실행
    execl("/bin/bash", "bash", NULL);
    return 0;
}

int main() {
    char *stack = malloc(STACK_SIZE);

    // 새로운 네임스페이스에서 자식 프로세스 생성
    int flags = CLONE_NEWPID   // PID 네임스페이스
              | CLONE_NEWUTS   // 호스트이름 네임스페이스
              | CLONE_NEWNS;   // 마운트 네임스페이스

    pid_t pid = clone(child_func, stack + STACK_SIZE, flags, NULL);
    printf("Child PID (in parent): %d\n", pid);

    waitpid(pid, NULL, 0);
    free(stack);
    return 0;
}

Kubernetes Overview

A container orchestration platform that automates large-scale container deployment and management.

┌──────────────────────────────────────────────────┐
│              Kubernetes Cluster                   │
│                                                  │
│  Control Plane (Master):                         │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐         │
│  │ API      │ │ Scheduler│ │ Controller│         │
│  │ Server   │ │          │ │ Manager  │         │
│  └──────────┘ └──────────┘ └──────────┘         │
│  ┌──────────┐                                    │
│  │ etcd     │ ← Cluster state store             │
│  └──────────┘                                    │
│                                                  │
│  Worker Nodes:                                   │
│  ┌─────────────────┐  ┌─────────────────┐        │
│  │ Node 1          │  │ Node 2          │        │
│  │ ┌─────┐ ┌─────┐│  │ ┌─────┐ ┌─────┐│        │
│  │ │Pod A│ │Pod B││  │ │Pod C│ │Pod D││        │
│  │ └─────┘ └─────┘│  │ └─────┘ └─────┘│        │
│  │ kubelet  kube-  │  │ kubelet  kube-  │        │
│  │          proxy  │  │          proxy  │        │
│  └─────────────────┘  └─────────────────┘        │
└──────────────────────────────────────────────────┘

7. Application Containment

Multi-Layer Isolation for Enhanced Security

┌─────────────────────────────────────┐
│     Isolation Level Comparison       │
│                                     │
│  VM:          Strong isolation      │
│  │            (hypervisor boundary) │
│  │                                  │
│  gVisor:      Medium isolation      │
│  │            (user-space kernel)   │
│  │                                  │
│  Container:   Basic isolation       │
│  │            (namespaces/cgroups)  │
│  │                                  │
│  Process:     Minimal isolation     │
│              (shared kernel)        │
└─────────────────────────────────────┘

8. VM Migration

Technology for moving a running VM to another physical host.

Live Migration Process

Source Host                        Destination Host
┌──────────────┐                ┌──────────────┐
│ VM (running) │                │              │
│              │                │              │
│ 1. Memory    │                │              │
│    page xfer │───────────────→│ Receive      │
│              │                │              │
│ 2. Dirty page│                │              │
│    iterative │───────────────→│ Receive      │
│              │                │              │
│ 3. VM pause  │                │              │
│    send rest │───────────────→│ Receive      │
│              │                │              │
│ 4. VM stop   │                │ 5. VM resume │
│              │                │              │
└──────────────┘                └──────────────┘
Downtime: tens to hundreds of ms (near zero downtime)

9. Unikernels

Lightweight VMs that compile an application and only the needed OS functionality into a single address space image.

Regular VM:                 Unikernel:
┌───────────┐              ┌───────────┐
│ App       │              │ App       │
├───────────┤              │ + needed  │
│ Libraries │              │   OS funcs│
├───────────┤              │ (single   │
│ Full OS   │              │  binary)  │
│ (kernel + │              └─────┬─────┘
│  utils)   │                    │
└─────┬─────┘              Hypervisor
  Hypervisor

Size: GB                   Size: MB
Boot: Seconds              Boot: Milliseconds
Attack surface: Wide       Attack surface: Very narrow

10. Summary

Type 1 Hypervisor: Runs directly on hardware, suited for server/cloud environments
Type 2 Hypervisor: Runs on host OS, suited for development/testing
Hardware Virtualization: VT-x, EPT minimize overhead
Paravirtualization: Modified guest OS for efficient hypervisor communication
Containers: Lightweight isolation, fast startup, Docker/Kubernetes ecosystem
VM Migration: Live migration for near-zero downtime moves
Unikernels: Extremely lightweight special-purpose VMs

Quiz: Virtual Machines

Q1. What is the difference between Type 1 and Type 2 hypervisors?

A1. Type 1 runs directly on physical hardware (bare-metal) with low overhead and excellent performance. Type 2 runs as an application on an existing OS, making it easy to install but with additional overhead from going through the host OS.

Q2. Why are containers lighter than VMs?

A2. VMs include a complete guest OS each, while containers share the host kernel and only package the application and libraries. Container images are therefore lightweight at the MB level, and startup times are fast at the seconds level.

Q3. How is downtime minimized in live migration?

A3. In the pre-copy approach, memory pages are transferred while the VM is running, and dirty (changed) pages are sent repeatedly. When the change rate drops sufficiently, the VM is briefly paused, the remaining pages are sent, and the VM resumes on the destination. This reduces downtime to tens of milliseconds.