Belajar Cloud Hypervisor - Testing & CI | Belajar Cloud Hypervisor

#Pendahuluan

Setelah menjelajahi hampir semua fitur Cloud Hypervisor, sekarang kita melihat bagaimana proyek ini menjaga dirinya tetap andal. Sebuah VMM tanpa pengujian ketat adalah bencana — satu bug di device model bisa berarti isolasi jebol antar tenant (ingat CVE-2026-27211 di episode 13). Di episode 16 kita membedah strategi testing Cloud Hypervisor dan cara kalian membuat benchmark untuk membandingkannya dengan VMM lain.

Ada dua sisi yang kita bahas: sebagai kontributor (menjalankan cargo test dan integration tests) dan sebagai operator (mengukur performa VMM di lingkungan kalian sendiri sebelum memutuskan mengadopsinya).

#Unit Test dan cargo test

#Struktur Proyek

Cloud Hypervisor adalah workspace Rust: crates modular di bawah crates/ (vmm, devices, vm-memory, dsb.). Unit test ditulis di samping kode, menguji logika murni — parsing config, state machine device, format snapshot — tanpa KVM:

Jalankan unit tests

cargo test --workspace

cargo test --workspace mengkompilasi seluruh crate dan menjalankan ribuan unit test. Karena tidak butuh hardware virtualization, test ini bisa dijalankan di mesin mana pun dengan Rust toolchain — inilah fondasi kualitas paling cepat.

#Filter dan Focus

Saat mengembangkan satu area, fokuskan test ke modul tertentu:

Test hanya crate vmm

cargo test -p vmm

Dan jalankan satu test spesifik dengan filter nama:

Jalankan test tertentu

cargo test -p vmm snapshot

snapshot memfilter test yang namanya mengandung "snapshot" — praktis saat memverifikasi perubahan pada format snapshot.

#Integration Tests: integration.rs

#Apa yang Diuji

Unit test tidak cukup — komponen yang benar sendiri-satu-satu belum tentu benar bersama. Karena itu Cloud Hypervisor punya integration tests yang menjalankan VMM sungguhan (butuh KVM) dan memverifikasi perilaku end-to-end. File utamanya tests/integration.rs: boot VM nyata, tes hotplug, snapshot/restore, network traffic, live migration, dan banyak lagi.

Jalankan integration tests

cargo test --test integration

Setiap test menyiapkan VM dari binary yang baru di-build, menjalankan skenario, dan memverifikasi hasil. Contoh skenario yang diuji:

Boot kernel hingga prompt konsol muncul dalam waktu tertentu.
Hotplug CPU/memory lalu verifikasi di dalam guest via agent.
Snapshot → restore → verifikasi proses guest berlanjut.
Live migration antar dua VMM instance di host yang sama.
Network: kirim paket host→guest→host dan pastikan diterima utuh.

Warning

Integration tests butuh /dev/kvm dan binary yang sudah di-build — menjalankannya di CI tanpa akselerasi hardware akan gagal. Inilah alasan mengapa CI Cloud Hypervisor memakai runner dengan KVM (atau nested virtualization), bukan runner container biasa.

#CI: Menargetkan Kernel 5.15

#Baseline Kernel

Proyek ini menjalankan CI-nya terhadap kernel 5.15 — kernel LTS yang menjadi baseline dukungan. Ini keputusan penting: fitur yang didukung harus berjalan di kernel LTS yang banyak dipakai production, bukan hanya kernel terbaru. CI akan menandai kegagalan yang hanya muncul di kernel baru sebagai regresi.

Contoh matriks CI (konsep)

strategy:
  matrix:
    kernel:
      - 5.15
      - latest
    arch:
      - x86_64
      - aarch64
steps:
  - name: Run integration tests
    run: cargo test --test integration

Matriks di atas menguji kombinasi kernel dan arsitektur — memastikan fitur tetap jalan di baseline sekaligus mengikuti kernel terbaru.

#Gerbang Kualitas

Alur CI umumnya: lint → unit test → build → integration test → benchmark dasar. Hanya PR yang lulus semua gerbang yang bisa di-merge. Jika kalian berkontribusi, CONTRIBUTING.md menjelaskan bagaimana menjalankan set yang sama secara lokal — ini praktik yang harus kalian tiru di proyek sendiri: gerbang otomatis sebelum merge, bukan andalan review manual.

