Virtualisasi dengan KVM/QEMU

Bab 26 dan Bab 27 menutup pembahasan container dengan satu batasan penting yang sengaja belum diselesaikan, yaitu setiap container Docker tetap berbagi kernel yang sama dengan host-nya, seperti yang sudah disinggung pada Bagian 26.1. Batasan ini nyaris tidak terasa untuk kebutuhan sehari-hari seperti menjalankan web server atau database, tetapi menjadi masalah serius ketika Sysadmin dihadapkan pada kebutuhan yang jauh lebih ketat. Bagaimana jika Developer butuh menguji aplikasi di atas kernel Linux versi lain yang berbeda dari host produksi? Bagaimana jika sebuah tim butuh menjalankan Windows Server untuk aplikasi legacy, sementara seluruh infrastruktur lain berjalan di Ubuntu? Atau bagaimana jika kebijakan keamanan perusahaan mewajibkan isolasi penuh antar-tenant, sampai ke level kernel, bukan sekadar namespace dan cgroup seperti yang menjadi fondasi container? Container tidak bisa menjawab ketiga skenario ini, karena sifatnya memang berbagi kernel, bukan menjalankan kernel sendiri-sendiri. Bab 28 menjawab kebutuhan tersebut melalui KVM (Kernel-based Virtual Machine), teknologi virtualisasi penuh bawaan kernel Linux, dipasangkan dengan QEMU sebagai mesin emulasi perangkat dan libvirt sebagai lapisan manajemen di atas keduanya. Bab ini dimulai dari konsep dasar hypervisor, dilanjutkan dengan instalasi stack KVM/QEMU/libvirt di Ubuntu Server 26.04 LTS, membuat virtual machine pertama secara headless lewat virt-install, hingga menutup bab dengan operasional harian melalui virsh, termasuk snapshot untuk rollback cepat.

28.1 Hypervisor Tipe 1 vs Tipe 2: Fondasi Virtualisasi Penuh

Sebelum masuk ke instalasi, kita perlu memahami dulu di mana posisi KVM dibandingkan hypervisor lain yang mungkin sudah pernah kita dengar, seperti VMware ESXi atau VirtualBox, serta mengapa arsitekturnya justru sedikit tidak biasa dibanding keduanya.

28.1.1 Dari Container ke Virtualisasi Penuh: Kernel Terpisah untuk Setiap Guest

Container, seperti yang sudah kita praktikkan sepanjang Bab 26 dan 27, mengisolasi proses melalui namespace dan cgroup di atas satu kernel yang sama. Virtualisasi penuh mengambil pendekatan yang jauh lebih ekstrem, yaitu setiap virtual machine (disingkat VM, sering juga disebut guest) menjalankan kernelnya sendiri secara utuh, lengkap dengan device driver, memory management, dan scheduler-nya masing-masing, seolah-olah berjalan di atas hardware fisik sungguhan. Sebuah komponen software yang disebut hypervisor bertugas menciptakan dan mengelola hardware virtual ini, mulai dari CPU, RAM, storage, hingga network interface, lalu membagikannya ke setiap guest secara terisolasi.

Konsekuensi dari isolasi tingkat kernel ini cukup signifikan. VM jauh lebih berat dibanding container, baik dari sisi waktu boot (puluhan detik hingga menit, bukan milidetik) maupun konsumsi resource, karena setiap VM harus memuat kernel dan seluruh proses sistem operasinya sendiri. Sebagai balasannya, VM mendapatkan isolasi keamanan yang jauh lebih kuat dan kebebasan penuh memilih sistem operasi guest, dua hal yang tidak bisa ditawar oleh container.

28.1.2 Hypervisor Tipe 1 (Bare Metal) vs Tipe 2 (Hosted)

Literatur virtualisasi umumnya membagi hypervisor menjadi dua tipe berdasarkan posisinya relatif terhadap hardware dan sistem operasi.

