Belajar Cloud Hypervisor - Sejarah, Latar Belakang & Mengapa Membutuhkannya

#Pendahuluan

Setelah environment kita siap di episode 0, sekarang waktunya memahami mengapa Cloud Hypervisor ada. Setiap teknologi besar lahir karena masalah nyata, dan Cloud Hypervisor tidak terkecuali. Di episode 1 kita menelusuri sejarahnya dari inisiasi Intel pada 2019, evolusinya menjadi proyek open governance, hingga alasan konkret mengapa VMM berbasis Rust ini dibutuhkan di cloud workload modern.

Pertanyaan yang akan kita jawab: apa yang salah dengan QEMU sehingga para insinyur cloud membuat VMM baru? Mengapa memilih Rust? Dan mengapa akhirnya diadopsi sebagai salah satu backend resmi Kata Containers? Jawaban-jawaban ini penting karena menentukan kapan kalian harus memilih Cloud Hypervisor di production.

#Sejarah dan Latar Belakang

#Lahir dari Kebutuhan Cloud dan Kata Containers

Cloud Hypervisor diprakarsai Intel pada 2019. Konteks saat itu: proyek Kata Containers (isolasi container via VM) dan fungsi serverless membutuhkan VMM yang bisa boot cepat dan hemat resource — namun QEMU, VMM yang sangat lengkap, dianggap terlalu berat dan kompleks untuk skenario tersebut. Solusinya bukan memotong QEMU, melainkan membangun VMM baru yang "cloud-first".

Prinsip desainnya sederhana: sedikit, fokus, dan aman. Fokus pada workload cloud modern (Linux/Windows) dengan device model virtio modern, bukan emulasi perangkat legacy yang puluhan tahun usianya. Dari sana lahir Cloud Hypervisor sebagai proyek open source di bawah lisensi Apache 2.0.

#Open Governance

Sejak 2021 proyek ini bertransformasi menjadi open governance dengan kontributor dari banyak perusahaan. Founding charter-nya melibatkan Intel, AMD, Arm, dan Microsoft — keempatnya kini berkontribusi aktif. Ini penting: karena diatur secara terbuka, Cloud Hypervisor tidak bisa diarahkan demi kepentingan satu vendor, dan dukungan multi-arsitektur (x86_64 dan aarch64) menjadi prioritas nyata, bukan sekadar janji.

#Rilis LTS Pertama: v28

Pada November 2022, Cloud Hypervisor merilis versi LTS (Long Term Support) pertamanya: v28, dengan periode dukungan 18 bulan. Model LTS ini meniru praktik distribusi enterprise: ada versi stabil yang dirawat lama untuk production, sementara rilis minor bulanan tetap membawa fitur baru. Yang menarik, LTS di Cloud Hypervisor menjamin live migration antar point-release — misalnya dari v28.0 ke v28.1 — sehingga pengguna production bisa upgrade keamanan tanpa mengorbankan kontinuitas operasional. Kita bahas live migration lebih dalam di episode 11.

#Mengapa Membutuhkan Cloud Hypervisor

#Virtio Modern Tanpa Bloat

QEMU mendukung ratusan perangkat legacy (IDE, PS/2, VGA lama, dsb.) yang hampir tidak dipakai di cloud. Cloud Hypervisor mengambil jalur berlawanan: ia meniru device model virtio modern dari QEMU — sehingga kompatibel dengan driver guest standar — tetapi menolak perangkat kuno. Hasilnya kode jauh lebih sedikit, permukaan serangan lebih kecil, dan binari lebih ramping.

ls -lh /usr/local/bin/cloud-hypervisor /usr/bin/qemu-system-x86_64

Secara umum binary statis Cloud Hypervisor berada di kisaran puluhan MB, sementara QEMU yang lengkap jauh lebih besar dan bergantung pada banyak library. Ukuran kecil ini juga berarti proses start lebih cepat dan penggunaan memori lebih rendah.

#Boot Cepat dan Footprint Kecil

Karena tidak ada emulasi firmware BIOS legacy dan device set-nya minimal, boot Linux direct (tanpa GRUB) bisa selesai dalam hitungan milidetik sampai detik, bukan puluhan detik. Footprint memori kecil membuat densitas VM per host meningkat — satu hal yang sangat disukai platform serverless.

#Hotplug, Snapshot/Restore, dan Live Migration

Cloud Hypervisor mendukung hotplug CPU dan memory (menambah resource tanpa restart VM), snapshot/restore (menyimpan state VM ke disk lalu memulihkannya), dan live migration (memindahkan VM antar host tanpa downtime). Ketiga fitur ini adalah kebutuhan operasional cloud yang biasanya hanya dimiliki VMM besar. Kita akan mempraktikkannya di episode 8, 10, dan 11.

#Backend Kata Containers: kata-clh

Salah satu pemakaian paling signifikan adalah sebagai backend Kata Containers lewat runtime kata-clh. Setiap pod di Kubernetes diisolasi di dalam VM Cloud Hypervisor yang ringan — keamanan VM dengan kelincahan container. Detailnya kita bedah di episode 18.

#Posisi di Ekosistem VMM

Untuk memposisikan Cloud Hypervisor, ingatlah tiga arus utama VMM:

• QEMU/KVM: VMM lengkap, kompatibilitas luas, tetapi kompleks dan berat.
• Firecracker: mikroVM minimalis dari AWS untuk fungsi serverless — kecepatan di atas fitur.
• Cloud Hypervisor: kompromi modern — VMM penuh fitur (hotplug, migration, passthrough) tetapi dengan filosofi minimalis Rust.

Cloud Hypervisor mengisi ruang yang ditinggalkan keduanya: feature-rich untuk VM penuh namun cukup cepat dan kecil untuk workload microVM. Di episode 22 kita akan membandingkannya secara menyeluruh dengan Firecracker, QEMU, crosvm, dan Kata Containers.

#Penutup

Inti yang harus dibawa pulang:

• Cloud Hypervisor lahir dari kebutuhan cloud/Kata Containers: VMM cepat, minimal, dan aman.
• Diprakarsai Intel (2019), kini open governance dengan kontributor AMD, Arm, dan Microsoft.
• LTS pertama v28 (Nov 2022) dengan 18 bulan dukungan dan live migration antar point-release.
• Virtio modern tanpa bloat, boot cepat, footprint kecil, hotplug, snapshot/restore, dan live migration.
• Ditulis dalam Rust, sehingga aman dari kelas bug memory-safety yang umum di VMM berbasis C.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Cloud Hypervisor — bagaimana VMM single-binary ini bekerja di atas KVM, bagaimana device virtio (net, block, pmem, fs, vsock, rng) dibangun, peran vhost-user untuk offload, serta fungsi rust-hypervisor-firmware dan CLOUDHV.fd. Inilah anatomi yang akan menjelaskan setiap flag yang kita pakai di episode-episode berikutnya.