Episode ini membedah arsitektur Cloud Hypervisor: VMM Rust single-binary di atas backend KVM/MSHV, device virtio (net, block, pmem, fs, vsock, rng), dan offload vhost-user. Kalian juga memahami peran komponen pendukung seperti rust-hypervisor-firmware, edk2 UEFI (CLOUDHV.fd), serta alur proses VM dari kernel guest hingga device model.

Setelah memahami sejarah dan motivasi di balik Cloud Hypervisor di episode 1, sekarang kita bedah bagaimana ia bekerja dari dalam. Arsitektur menentukan segalanya: kenapa boot begitu cepat, kenapa binary-nya kecil, dan kenapa device bisa di-hotplug. Di episode 2 kita menelusuri anatomi VMM ini — dari proses yang berjalan di host sampai ring buffer yang menghubungkannya dengan guest.
Bayangkan Cloud Hypervisor seperti pengatur lalu lintas bandara: ia tidak menerbangkan pesawat (itu tugas guest OS di dalam VM), tetapi ia mengatur jalur masuk-keluar (vCPU), gerbang kargo (virtio-block), runway jaringan (virtio-net), dan menara kontrol (vCPU scheduler KVM). Semua koordinasi ini terjadi lewat satu proses tunggal di host.
Cloud Hypervisor adalah VMM single-binary: seluruh VMM — vCPU loop, device model, dan manajemen memory — hidup dalam satu proses Rust. Keuntungannya: mudah di-deploy (satu file), footprint memori kecil, dan lebih mudah di-sandbox (kita bahas landlock di episode 12). Tidak seperti QEMU yang memanggil banyak helper, Cloud Hypervisor menangani semuanya sendiri.
Struktur dasarnya kurang lebih:
cloud-hypervisor (proses host)
├── vCPU threads → dikelola KVM, menjalankan ring guest
├── device model → virtio devices + MMIO/PIO trap handler
├── memory manager → guest RAM, hugepages, shared memory
└── control plane → menerima perintah (hotplug, snapshot, dll.)Proses ini tidak mengeksekusi instruksi guest secara langsung. Ia meminta kernel KVM untuk menciptakan vCPU dan VM via ioctl (dari crate kvm-ioctls). KVM bertindak sebagai accelerator: guest code berjalan langsung di CPU (ring 1 VMX/SVM), dan begitu ada peristiwa yang harus ditangani VMM (port I/O, MMIO, hypercall), CPU melakukan VM-exit dan kontrol kembali ke proses VMM.
cat /proc/misc | grep kvm
lsmod | grep kvmSelain KVM, Cloud Hypervisor mendukung backend Microsoft Hypervisor (MSHV) untuk platform Windows/Hyper-V. Namun di series ini kita fokus pada KVM, backend utama untuk Linux. Untuk aarch64, Cloud Hypervisor memakai KVM di host Arm yang mendukung virtualization, dan dukungan riscv64 sedang dalam tahap eksperimental.
Alih-alih mengemulasi perangkat fisik, Cloud Hypervisor menyajikan virtio devices. Konsepnya: guest dan host berbagi virtqueue (ring buffer) di shared memory. Guest memproduksi permintaan (misal "tulis blok ini ke disk"), host mengkonsumsinya, lalu membalas. Karena tidak ada emulasi hardware fisik, overhead jauh lebih rendah.
Perangkat yang didukung mencakup:
virtiofsd).cloud-hypervisor \
--disk path=ubuntu.raw \
--net tap=ch0,ip=192.168.100.1 \
--rng--rng menyajikan virtio-rng sehingga guest tidak kehabisan entropy — masalah yang sering membuat aplikasi kriptografi menggantung di VM tanpa sumber random yang baik.
Untuk performa lebih tinggi, Cloud Hypervisor bisa menyerahkan pemrosesan data plane ke daemon eksternal lewat protokol vhost-user. Daemon seperti vhost-user-net atau virtiofsd memegang akses langsung ke device/fd, sementara VMM hanya mengatur kontrol. Ini mengurangi overhead VM-exit karena data plane tidak perlu bolak-balik ke proses VMM. Kita bahas praktiknya di episode 7.
Selain binary utama, ekosistem Cloud Hypervisor punya tiga komponen penting:
rust-hypervisor-firmware (disebut juga hypervisor-fw) adalah firmware minimal berbasis Rust untuk boot Linux guest. Ia melakukan setup awal (GDT, page tables) lalu langsung melompat ke kernel — jauh lebih cepat daripada firmware penuh. Cocok untuk direct boot tanpa filesystem boot loader.
Untuk boot OS penuh seperti Ubuntu dengan GRUB, atau Windows, kalian butuh firmware UEFI berbasis edk2 — dalam bentuk file CLOUDHV.fd. Ini varian edk2 yang di-maintain khusus untuk Cloud Hypervisor. Bedanya dengan edk2 upstream akan kita bahas di episode 15, khususnya untuk aarch64.
Semua perangkat yang disajikan ke guest (virtio-net, virtio-blk, dsb.) diimplementasikan di dalam binary sebagai bagian device model. Karena berbasis Rust dan berbagi crate dengan proyek rust-vmm lain (kvm-ioctls, vm-memory, virtio-queue), implementasinya teruji silang dengan Firecracker dan crosvm — detailnya di episode 21.
Tip
Ingat pembagian peran ini: cloud-hypervisor menyediakan VMM dan device model, KVM mengeksekusi guest, firmware (hypervisor-fw atau CLOUDHV.fd) mem-boot guest, dan daemon vhost-user menangani data plane yang di-offload. Seluruh bagian ini bekerja sebagai satu sistem — merusak satu komponen akan terlihat jelas dari gejala VM yang tidak boot atau NIC yang tidak jalan.
Urutan logis saat cloud-hypervisor --kernel vmlinux --disk path=disk.raw dijalankan:
/dev/kvm.Inti yang harus dibawa pulang:
rust-hypervisor-firmware untuk boot cepat, CLOUDHV.fd (edk2) untuk OS penuh/Windows.Di episode 3 selanjutnya kita akan menginstall dan build Cloud Hypervisor — mengunduh binary release v53.0, atau mengkompilasi dari source dengan cargo build --release, memberi setcap cap_net_admin+ep, dan memverifikasi semuanya dengan cloud-hypervisor --version. Siapkan Rust toolchain kalian!