Pembagian dua tipe ini sudah dipakai sejak literatur virtualisasi klasik era 1970-an, jauh sebelum Linux dan KVM ada. Masalahnya, KVM tidak pas masuk ke salah satu kategori secara murni, dan bagian berikutnya menjelaskan alasannya.

28.1.3 KVM sebagai Kernel Linux yang Menjadi Hypervisor

KVM bukan aplikasi hypervisor terpisah yang perlu dipasang seperti ESXi, melainkan sebuah modul kernel (kvm.ko beserta kvm_intel.ko atau kvm_amd.ko tergantung vendor CPU) yang sudah menyatu di dalam kernel Linux sejak versi 2.6.20. Begitu modul ini aktif, kernel Linux yang sedang berjalan itu sendiri berfungsi sebagai hypervisor, memakai fitur hardware virtualization extension dari CPU (Intel VT-x atau AMD-V) untuk menjalankan instruksi guest secara nyaris langsung di CPU fisik, bukan diterjemahkan satu per satu lewat emulasi software yang lambat.

Disebabkan oleh posisi ini, KVM sering disebut sebagai hypervisor tipe 1 yang berjalan di dalam OS tujuan umum, alih-alih tipe 1 murni yang tidak memiliki OS host sama sekali seperti ESXi. Host Ubuntu Server yang sedang kita kelola tetap bisa dipakai untuk keperluan lain di luar virtualisasi, sesuatu yang tidak berlaku untuk ESXi yang benar-benar didedikasikan penuh sebagai hypervisor. KVM sendiri hanya menyediakan kemampuan eksekusi CPU dan memory dasar. Modul ini tidak mengemulasi BIOS, kartu grafis, controller disk, atau kartu jaringan virtual, dan di sinilah QEMU mengambil peran. QEMU adalah emulator mesin lengkap yang menyediakan seluruh perangkat virtual tersebut, sekaligus memanfaatkan KVM sebagai akselerator agar CPU guest berjalan mendekati kecepatan native, bukan diemulasi penuh yang jauh lebih lambat. Kombinasi keduanya umum disebut sebagai KVM/QEMU, dan hampir selalu berjalan berdampingan di Ubuntu Server.

Satu lapisan terakhir yang melengkapi stack ini adalah libvirt, sebuah API dan daemon manajemen yang berdiri di atas QEMU. Tanpa libvirt, mengelola VM berarti memanggil binary qemu-system-x86_64 secara langsung dengan puluhan flag command line yang rumit untuk setiap VM. libvirt menyembunyikan kerumitan ini di balik definisi VM berbasis XML dan perintah virsh yang jauh lebih mudah dikelola, sekaligus menjadi lapisan API yang sama dipakai oleh tool tingkat lebih tinggi seperti virt-install, virt-manager, hingga platform cloud seperti OpenStack.

28.1.4 Memeriksa Dukungan Virtualisasi Hardware

KVM hanya bisa aktif jika CPU host mendukung dan mengaktifkan hardware virtualization extension. Langkah ini wajib diperiksa lebih dulu sebelum melangkah ke instalasi, karena tanpa dukungan ini, VM tetap bisa dibuat tetapi berjalan lewat emulasi software penuh yang sangat lambat, nyaris tidak terpakai untuk kebutuhan nyata.

Langkah Praktik

1. Periksa apakah CPU mendukung Intel VT-x (vmx) atau AMD-V (svm).

   grep -Ec '(vmx|svm)' /proc/cpuinfo

2. Pasang cpu-checker untuk mendapatkan tool kvm-ok yang memberi diagnosis lebih lengkap dibanding sekadar membaca /proc/cpuinfo.

   sudo apt update
   sudo apt install cpu-checker

3. Jalankan pemeriksaan lengkap.

   sudo kvm-ok

Verifikasi dan Troubleshooting

