Belajar Cloud Hypervisor - Snapshot & Restore

#Pendahuluan

Setelah VM bisa di-provisioning otomatis dengan cloud-init di episode 9, saatnya membahas ketahanan state: apa yang terjadi ketika kalian ingin "mem-frozen" VM yang sedang berjalan dan melanjutkannya nanti — atau di host lain? Jawabannya adalah snapshot dan restore.

Bayangkan snapshot seperti memotret keadaan seluruh VM: memory (isi RAM), state CPU, dan state device disalin ke disk. Saat restore, VM dilanjutkan dari persis titik itu — proses yang berjalan tidak sadar bahwa ia sempat "dibekukan". Ini fondasi untuk backup konsisten, recovery, dan (bersama episode 11) live migration.

#Apa yang Disimpan dalam Snapshot

Sebuah snapshot Cloud Hypervisor menyimpan tiga hal utama:

• Memory: seluruh isi RAM guest, disalin ke file.
• Device state: konfigurasi dan state tiap virtio device (blk, net, fs, dsb.).
• vCPU state: register vCPU dan status eksekusi tiap thread.

Karena kompleksitas inilah snapshot tidak bisa sembarangan dipindahkan: format state device melekat pada versi tertentu. Restore snapshot antar versi Cloud Hypervisor berbeda tidak didukung — topik yang kita bedah di bagian batasan.

#Membuat Snapshot: API Snapshot

Snapshot dibuat lewat API socket ketika VM sedang berjalan. Siapkan VM dengan --api-socket (episode 8), lalu panggil endpoint snapshot:

curl --unix-socket /tmp/ch.sock -X PUT \
  -H "Content-Type: application/json" \
  --data '{
    "destination_url": "file:///srv/snapshots/vm-01"
  }' \
  http://localhost/api/v1/vm.snapshot

destination_url: file:///srv/snapshots/vm-01 menentukan lokasi output. Cloud Hypervisor menulis beberapa file ke direktori itu:

/srv/snapshots/vm-01/
├── memory_file                    # isi RAM guest
├── vm.json                        # state device & vCPU
└── (file device opsional lainnya)

Proses snapshot berlangsung tanpa menghentikan VM. Namun perlu dicatat: snapshot bukanlah zero-downtime dalam arti penuh — selama pembuatan, ada fase "stop the world" singkat (VM di-pause, memory disalin, VM dilanjutkan). Untuk workload yang benar-benar harus terus berjalan tanpa jeda, live migration (episode 11) adalah jawabannya.

#Restore: Menghidupkan Kembali

Restore dilakukan dengan menjalankan cloud-hypervisor baru yang memakai state snapshot:

cloud-hypervisor \
  --restore /srv/snapshots/vm-01 \
  --disk path=ubuntu.raw \
  --net tap=ch0,ip=192.168.100.1,mac=a8:21:95:80:35:e6

--restore /srv/snapshots/vm-01 membaca vm.json dan memory_file, lalu melanjutkan eksekusi guest dari titik snapshot diambil. Perhatikan: device config seperti --disk dan --net harus disediakan lagi — state device di snapshot dirujuk ulang dengan parameter CLI yang sesuai. MAC dan path disk harus konsisten dengan saat snapshot dibuat, karena guest menyimpan state koneksi terhadap device tersebut.

Verifikasi bahwa proses di guest berlanjut:

uptime -s
ps aux | grep aplikasi

uptime -s menunjukkan waktu boot yang lama (saat VM pertama start), bukan waktu restore — bukti bahwa VM dilanjutkan, bukan di-boot ulang.

#Offloaded Snapshot Daemon (v53.0)

Sejak v53.0 (12 Juli 2026), pembuatan snapshot bisa di-offload ke proses daemon terpisah. Alih-alih VMM menangani penyalinan memory di dalam prosesnya, sebuah daemon eksternal mengambil alih tugas itu. Keuntungannya: VMM lebih ringan saat snapshot, pembuatan snapshot bisa berjalan paralel di host berbeda, dan kesalahan dalam proses snapshot tidak meruntuhkan VM.

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

Alur kerjanya: VMM menyerahkan referensi memory ke daemon via socket, daemon menyalin memory ke file snapshot sementara VMM melanjutkan melayani VM. Ini mengurangi jeda "stop the world" dan mempercepat waktu snapshot — peningkatan yang signifikan untuk lingkungan yang melakukan snapshot massal.

#Batasan dan Best Practice

#Tidak Lintas Versi

Aturan paling penting: snapshot dibuat dengan versi X, hanya bisa di-restore dengan versi X (atau point-release yang kompatibel dalam LTS yang sama). Jangan harap snapshot dari v50 bisa di-restore di v53. Di production, simpan versi VMM yang dipakai di metadata snapshot dan pin versi saat deploy.

#Best Practice Format

• Simpan path disk tetap: letakkan snapshot dan disk di lokasi yang bisa diakses kedua host (shared storage) agar restore lintas host berjalan mulus.
• Snapshot saat idle: snapshot di tengah beban tinggi menghasilkan file lebih besar dan jeda lebih lama. Jadwalkan saat beban rendah.
• File yang sedang ditulis: snapshot menangkap state in-memory; data yang baru ditulis guest ke disk tidak ikut — pastikan filesystem guest konsisten (misal lewat fstrim/sync) sebelum snapshot bila ingin konsistensi penuh.
• Uji restore berkala: snapshot yang tidak pernah diuji restore adalah bom waktu. Jadwalkan uji restore sebagai bagian dari proses.

#Recovery Workflow

curl --unix-socket /tmp/ch.sock -X PUT \
  --data '{"destination_url":"file:///srv/snapshots/vm-01"}' \
  http://localhost/api/v1/vm.snapshot
tar czf backup-$(date +%F).tar.gz /srv/snapshots/vm-01

Arsipkan snapshot bersama konfigurasi VM (guest.json) dan versi binary — itu paket recovery yang lengkap.

#Pitfall Umum

• --memory shared=on terlupakan: snapshot gagal; set dari awal.
• Disk/MAC tidak konsisten: guest kehilangan koneksi network atau tidak bisa mount disk setelah restore.
• Mencoba restore lintas versi: gagal dengan error format; selalu cocokkan versi.
• Snapshot berulang tanpa disk: snapshot menyimpan state, bukan isi disk — pastikan disk image juga di-backup.

#Penutup

Inti yang harus dibawa pulang:

• Snapshot menyimpan memory, device state, dan vCPU state VM yang berjalan.
• Snapshot dibuat via API vm.snapshot dan dipulihkan dengan --restore.
• Membutuhkan --memory shared=on sejak awal.
• v53.0 menambahkan offloaded snapshot daemon untuk snapshot tanpa membebani VMM.
• Snapshot tidak bisa dipindahkan antar versi Cloud Hypervisor.
• Uji restore berkala dan arsip snapshot bersama konfigurasi serta versi binary.

Di episode 11 selanjutnya kita akan membahas live migration — memindahkan VM antar host tanpa downtime dengan protocol yang sudah diperluas, termasuk page-fault yang dilayani dari source di v53. Kita siapkan shared storage dan network, lalu bedah constraint kompatibilitas versi dan perangkat. VM kalian mulai bisa "berpindah rumah" tanpa sadar.