Belajar Cloud Hypervisor - Live Migration

#Pendahuluan

Snapshot yang kita pelajari di episode 10 memang menangkap state VM, tetapi ada jeda singkat saat VM di-pause. Untuk menjaga ketersediaan penuh — server yang melayani request tidak boleh berhenti sedetik pun — kita butuh live migration: memindahkan VM dari satu host ke host lain tanpa downtime yang dirasakan guest.

Analogi terbaiknya seperti memindahkan toko yang sedang ramai pelanggan ke gedung baru: semua barang dipindahkan sedikit demi sedikit sementara pelanggan tetap dilayani, dan begitu pindahannya nyaris selesai, baru ada perpindahan terakhir yang sekejap. Di episode 11 kita membedah bagaimana Cloud Hypervisor melakukan ini, apa saja prasyaratnya, dan batasan yang wajib kalian hormati di production.

#Prinsip Dasar Live Migration

#Cara Kerja

Migrasi berjalan dalam beberapa fase:

1. Persiapan: host tujuan (target) menyiapkan VM baru dengan konfigurasi sama, tapi dalam keadaan "menunggu".
2. Pra-copy: memory guest disalin dari source ke target secara inkremental sambil VM tetap berjalan di source. Halaman yang berubah selama penyalinan (dirty pages) dicatat dan disalin lagi di iterasi berikutnya.
3. Stop-and-copy: saat sisa dirty pages cukup kecil, VM di-pause sejenak, sisa memory dan state vCPU/device disalin, lalu eksekusi dipindahkan ke target.
4. Post-copy (di v53 diperluas): VM sudah berjalan di target, tetapi halaman memory yang belum sempat disalin (page fault) dilayani dari source sesuai permintaan.

Keberhasilan migrasi bergantung pada seberapa cepat dirty pages disalin dibanding laju perubahan memory — semakin lambat laju perubahan, semakin singkat jeda stop-and-copy.

#Page-Fault dari Source (v53.0)

Sejak v53.0 (12 Juli 2026), live migration memakai pendekatan post-copy dengan page-fault dilayani dari source. Artinya: alih-alih menunggu seluruh memory tersalin (yang bisa lama untuk VM dengan memory besar), target segera menjalankan VM dan meminta halaman yang dibutuhkan ke source saat terjadi page fault. Dampaknya: total waktu migrasi jauh lebih pendek, dengan biaya ketergantungan pada ketersediaan source selama masa transisi.

#Prasyarat: Shared Storage dan Network

#Shared Storage

Migrasi memindahkan state mesin, bukan isi disk. Karena itu kedua host harus melihat disk yang sama — shared storage (NFS, iSCSI, Ceph RBD, atau distributed storage). Di praktik kita, siapkan NFS:

sudo mkdir -p /srv/vms
sudo mount -t nfs storage.internal:/exports/vms /srv/vms

Kedua host mengakses ubuntu.raw dan file snapshot dari lokasi yang sama. Jika tidak, target tidak akan bisa membaca disk saat VM dipindahkan.

#Network

Source dan target harus saling terhubung, dan idealnya berada di bridge jaringan yang sama sehingga MAC dan IP guest tetap berlaku tanpa perlu rekonfigurasi network:

sudo ip link add name br0 type bridge
sudo ip link set br0 up
sudo ip link set eth0 master br0

Jika jaringan berbeda, guest harus direkonfigurasi setelah migrasi — yang justru menghilangkan keunggulan "tanpa downtime".

#Menjalankan Migrasi

#Siapkan Target

Host tujuan memulai VM dalam mode "receive", menunggu migrasi datang:

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=/srv/vms/ubuntu.raw \
  --cpus boot=2 \
  --memory size=2G,shared=on \
  --net tap=ch0,ip=192.168.100.1,mac=a8:21:95:80:35:e6 \
  --api-socket /tmp/target.sock

Perhatikan bahwa ini VM biasa — migrasi nanti "menimpa" state-nya. shared=on di kedua sisi adalah wajib (sama seperti snapshot).