• Angka lebih dari 0 dari perintah grep di atas menandakan CPU mendukung virtualisasi. Angka 0 berarti CPU memang tidak mendukung, atau fitur ini masih dinonaktifkan di BIOS/UEFI host.
• Output sehat dari kvm-ok menampilkan INFO: /dev/kvm exists diikuti KVM acceleration can be used.
• Jika muncul INFO: Your CPU does not support KVM extensions, CPU host memang tidak mendukung virtualisasi hardware, dan hentikan proses di sini karena instalasi KVM tidak akan berfungsi optimal.
• Jika muncul pesan KVM acceleration can NOT be used disertai baris INFO: KVM (vmx) is disabled by your BIOS (atau svm untuk CPU AMD), artinya CPU sebenarnya mendukung virtualisasi tetapi fiturnya masih dimatikan di firmware. Masuk ke BIOS/UEFI host dan aktifkan opsi bernama Intel VT-x, Intel Virtualization Technology, atau AMD-V tergantung vendor motherboard, lalu lakukan hard power off/on, bukan sekadar reboot, agar firmware benar-benar membaca ulang setting tersebut.
• Berikut adalah catatan penting dari lapangan untuk server yang sebenarnya berupa VM di cloud atau di dalam hypervisor lain (misalnya VM cloud provider, atau VM di dalam VirtualBox seperti yang disinggung Bagian 2.4): KVM di dalam KVM disebut nested virtualization dan tidak selalu aktif secara default. Provider cloud tertentu menyediakan tipe instance khusus dengan nested virtualization aktif (biasanya ditandai fitur "bare metal" atau "nested KVM"), sementara sebagian lain menutupnya sama sekali demi alasan keamanan multi-tenant. Jika kvm-ok gagal di dalam VM, periksa dokumentasi provider terkait dukungan nested virtualization sebelum menganggap hardware tidak mendukung.

28.2 Instalasi KVM, QEMU, dan libvirt di Ubuntu Server 26.04 LTS

Setelah dukungan hardware terkonfirmasi, bagian ini memasang seluruh stack virtualisasi sekaligus menyiapkan akses operasional yang aman untuk pengguna non-root.

28.2.1 Paket yang Dibutuhkan dan Peran Masing-masing

Langkah Praktik

1. Pasang seluruh paket inti dalam satu perintah.

   sudo apt update
   sudo apt install qemu-system-x86 qemu-utils libvirt-daemon-system libvirt-clients virtinst

Setiap paket di atas punya peran spesifik yang perlu dipahami, bukan sekadar dipasang begitu saja.

Sebagian tutorial lama masih menyertakan paket bridge-utils dalam daftar ini. Paket tersebut sudah usang, digantikan oleh perintah ip link dan bridge dari iproute2 yang sudah terpasang bawaan di Ubuntu Server. libvirt-daemon-system sendiri sejak beberapa rilis terakhir memang tidak lagi memiliki dependency ke bridge-utils, karena libvirt mengelola bridge virbr0 secara langsung lewat netlink, tanpa memanggil binary brctl sama sekali.

Verifikasi dan Troubleshooting

• Konfirmasikan versi QEMU dan libvirt yang terpasang.

  qemu-system-x86_64 --version
  virsh version

  Ubuntu Server 26.04 LTS membawa QEMU 10.2 dan libvirt 12.0 di repository main sebagai baseline yang didukung penuh sepanjang siklus LTS. Bagi yang butuh fitur virtualisasi lebih baru tanpa menunggu rilis LTS berikutnya, Canonical juga menyediakan virtualisation HWE stack opsional (paket qemu-hwe dan libvirt-hwe) yang diperbarui mengikuti rilis interim, di luar cakupan bab ini.

28.2.2 Modular libvirt Daemon: virtqemud Menggantikan libvirtd

Bagian ini penting untuk dipahami karena menjadi jebakan umum bagi Sysadmin yang terbiasa dengan tutorial lama. Sejak Ubuntu 24.04 LTS, paket libvirt-daemon-system tidak lagi memakai satu daemon monolitik libvirtd untuk segala urusan. Sebagai gantinya, libvirt kini terpecah menjadi beberapa daemon modular yang masing-masing menangani satu driver spesifik, mengikuti socket activation systemd sehingga daemon yang tidak dipakai tidak perlu berjalan terus-menerus di background.

