Belajar Cloud Hypervisor - Performance & Observability

#Pendahuluan

Sejauh ini VM kita "jalan". Di episode 20 kita bertanya: seberapa baik jalan-nya? Performa dan observability adalah dua sisi koin yang sama: tanpa pengukuran tidak ada optimasi, dan tanpa observasi tidak ada diagnosis. Di episode ini kita menyetel performa — hugepages, CPU pinning, NUMA awareness — lalu membangun observability — log, metrics, tracing, dan debugging dengan gdb.

Bayangkan performa seperti menyetel mesin mobil: hugepages memperbesar "tangki jalur cepat" (TLB), pinning mengunci pekerja di posisi tetap agar tidak bolak-balik, dan NUMA awareness memastikan data dekat dengan pemrosesnya. Observability adalah dashboard yang menunjukkan semua itu bekerja atau tidak.

#Tuning Performa

#Hugepages

Kita sudah menyentuh hugepages di episode 5. Sekarang kita mengoptimalkannya. Alokasi 2 MB halaman mengurangi jumlah entri TLB sehingga memory access lebih cepat:

Siapkan pool hugepages

echo 1024 | sudo tee /proc/sys/vm/nr_hugepages
grep HugePages_Total /proc/meminfo

Lalu jalankan VM dengan hugepages:

VM dengan hugepages + shared

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=os.raw \
  --cpus boot=4 \
  --memory size=4G,hugepages=on,shared=on

hugepages=on membuat RAM guest dari pool hugepage host; shared=on dibutuhkan untuk snapshot/migration (episode 10-11). Verifikasi di dalam guest bahwa halaman 2 MB benar-benar dipakai:

Cek hugepage di dalam guest

grep -i huge /proc/meminfo

#CPU Pinning dan Affinity

Secara default, vCPU thread bisa berpindah-pindah CPU fisik. Pinning mengunci setiap vCPU ke CPU fisik tertentu — mengurangi cache thrashing dan context switching, sangat terasa untuk workload latency-sensitive:

Pin vCPU ke CPU fisik

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=os.raw \
  --cpus boot=4 \
  --memory size=4G \
  --cpu-affinity vcpu:0-3

--cpu-affinity vcpu:0-3 memetakan keempat vCPU ke CPU fisik 0-3. Kombinasikan dengan isolcpus di host agar workload lain tidak berebut core tersebut:

Isolasi CPU di host (GRUB/EFI cmdline)

isolcpus=2,3,6,7 nohz_full=2,3,6,7 rcu_nocbs=2,3,6,7

#NUMA Awareness

Pada host multi-socket, memory dekat CPU (NUMA node) jauh lebih cepat diakses daripada yang jauh. Untuk workload memory-intensive, pastikan VM menempel di satu NUMA node, dan guest memetakan topology-nya agar aplikasi bisa menyetel sendiri:

Cek NUMA topology host

numactl --hardware

VM dengan topology NUMA eksplisit

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=os.raw \
  --cpus boot=8,topology="1 socket,8 cores,1 thread" \
  --memory size=8G \
  --numa guest_numa_id=0,cpus=[0-7],distances=[10,20]

Di dalam guest, aplikasi bisa melihat topology dan menyetel alokasinya:

Cek NUMA di dalam guest

numactl --hardware
numactl --show

Note

Tuning adalah trade-off, bukan list yang harus semua diaktifkan. Hugepages membantu memory-intensive tapi menambah overhead manajemen; pinning membantu latency tapi mengurangi fleksibilitas scheduler; NUMA membantu locality tapi membatasi pilihan penjadwalan. Ukur sebelum dan sesudah tiap perubahan.

#Observability

#Log VMM

Cloud Hypervisor menulis log ke stderr secara default. Aktifkan --log-file untuk menyimpan log dan kendalikan levelnya:

Simpan log VMM

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=os.raw \
  --cpus boot=4 \
  --memory size=4G \
  --log-file /var/log/ch-vm.log \
  --log-level info

Level yang tersedia: error, warning, info, debug, trace. trace sangat detail (setiap ioctl KVM dan event device) — nyalakan hanya saat debugging.

Saat ada masalah, urutkan dari log:

Cari error di log VMM

grep -iE "error|fatal" /var/log/ch-vm.log | tail -20

#Metrics

