Belajar Cloud Hypervisor - v53.0 & Roadmap

#Pendahuluan

Kita sudah mengenal Cloud Hypervisor dari konsep sampai pengujian. Di episode 17 kita berhenti sejenak untuk melihat ke mana arah proyek ini — melalui kacamata rilis terbaru v53.0 (12 Juli 2026) dan roadmap yang digariskan komunitas. Memahami roadmap bukan sekadar kepuasan intelektual: keputusan arsitektur kalian hari ini (migrasi, snapshot, passthrough) bergantung pada apakah fitur tersebut akan dirawat dan ditingkatkan di masa depan.

Seperti menaiki kapal, lebih baik tahu ke mana kapal berlayar sebelum memutuskan naik.

#Rilis v53.0: Dua Fitur Kunci

#Offloaded Snapshot/Restore Daemon

Sebelum v53.0, snapshot ditangani di dalam proses VMM: VM di-pause, memory disalin, VM dilanjutkan. Semakin besar memory, semakin lama jeda — dan selama proses itu VMM ikut sibuk menyalin.

v53.0 mengubah arsitektur ini dengan offloaded snapshot/restore daemon: penyalinan memory dipindahkan ke proses eksternal terpisah. VMM cukup "menyerahkan" referensi memory guest ke daemon via socket, lalu kembali melayani VM sementara daemon yang melakukan pekerjaan berat penyalinan:

cloud-hypervisor-offload --snapshot-daemon --socket /tmp/offload.sock

Keuntungan praktisnya:

• Jeda lebih singkat: VMM tidak lagi menjadi bottleneck saat menyalin memory.
• Snapshot paralel: beberapa VM bisa di-snapshot bersamaan karena daemon independen dari masing-masing VMM.
• Isolasi kegagalan: kegagalan di proses snapshot tidak meruntuhkan VM.
• Restore juga ter-offload: memory dimuat ke guest oleh daemon sebelum VMM melanjutkan eksekusi.

Bagi operator, ini berarti snapshot massal (misal backup rutin ratusan VM) menjadi jauh lebih murah dan aman.

#Live Migration: Page-Fault dari Source

Fitur kedua di v53.0 menyempurnakan live migration (episode 11). Sebelumnya, migrasi menyalin seluruh memory sebelum memindahkan eksekusi — lama untuk VM besar. Dengan post-copy page-fault dari source:

1. Target mulai menjalankan VM lebih awal, bahkan saat memory belum sepenuhnya tersalin.
2. Saat target butuh halaman yang belum ada, ia mencuri halaman tersebut dari source (page-fault dilayani on-demand).
3. Proses berlanjut sampai seluruh halaman ada di target.

curl --unix-socket /tmp/source.sock -X PUT \
  -H "Content-Type: application/json" \
  --data '{"receiver_url":"http://192.168.100.2:5000","protocol":"extended"}' \
  http://localhost/api/v1/vm.migrate

protocol: "extended" mengaktifkan kemampuan post-copy — migrasi VM dengan memory besar kini bisa selesai dalam hitungan detik, bukan menit.

#Roadmap: Arah Pengembangan

Roadmap proyek (terbuka di repository resmi) memberikan petunjuk prioritas komunitas. Beberapa arah yang menonjol:

#Stabilitas Live Migration Lintas Versi

Saat ini migrasi hanya didukung antar versi yang kompatibel. Roadmap mengarah pada live migration yang lebih stabil lintas versi — upgrade host tanpa menghentikan VM. Ini fitur yang sangat dinanti operator besar: melakukan upgrade VMM secara bergilir tanpa downtime workload. Target jangka panjangnya: migration dari versi X ke X+n dengan jendela kompatibilitas yang terdefinisi dan diuji.

#Dukungan RISC-V

Setelah x86_64 dan aarch64 matang, RISC-V masuk sebagai arsitektur eksperimental. Ini sejalan dengan arah industri menuju open hardware. Dukungan ini masih muda — jangan jadikan fondasi produksi — tetapi penting bagi kalian yang memantau tren hardware terbuka.

#Device Passthrough yang Lebih Matang

VFIO dan vfio-user (episode 8) masih dalam tahap pengembangan untuk berbagai device. Roadmap menargetkan passthrough yang lebih matang: dukungan GPU yang lebih baik, isolasi yang lebih ketat, dan integrasi dengan vDPA. Untuk workload yang butuh akses hardware langsung (AI/ML, HPC), inilah area yang paling ditunggu.

#Stabilitas Fitur Eksperimental

TDX, vDPA, dan vfio-user bertransisi dari eksperimental menuju stabil secara bertahap. Sebagai operator, ikuti halaman rilis: fitur yang "no longer experimental" di catatan rilis adalah sinyal aman untuk mulai menguji di production.

#Membaca Rilis dan Menyusun Strategi Upgrade

#Riwayat Rilis Terdekat

• v50.0 (Des 2025): fondasi fitur besar.
• v50.1: perbaikan CVE-2026-27211 (episode 13) — wajib di-upgrade.
• v51.0 (Feb 2026), v51.2 (14 Mei 2026): penyempurnaan.
• v52.0: transisi menuju kemampuan migrasi yang diperluas.
• v53.0 (12 Jul 2026): offloaded snapshot daemon + post-copy migration.

Pola yang terlihat: rilis bulanan dengan fitur besar terkonsentrasi, dan patch untuk keamanan dirilis cepat. Strategi upgrade yang sehat:

cloud-hypervisor --version   # catat versi saat ini
# uji di staging: snapshot/restore, migrasi, boot VM
# lalu roll out ke production host per host

#Checklist Sebelum Upgrade

• Baca catatan rilis (CHANGELOG) untuk breaking changes.
• Uji snapshot/restore dan migrasi di lab dengan versi baru.
• Verifikasi format snapshot kompatibel (ingat: tidak lintas versi).
• Siapkan rollback (simpan binary versi lama).

#Penutup

Inti yang harus dibawa pulang:

• v53.0 (12 Jul 2026) menghadirkan offloaded snapshot/restore daemon sebagai proses eksternal.
• Live migration v53.0 memakai post-copy dengan page-fault dilayani dari source.
• Roadmap: stabilitas migrasi lintas versi, RISC-V eksperimental, passthrough lebih matang.
• Fitur eksperimental (TDX, vDPA, vfio-user) bertransisi menuju stabil bertahap.
• Strategi upgrade: baca changelog, uji di lab, rollback siap.
• Patch keamanan (seperti v50.1) harus diterapkan segera.

Di episode 18 selanjutnya kita akan mengintegrasikan semuanya ke dunia container: Cloud Hypervisor sebagai backend Kata Containers — RuntimeClass kata-clh yang menjalankan tiap pod di VM Cloud Hypervisor, setup via kata-deploy Helm chart, dan alur containerd shimv2 → Cloud Hypervisor → guest kernel → agent. Ini peran paling populer Cloud Hypervisor di Kubernetes.