Dalam praktiknya, kita jarang perlu berinteraksi langsung dengan masing-masing daemon ini satu per satu, karena virsh dan virt-install otomatis berbicara ke daemon yang tepat lewat virtproxyd. Namun, memahami pergeseran arsitektur ini penting supaya tidak bingung saat sebuah tutorial lama menyuruh menjalankan sudo systemctl restart libvirtd dan justru mendapat error.

Langkah Praktik

1. Periksa status socket daemon utama yang menangani QEMU/KVM.

   systemctl status virtqemud.socket

Verifikasi dan Troubleshooting

• Status active (listening) menandakan socket sudah siap menerima koneksi, dan daemon virtqemud sendiri baru benar-benar berjalan penuh (active (running)) begitu ada client pertama yang terhubung, sesuai model socket activation.
• Jika mencoba sudo systemctl restart libvirtd dan muncul error Failed to start libvirtd.service - libvirt legacy monolithic daemon, ini bukan tanda instalasi rusak. Error tersebut hanya menandakan sistem memang sudah beralih ke daemon modular, dan perintah yang benar untuk kebutuhan restart adalah sudo systemctl restart virtqemud.

28.2.3 Akses Non-root Melalui Group libvirt dan kvm

Secara default, operasi libvirt lewat socket qemu:///system membutuhkan privilege root. Menambahkan user administrasi ke dua group berikut menghindarkan kita dari kebiasaan buruk mengetik sudo di depan setiap perintah virsh.

Langkah Praktik

1. Tambahkan user yang sedang aktif ke group libvirt dan kvm.

   sudo usermod -aG libvirt,kvm $USER

2. Terapkan perubahan group tanpa perlu logout penuh, cukup untuk sesi shell yang sedang berjalan.

   newgrp libvirt

Verifikasi dan Troubleshooting

• Konfirmasikan koneksi ke libvirt berhasil tanpa sudo.

  virsh list --all

• Perubahan group lewat usermod baru sepenuhnya berlaku di sesi SSH baru. Perintah newgrp hanya menambal sesi yang sedang aktif saat ini; untuk kepastian penuh terutama di sesi lain yang sudah terbuka, logout dan login ulang tetap lebih aman.
• Jika virsh list --all masih menampilkan error Failed to connect socket ... Permission denied, pastikan keanggotaan group sudah benar dengan groups $USER, dan ingat bahwa anggota group sudo sebenarnya sudah otomatis mendapat akses penuh lewat polkit meski belum masuk group libvirt secara eksplisit.

28.2.4 Jaringan NAT Default dan Storage Pool

libvirt menyiapkan dua resource dasar yang dipakai hampir setiap VM, yaitu jaringan dan tempat penyimpanan disk virtual. Keduanya perlu dipastikan aktif sebelum membuat VM pertama.

Langkah Praktik

1. Periksa status network bawaan bernama default.

   virsh net-list --all

2. Jika network default berstatus tidak aktif, jalankan dan aktifkan autostart-nya agar tetap hidup setelah host reboot.

   virsh net-start default
   virsh net-autostart default

3. Periksa storage pool untuk menyimpan file disk virtual.

   virsh pool-list --all

4. Jika belum ada pool bernama default, buat pool berbasis direktori yang mengarah ke lokasi standar /var/lib/libvirt/images.

   virsh pool-define-as default dir --target /var/lib/libvirt/images
   virsh pool-build default
   virsh pool-start default
   virsh pool-autostart default

Verifikasi dan Troubleshooting

• Network yang sehat menampilkan baris default dengan status active dan yes pada kolom Autostart. Network ini dibangun di atas bridge virtual bernama virbr0, memberikan setiap VM alamat IP privat lewat dnsmasq yang berjalan otomatis, lalu meneruskan traffic keluar lewat NAT ke interface fisik host, mirip cara kerja router rumahan.

  ip addr show virbr0