#Benchmark: Cloud Hypervisor vs QEMU

#Mengapa Benchmark Sendiri

Klaim "boot cepat" dan "footprint kecil" tidak ada artinya tanpa angka di lingkungan kalian. Benchmark yang baik menjawab tiga pertanyaan: berapa lama boot, berapa memory yang dipakai, dan berapa throughput I/O yang bisa dicapai.

#Boot Time

Ukur waktu dari start VMM sampai prompt tersedia:

Ukur boot time Cloud Hypervisor

time cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=ubuntu.raw \
  --cpus boot=2 \
  --memory size=1G \
  --cmdline "console=ttyS0 root=/dev/vda1 quiet"

Lakukan hal yang sama dengan QEMU (kernel dan image yang identik):

Ukur boot time QEMU

time qemu-system-x86_64 \
  -kernel vmlinuz -initrd initrd.img -append "console=ttyS0 root=/dev/vda1 quiet" \
  -drive file=ubuntu.raw,format=raw,if=virtio \
  -enable-kvm -m 1G -smp 2 -nographic

Bandingkan time output: perbedaan boot time di lingkungan inilah angka yang sebenarnya kalian butuhkan — bukan klaim dari blog.

#Memory Overhead

Bandingkan penggunaan RSS proses VMM dengan beban identik:

Ukur RSS VMM

pgrep -f cloud-hypervisor | head -1 | xargs -I{} cat /proc/{}/status | grep VmRSS

Lakukan hal yang sama untuk qemu-system-x86_64. Memory overhead = RSS dikurangi memory guest (yang Anda set). Inilah biaya aktual VMM per VM — angka penting untuk menghitung densitas per host.

#Throughput I/O

Gunakan tool benchmark dalam guest, misal fio untuk disk dan iperf3 untuk network:

Benchmark disk di dalam guest

fio --name=randwrite --rw=randwrite --bs=4k --size=1G \
  --numjobs=4 --runtime=30 --ioengine=libaio --direct=1

Benchmark network di dalam guest

iperf3 -c 192.168.100.1

Jalankan skenario identik di QEMU dan Cloud Hypervisor, lalu bandingkan: latensi, IOPS, dan throughput. Hasilnya sering bergantung pada setup (hugepages, vhost-user, dsb.) — itulah mengapa benchmark di environment sendiri lebih berharga daripada angka orang lain.

#Pitfall Benchmark

Beban tidak identik: gunakan kernel, image, dan workload yang persis sama untuk kedua VMM.
Warm-up diabaikan: jalankan workload beberapa kali dan ambil nilai stabil, bukan percobaan pertama.
Memory cache host: jalankan benchmark bergantian dan biarkan host "dingin" untuk hasil konsisten.
Perbedaan config: QEMU default vs Cloud Hypervisor default bisa tidak adil — dokumentasikan opsi yang dipakai.

Tip

Jadikan benchmark sebagai script yang bisa diulang, bukan perintah ad-hoc. Simpan script di repo bersama hasilnya. Saat upgrade versi VMM atau kernel, jalankan ulang — perubahan performa yang tidak diinginkan akan terlihat jelas.

#Penutup

Inti yang harus dibawa pulang:

cargo test menjalankan ribuan unit test tanpa KVM; cargo test --test integration butuh KVM.
Integration tests menguji boot, hotplug, snapshot/restore, migrasi, dan network secara end-to-end.
CI menargetkan kernel 5.15 sebagai baseline LTS plus kernel terbaru.
Benchmark yang jujur mengukur boot time, memory overhead (RSS), dan throughput I/O.
Benchmark di environment sendiri mengalahkan klaim dari dokumentasi.
Jadikan benchmark script yang bisa dijalankan ulang di setiap upgrade.

Di episode 17 selanjutnya kita akan membahas v53.0 & roadmap — offloaded snapshot/restore daemon dan live migration dengan page-fault dari source yang baru diperkenalkan, lalu arah pengembangan: stabilitas live migration lintas versi, RISC-V, dan device passthrough yang lebih matang. Masa depan Cloud Hypervisor dimulai dari sini.