#Mulai Migrasi dari Source

Dari host source, panggil endpoint migrasi lewat API:

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

• receiver_url: alamat yang dibuka target untuk menerima data migrasi.
• protocol: "extended": memakai protocol live migration yang diperluas — termasuk post-copy page-fault yang dilayani source di v53.

Target mendengarkan di port tersebut dengan memakai socket API-nya:

curl --unix-socket /tmp/target.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

Saat migrasi selesai, VM di source otomatis berhenti dan eksekusi berlanjut penuh di target. Dari sisi guest, tidak ada proses yang sadar telah pindah host.

#Verifikasi di Guest

Di dalam guest, pastikan tidak ada gangguan berarti:

uptime -s
cat /proc/uptime

uptime -s tetap menunjukkan waktu boot awal — jika menunjukkan waktu migrasi, berarti VM baru saja di-reboot, bukan dimigrasi. Untuk uji yang lebih meyakinkan, jalankan ping terus-menerus dari host selama migrasi dan amati bahwa hanya ada jeda milidetik (bukan puluhan detik).

#Constraint dan Batasan

#Tidak Lintas Versi

Aturan yang sama dengan snapshot berlaku: live migration tidak didukung antar versi Cloud Hypervisor yang berbeda. Kedua host harus menjalankan versi yang identik (atau dalam jendela kompatibilitas LTS yang dijamin). Ini konsekuensi dari format state yang melekat pada versi. Di production, pisahkan "release train" migrasi: upgrade semua host dalam satu gelombang, bukan bertahap antar versi besar.

#Kompatibilitas Perangkat

Tidak semua device bisa dimigrasi dengan mudah:

• Passthrough VFIO (episode 8): device fisik tidak bisa "dipindahkan" ke host lain — perangkat di target harus identik dan tersedia. Ini sering menjadi alasan VM dengan passthrough tidak memenuhi syarat migrasi.
• vhost-user: daemon di source tidak otomatis pindah; target perlu daemon dengan socket yang sama.
• TAP name dan MAC: harus konsisten antara source dan target.

Sebelum migrasi, periksa bahwa konfigurasi device kedua host benar-benar sejajar:

diff <(cat /srv/vms/guest.json) <(ssh target "cat /srv/vms/guest.json")

#Windows Guest

Migrasi Windows punya tantangan tambahan terkait timer (TSC) dan device — pastikan kedua host memakai CPU dengan fitur yang identik, karena guest Windows sangat sensitif terhadap perbedaan fitur CPU yang diekspos.

#Pitfall Umum

• Shared storage tidak benar-benar shared: kedua host membaca salinan disk berbeda → data korup. Verifikasi dengan menulis dari satu host dan membaca dari host lain.
• Versi VMM berbeda: migrasi gagal atau state tidak kompatibel. Selalu pin versi.
• shared=on hanya di satu sisi: target gagal menerima memory. Set di kedua sisi.
• Bridge berbeda: guest kehilangan koneksi setelah pindah karena berada di L2 network yang beda.
• Lupa menonaktifkan passthrough: device fisik tidak ikut migrasi.

#Penutup

Inti yang harus dibawa pulang:

• Live migration memindahkan VM antar host tanpa downtime: pra-copy → stop-and-copy → post-copy.
• v53.0 memperluas post-copy dengan page-fault dilayani dari source — migrasi jauh lebih cepat.
• Shared storage wajib: kedua host melihat disk yang sama.
• Network kedua host harus konsisten (bridge, MAC) agar guest tidak putus koneksi.
• Tidak didukung lintas versi; kompatibilitas device (terutama passthrough) harus diperiksa.
• Migrasi adalah operasi yang perlu diuji rutin, bukan improvisasi.

Di episode 12 selanjutnya kita akan membedah virtual I/O: virtio, IOMMU, dan security — cara kerja ring buffer virtio dan packed virtio, virtio-iommu untuk IOMMU paravirtualisasi, serta sandboxing Landlock dan seccomp yang melindungi host dari VMM itu sendiri. Keamanan VM dimulai dari bawah.