• Storage pool yang sehat juga menampilkan status active pada kolom yang sama. Berbeda dari network default yang hampir selalu sudah otomatis ada setelah instalasi paket, pool default pada sejumlah instalasi Ubuntu justru tidak otomatis terdefinisi, sehingga langkah manual di atas cukup sering benar-benar dibutuhkan, bukan sekadar langkah pencegahan.
• Seluruh perintah virsh di atas berhasil tanpa sudo karena user sudah menjadi anggota group libvirt sejak Bagian 28.2.3. Konfigurasi polkit bawaan Ubuntu memberi anggota group ini akses penuh ke qemu:///system, bukan cuma akses baca, sehingga operasi yang mengubah definisi seperti pool-define-as ikut bekerja tanpa privilege root eksplisit.
• Jika ingin memakai LVM sebagai backend storage pool alih-alih direktori biasa (misalnya untuk memanfaatkan snapshot LVM yang sudah dibahas pada Bagian 7.2), libvirt juga mendukung tipe pool logical, di luar cakupan konfigurasi dasar bab ini.

28.3 Membuat Virtual Machine dengan virt-install

Bagian ini mempraktikkan pembuatan VM pertama secara headless sepenuhnya lewat command line, cocok untuk server tanpa monitor maupun GUI, sekaligus jauh lebih mudah diulang dan diotomasi dibanding instalasi manual lewat virtual optical drive seperti yang dipraktikkan pada Bagian 2.4.

28.3.1 Mengunduh ISO dan Memeriksa os-variant

Langkah Praktik

1. Unduh ISO Ubuntu Server 26.04 LTS langsung ke direktori storage pool, sama seperti yang sudah diunduh dari ubuntu.com/download/server pada Bagian 2.1.

   cd /var/lib/libvirt/images
   sudo wget https://releases.ubuntu.com/26.04/ubuntu-26.04-live-server-amd64.iso

2. Pasang libosinfo-bin untuk mendapatkan perintah osinfo-query. Paket ini tidak ikut terpasang otomatis lewat virtinst pada Bagian 28.2.1, karena virtinst hanya membawa binding Python ke libosinfo, bukan tool command line-nya.

   sudo apt install libosinfo-bin

3. Periksa apakah osinfo database lokal, yaitu database yang dipakai libvirt untuk menerapkan konfigurasi optimal per sistem operasi guest, sudah mengenali Ubuntu 26.04.

   osinfo-query os | grep -i ubuntu26

Verifikasi dan Troubleshooting

• Jika baris ubuntu26.04 tidak muncul karena paket osinfo-db di server belum diperbarui, jangan memaksakan value tersebut secara manual. Gunakan flag --os-variant detect=on,require=off pada virt-install di langkah berikutnya, yang membuat libvirt mendeteksi OS dari ISO secara otomatis, sekaligus tidak gagal keras jika deteksi tidak pasti.

28.3.2 Instalasi VM Headless Lewat Serial Console

Perintah virt-install berikut membuat VM baru sekaligus langsung mem-boot installer Subiquity dari ISO, dengan output diarahkan ke serial console alih-alih VNC, sehingga bisa langsung diikuti dari sesi SSH ke host tanpa software VNC client tambahan.

Langkah Praktik

1. Jalankan virt-install dengan disk 20 GB, RAM 2 GB, dan 2 vCPU.

   virt-install \
     --name vm-app01 \
     --memory 2048 \
     --vcpus 2 \
     --disk path=/var/lib/libvirt/images/vm-app01.qcow2,size=20,bus=virtio,format=qcow2 \
     --os-variant detect=on,require=off \
     --network network=default,model=virtio \
     --graphics none \
     --console pty,target_type=serial \
     --location /var/lib/libvirt/images/ubuntu-26.04-live-server-amd64.iso,kernel=casper/vmlinuz,initrd=casper/initrd \
     --extra-args="console=ttyS0,115200n8 --- console=ttyS0,115200n8"