VMM menghasilkan metrics (jumlah VM-exit, disk I/O, network traffic, dll.) yang bisa diekspor untuk monitoring. Siapkan endpoint metrics:

Aktifkan HTTP metrics endpoint

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=os.raw \
  --cpus boot=4 \
  --memory size=4G \
  --metrics path=http://localhost:9091/metrics

Prometheus bisa men-scrape endpoint ini. Metrik yang berguna misalnya cloud_hypervisor_vm_exits (frekuensi VM-exit) dan cloud_hypervisor_disk_read_bytes. Pantau tren, bukan hanya nilai absolut — lonjakan VM-exit sering menandakan device yang bermasalah.

#Tracing

Untuk analisis mendalam, aktifkan tracing (misal memakai perf di host untuk vCPU thread):

Trace VM-exit dengan perf

perf record -e kvm:kvm_exit -g -- pid=$(pgrep -f cloud-hypervisor)
perf report

perf kvm menampilkan distribusi penyebab VM-exit — apakah dominan I/O, timer, atau yang lain. Ini data berharga untuk memutuskan apakah butuh vhost-user, hugepages, atau konfigurasi device yang berbeda.

#Debugging dengan gdb

Untuk masalah paling sulit (hang, crash VMM), pasang gdb ke proses:

Attach gdb ke VMM

sudo gdb -p $(pgrep -f 'cloud-hypervisor' | head -1)

Di dalam gdb, ambil backtrace untuk melihat di mana proses tersangkut:

Backtrace di gdb

(gdb) thread apply all bt
(gdb) bt

Untuk reproduksi crash yang konsisten, jalankan di bawah gdb sejak awal:

Jalankan VMM di bawah gdb

gdb --args cloud-hypervisor --kernel kernel-vmlinux --disk path=os.raw
(gdb) run

Saat crash terjadi, gdb menahan proses — dari sana kalian bisa melihat call stack dan mendiagnosis. Jika kalian menemukan bug, laporkan dengan backtrace lengkap ke repository resmi (episode 21).

#Workflow Optimasi yang Disarankan

Ukur baseline: boot time, memory RSS, throughput (episode 16).
Tentukan bottleneck: dari metrics dan perf — CPU, memory, atau I/O.
Terapkan satu perubahan: hugepages, pinning, atau NUMA — satu per satu.
Ukur lagi: bandingkan dengan baseline.
Ulangi: pertahankan yang memberi keuntungan nyata, batalkan yang tidak.

Tip

Jangan optimasi tanpa pengukuran — "premature optimization" menghasilkan konfigurasi kompleks tanpa manfaat terukur. Selalu mulai dari baseline, dan jadikan hasil benchmark (episode 16) sebagai script yang bisa diulang untuk membandingkan setiap versi konfigurasi.

#Pitfall Umum

Hugepages tanpa pool cukup: VM gagal start. Sesuaikan nr_hugepages dengan --memory size.
Pinning ke CPU yang sibuk: affinity tidak berguna jika core juga dipakai workload lain — kombinasikan dengan isolcpus.
NUMA salah set: topology yang tidak cocok dengan host membuat guest meletakkan data di node yang salah.
Log level trace di production: membanjiri disk — gunakan hanya saat debugging.
gdb tanpa ptrace permission: jalankan dengan sudo atau set ptrace_scope sesuai kebutuhan.

#Penutup

Inti yang harus dibawa pulang:

Hugepages mengurangi TLB misses; aktifkan dengan hugepages=on.
CPU pinning (--cpu-affinity) mengurangi cache thrashing untuk latency-sensitive workload.
NUMA awareness memastikan memory dekat dengan pemrosesnya.
Log VMM (--log-file, --log-level) adalah sumber diagnosis pertama.
Metrics via HTTP endpoint siap di-scrape Prometheus.
perf kvm untuk analisis VM-exit; gdb untuk hang dan crash.
Optimasi harus selalu diukur: baseline → ubah → ukur ulang.

Di episode 21 selanjutnya kita akan membahas ekosistem & governance — GitHub cloud-hypervisor, roadmap, Slack, dan mailing list, founding charter dengan open governance (Intel, AMD, Arm, Microsoft), serta proyek rust-vmm yang berbagi crate dengan Firecracker dan crosvm. Komunitas di balik VMM ini juga bagian dari teknologinya.