Beberapa flag di atas layak dijelaskan lebih detail. Flag --disk memakai bus=virtio, yaitu driver storage paravirtualized yang jauh lebih cepat dibanding emulasi controller IDE/SATA penuh, karena guest OS modern seperti Ubuntu Server sudah menyertakan driver virtio secara bawaan. Flag --location mengarah langsung ke path casper/vmlinuz dan casper/initrd di dalam ISO, yaitu struktur direktori khas installer berbasis casper yang dipakai Ubuntu live-server sejak beberapa rilis terakhir, alih-alih memakai --cdrom yang hanya mem-boot ISO apa adanya tanpa menyalurkan output instalasi ke serial console. Flag --extra-args berisi dua argumen kernel dipisah tanda tiga buah strip (pola khas image berbasis casper), di mana bagian sebelum tiga strip menjadi parameter installer dan bagian sesudahnya diteruskan ke proses live-boot itu sendiri; keduanya perlu diisi console=ttyS0,115200n8 agar seluruh tahap boot, bukan cuma sebagian, konsisten tampil di serial console.

Perhatikan bahwa perintah virt-install di atas dijalankan tanpa sudo, berbeda dari wget pada Bagian 28.3.1 yang tetap butuh sudo untuk menulis file ke direktori /var/lib/libvirt/images yang dimiliki root. Perbedaan ini bukan kebetulan. wget menulis file secara langsung ke filesystem sebagai user yang menjalankannya, sedangkan virt-install hanya mengirim permintaan lewat socket ke daemon virtqemud yang berjalan sebagai root, dan daemon itulah yang benar-benar membuat file vm-app01.qcow2 di storage pool. Selama user tergabung dalam group libvirt seperti pada Bagian 28.2.3, permintaan lewat socket ini sudah cukup diotorisasi tanpa perlu privilege root di sisi client sama sekali.

28.3.3 Menyelesaikan Instalasi Subiquity Lewat Serial Console

virt-install otomatis menyambungkan terminal saat ini ke console VM begitu proses boot dimulai, menampilkan installer Subiquity yang sama persis dengan yang sudah kita kenal dari Bagian 2.2, hanya saja kini tampil sebagai TUI (text user interface) di atas serial console, bukan layar virtual optical drive.

Langkah Praktik

1. Ikuti seluruh alur Subiquity persis seperti Bagian 2.2, mulai dari pemilihan bahasa, konfigurasi jaringan, partisi disk, sampai pembuatan akun user pertama.
2. Setelah instalasi selesai dan Subiquity menampilkan opsi reboot, tekan Ctrl+] untuk keluar dari sesi console tanpa mematikan VM, karena reboot otomatis dari installer akan langsung mem-boot sistem hasil instalasi, bukan kembali ke installer seperti risiko yang dijelaskan pada Bagian 2.4.
3. Sambungkan kembali ke console VM setelah beberapa saat untuk memastikan boot pertama berjalan mulus.

   virsh console vm-app01

Verifikasi dan Troubleshooting

• Login prompt standar Ubuntu Server yang muncul di console menandakan instalasi dan boot pertama berhasil sepenuhnya.
• Berbeda dari instalasi manual lewat virtual optical drive pada Bagian 2.4 yang mengharuskan kita melepas ISO secara manual agar VM tidak boot ulang ke installer, pendekatan --location di sini tidak pernah melekatkan ISO sebagai CD-ROM permanen pada VM sejak awal, sehingga masalah tersebut sama sekali tidak muncul di sini.
• Jika layar serial console tampak kosong sama sekali sejak awal boot, kemungkinan besar salah satu dari dua argumen console=ttyS0,115200n8 pada --extra-args tertinggal atau salah ketik. Hapus VM yang gagal lalu ulangi dari langkah 28.3.2.

  virsh destroy vm-app01
  virsh undefine vm-app01 --remove-all-storage

28.3.4 virt-manager sebagai GUI dari Komputer Client

Server produksi jarang memasang lingkungan desktop, tetapi Sysadmin tetap bisa mengelola VM secara visual lewat virt-manager, sebuah GUI yang dijalankan dari komputer client (laptop/desktop Sysadmin sendiri), bukan dipasang di server.

Langkah Praktik

1. Di komputer client berbasis Ubuntu/Debian, pasang virt-manager.

   sudo apt install virt-manager

2. Buka virt-manager, pilih File > Add Connection, lalu isi detail koneksi SSH ke server, memanfaatkan akses SSH key-based yang sudah dikonfigurasi sejak Bab 3.

   qemu+ssh://nama_user@alamat-ip-server/system

Verifikasi dan Troubleshooting

• Setelah koneksi berhasil, seluruh VM yang sudah dibuat lewat virt-install di server, termasuk vm-app01, langsung terlihat di daftar virt-manager, lengkap dengan grafik penggunaan CPU dan memory secara real-time.
• Koneksi qemu+ssh:// memanfaatkan SSH tunnel sepenuhnya, sehingga tidak perlu membuka port tambahan apa pun di firewall server selain port SSH yang memang sudah terbuka sejak Bab 3.
• Jika koneksi gagal dengan pesan terkait virsh atau polkit tidak ditemukan di sisi server, pastikan user yang dipakai login SSH memang sudah menjadi anggota group libvirt seperti pada Bagian 28.2.3.

28.4 Manajemen VM Sehari-hari dengan virsh

Setelah VM pertama berjalan, bagian ini membahas operasional harian yang paling sering dibutuhkan Sysadmin, mulai dari siklus hidup dasar hingga snapshot untuk rollback cepat.

28.4.1 Siklus Hidup VM

Langkah Praktik

1. Matikan VM secara graceful dan tunggu hingga statusnya benar-benar berubah.

   virsh shutdown vm-app01
   virsh list --all

2. Nyalakan kembali.

   virsh start vm-app01

Verifikasi dan Troubleshooting

• Catatan jujur soal risiko: virsh shutdown bergantung pada agen ACPI di dalam guest OS untuk merespons sinyal shutdown. Jika guest sedang hang atau tidak merespons sama sekali setelah beberapa saat, barulah virsh destroy menjadi opsi terakhir, persis seperti mencabut kabel power server fisik, dengan risiko yang sama pula.
• virsh undefine saja tidak menghapus file vm-app01.qcow2 di storage pool. Tambahkan flag --remove-all-storage jika memang berniat menghapus VM beserta seluruh data disknya secara permanen, dan pastikan sudah tidak ada data penting yang perlu dibackup terlebih dahulu, mengikuti prinsip yang sama seperti strategi backup pada Bab 23.

28.4.2 Autostart VM Saat Host Boot

Langkah Praktik

1. Aktifkan autostart agar vm-app01 ikut menyala otomatis setiap kali host Ubuntu Server reboot.

   virsh autostart vm-app01

Verifikasi dan Troubleshooting

• Konfirmasikan status autostart.

  virsh dominfo vm-app01 | grep Autostart

  Baris Autostart: enable menandakan konfigurasi sudah aktif.
• Untuk membatalkan autostart, gunakan virsh autostart vm-app01 --disable.

28.4.3 Melihat dan Mengubah Resource VM

Langkah Praktik

1. Lihat definisi lengkap VM dalam format XML, termasuk konfigurasi disk, network, dan CPU.

   virsh dumpxml vm-app01

2. Edit definisi VM secara langsung lewat editor default (mengikuti variable $EDITOR), berguna untuk konfigurasi lanjutan yang belum tersedia lewat flag virsh biasa.

   virsh edit vm-app01

3. Tambah jumlah vCPU dan RAM untuk boot berikutnya, tanpa mengubah konfigurasi yang sedang berjalan saat ini.

   virsh shutdown vm-app01
   virsh setvcpus vm-app01 4 --config
   virsh setmem vm-app01 4G --config
   virsh start vm-app01

Verifikasi dan Troubleshooting

• Konfirmasikan perubahan sudah diterapkan.

  virsh dominfo vm-app01

• Flag --config hanya mengubah definisi yang dipakai saat VM berikutnya kali dinyalakan, bukan kondisi yang sedang berjalan saat itu juga. Sebagian resource seperti CPU sebenarnya mendukung penyesuaian langsung tanpa restart lewat flag --live, tetapi tetap dibatasi oleh nilai maksimum yang sudah ditentukan sejak VM pertama kali dibuat, serta membutuhkan dukungan hotplug dari guest OS itu sendiri. Menambah resource melebihi kapasitas awal secara aman umumnya tetap memerlukan definisi ulang VM lewat virsh edit atau kombinasi --config --live sekaligus.
• Jangan pernah mengalokasikan total RAM seluruh VM melebihi RAM fisik host tanpa perhitungan matang. libvirt maupun KVM tidak mencegah overcommit memory secara default, dan host yang kehabisan memory fisik akan memicu OOM killer yang bisa mematikan proses VM secara tiba-tiba, bukan sekadar memperlambatnya.

28.4.4 Snapshot VM untuk Rollback Cepat

Snapshot menyimpan kondisi disk VM pada satu titik waktu tertentu, memungkinkan rollback cepat sebelum melakukan perubahan berisiko seperti upgrade aplikasi atau patch kernel guest, konsep yang serupa dengan snapshot LVM pada Bagian 7.2, hanya saja kini bekerja di level file disk virtual qcow2.

Langkah Praktik

1. Buat snapshot sebelum melakukan perubahan berisiko di dalam VM.

   virsh snapshot-create-as vm-app01 sebelum-upgrade "Kondisi sebelum upgrade paket"

2. Lihat daftar snapshot yang tersimpan.

   virsh snapshot-list vm-app01

3. Jika perubahan ternyata bermasalah, kembalikan VM ke kondisi snapshot.

   virsh snapshot-revert vm-app01 sebelum-upgrade

4. Hapus snapshot yang sudah tidak diperlukan agar tidak menumpuk dan membengkakkan ukuran file qcow2.

   virsh snapshot-delete vm-app01 sebelum-upgrade

Verifikasi dan Troubleshooting

• Snapshot lewat snapshot-create-as tanpa flag tambahan menghasilkan internal snapshot, tersimpan menyatu di dalam satu file qcow2 yang sama. Cara ini paling sederhana untuk kebutuhan rollback jangka pendek seperti uji coba upgrade, tetapi kurang cocok untuk strategi backup jangka panjang karena tetap bergantung pada satu file disk yang sama; VM sebaiknya dalam kondisi mati (shut off) saat snapshot dibuat untuk memastikan konsistensi filesystem di dalamnya.
• Untuk kebutuhan produksi yang lebih matang, misalnya snapshot terhadap VM yang sedang berjalan tanpa downtime, libvirt juga mendukung external snapshot yang memisahkan file disk baru dari base image lama, di luar cakupan dasar bab ini.
• Snapshot bukan pengganti backup. Snapshot tetap tersimpan di storage pool yang sama dengan VM aslinya, sehingga kegagalan disk fisik host tetap menghilangkan VM beserta seluruh snapshot-nya sekaligus. Kombinasikan tetap dengan strategi backup off-site yang akan dibahas pada Bab 40.

Sampai di sini, kita sudah memahami posisi KVM sebagai hypervisor berbasis kernel Linux, memasang stack KVM/QEMU/libvirt lengkap dengan daemon modularnya, membuat VM pertama secara headless lewat virt-install, hingga mengelola siklus hidup dan snapshot-nya lewat virsh. Virtualisasi penuh lewat KVM memberi isolasi paling kuat di antara seluruh pendekatan yang sudah kita bahas, tetapi harganya adalah overhead resource yang jauh lebih besar dibanding container. Bab 29 kembali ke pendekatan yang lebih ringan lewat LXD/Incus, yaitu system container yang memberi pengalaman mirip VM lengkap dengan init system dan multi-proses di dalamnya, namun tetap seringan container karena masih berbagi kernel dengan host, menempatkan diri tepat di tengah antara Docker yang sudah kita kuasai dan KVM yang baru saja kita pelajari.