Virsh Adalah: Perintah Pengelola Mesin Virtual KVM Linux

Menjalankan beberapa mesin virtual di satu komputer pribadi terasa cukup mudah. Anda membuka jendela VirtualBox atau VMware Workstation, memilih mesin yang diinginkan, lalu menekan tombol Start. Seluruh kondisinya terlihat di satu layar.

Situasinya berubah begitu mesin-mesin itu pindah ke server. Server tidak punya monitor, dan satu-satunya pintu masuk adalah SSH. Tidak ada tombol Start yang bisa ditekan. Yang tersedia hanya prompt teks, sementara Anda tetap harus menyalakan mesin nomor tiga, menambah memorinya, lalu memastikan mesin nomor lima benar-benar mati.

Di sinilah virsh bekerja. Virsh adalah program baris perintah yang menjadi antarmuka utama untuk mengelola mesin virtual di Linux, dipakai persis di tempat tombol Start tidak pernah ada.

Virsh Adalah Klien Baris Perintah untuk Libvirt

Nama virsh merupakan singkatan dari virtualization shell. Ia bukan hypervisor, bukan pula pembuat mesin virtual. Tugasnya lebih sempit: menerjemahkan perintah yang Anda ketik menjadi panggilan ke libvirt.

Libvirt sendiri adalah pustaka dan kumpulan layanan yang menyimpan definisi setiap mesin virtual, menjalankannya, serta menyediakan API yang stabil. Pustaka open source ini berlisensi GNU Lesser General Public License. Versi hulu terbarunya saat artikel ini ditulis adalah libvirt 12.7.0, dirilis 1 September 2026.

Hubungan keduanya menjelaskan satu hal yang sering disalahpahami saat orang bertanya apa itu virsh: ia bukan alat khusus KVM. Dokumentasi resminya menyebut libvirt mendukung Xen, QEMU, KVM, LXC, OpenVZ, VirtualBox, dan VMware ESX. Perintah yang sama karena itu bisa menyetir hypervisor berbeda, hanya dengan mengganti alamat sambungannya.

Satu istilah perlu diperkenalkan lebih dulu karena muncul di hampir semua pesan galat. Libvirt menyebut satu mesin virtual sebagai domain. Jadi ketika terminal membalas error: failed to get domain 'web01', yang dimaksud adalah mesin virtual bernama web01, bukan alamat situs seperti example.com.

Siapa yang Memakai Virsh: Pemilik Host, Bukan Penyewa VPS

Virsh berjalan di mesin yang menjalankan hypervisor, bukan di dalam mesin virtual yang dihasilkannya. Posisi inilah yang menentukan relevansinya untuk Anda.

Bila Anda menyewa VPS berbasis KVM, Anda berada di sisi tamu. Hypervisor yang membuat VPS itu milik penyedia, dan letaknya satu lapis di bawah jangkauan Anda. Memasang virsh di dalam VPS lalu menjalankan virsh list --all akan menampilkan daftar kosong, karena memang tidak ada mesin virtual yang didefinisikan di sana.

Yang benar-benar memakainya adalah pihak yang memiliki mesin fisiknya:

1. Pemilik server fisik: perusahaan atau perorangan yang menyewa dedicated server, lalu membelahnya sendiri menjadi beberapa mesin virtual.
2. Pengelola homelab: praktisi yang menjalankan beberapa sistem operasi di satu komputer di rumah, untuk belajar atau menguji konfigurasi.
3. Tim infrastruktur: pengelola Proxmox, oVirt, atau OpenStack, yang seluruhnya memakai libvirt di lapisan bawah.

Syarat perangkat kerasnya tidak bisa ditawar. Prosesor harus mendukung ekstensi virtualisasi, ditandai flag vmx untuk Intel atau svm untuk AMD di /proc/cpuinfo, dan berkas perangkat /dev/kvm harus tersedia.

Menjalankan hypervisor di dalam mesin virtual disebut virtualisasi bersarang (nested virtualization), dan ini hanya berfungsi bila penyedia sengaja meneruskan ekstensi virtualisasi CPU ke instance Anda. Bila flag vmx atau svm tidak muncul di /proc/cpuinfo, tidak ada konfigurasi di dalam VPS Indonesia mana pun yang bisa memunculkannya.

KVM, QEMU, Libvirt, dan Virsh: Siapa Mengerjakan Apa

Empat nama ini sering dipakai bergantian di forum, padahal pekerjaannya berbeda. Memisahkannya sekali di awal menghemat waktu saat membaca pesan galat.

1. KVM (Kernel-based Virtual Machine): modul di dalam kernel Linux yang membuka akses ke ekstensi virtualisasi milik prosesor. KVM tidak punya antarmuka sendiri dan tidak bisa dipanggil langsung.
2. QEMU: proses di ruang pengguna yang meniru perangkat keras — disk, kartu jaringan, kartu grafis. Satu mesin virtual yang menyala berarti satu proses QEMU di host.
3. Libvirt: lapisan pengelola. Ia menyimpan definisi mesin virtual, menyalakan QEMU dengan argumen yang benar, mengatur jaringan virtual, dan menyediakan API yang tidak berubah meski hypervisornya diganti.
4. Virsh: klien yang Anda ketik. Ia mengirim permintaan ke libvirt, lalu mencetak jawabannya.

Urutannya bisa dibaca dari atas ke bawah: Anda mengetik di virsh, virsh berbicara ke libvirt, libvirt menyalakan QEMU, dan QEMU meminjam tenaga dari KVM di kernel.

Virsh berada di lapisan teratas, di bawahnya libvirt, QEMU, lalu KVM di kernel, dan perangkat keras sebagai alas.

Konsekuensi praktisnya cukup besar. Karena virsh hanya berbicara dengan libvirt, satu-satunya cara mengubah perilaku mesin virtual adalah mengubah apa yang tersimpan di libvirt. Argumen QEMU yang disunting manual di luar libvirt akan hilang begitu mesin virtual dinyalakan ulang.

Memasang Virsh dan Menyalakan Layanan yang Benar di Distro Anda

Nama paket yang membawa berkas /usr/bin/virsh berbeda antar keluarga distro Linux. Di Debian dan Ubuntu, paketnya libvirt-clients. Di keluarga Red Hat seperti AlmaLinux, Rocky Linux, dan RHEL, namanya libvirt-client tanpa huruf s.

Langkah #1: Pasang paket klien dan daemonnya

Pada Debian atau Ubuntu, pasang klien beserta daemonnya:

sudo apt update
sudo apt install libvirt-clients \
  libvirt-daemon-system qemu-kvm

Pada AlmaLinux, Rocky Linux, atau RHEL, paketnya disediakan sekaligus:

sudo dnf install libvirt qemu-kvm virt-install

Paket klien itu juga membawa virt-host-validate dan virt-xml-validate.

Langkah #2: Nyalakan layanan yang tepat untuk distro Anda

Nama layanannya tidak seragam, dan inilah sumber kebingungan yang paling sering. Libvirt sedang berpindah dari satu daemon besar bernama libvirtd ke beberapa daemon kecil terpisah seperti virtqemud, virtnetworkd, dan virtstoraged.

Isi tabel di atas bukan perkiraan. Daftar berkas paket libvirt-daemon-system untuk Ubuntu 24.04 hanya memuat libvirtd.service, libvirtd.socket, dan turunannya, tanpa satu pun unit virtqemud. Sebaliknya, Red Hat menyatakan daemon monolitik libvirtd sudah berstatus deprecated di RHEL 9.

Anda sering tidak perlu menyalakannya sama sekali. Systemd memakai aktivasi soket, sehingga daemon hidup sendiri saat sambungan pertama masuk. Karena itu perintah di tabel menyalakan unit .socket, bukan .service.

Langkah #3: Pastikan host memang sanggup menjalankan mesin virtual

Sebelum membuat mesin virtual pertama, jalankan pemeriksa bawaannya:

sudo virt-host-validate

Dua baris paling menentukan adalah QEMU: Checking for hardware virtualization dan QEMU: Checking if device /dev/kvm is accessible, dan keduanya harus berstatus PASS. Status FAIL berketerangan Only emulated CPUs are available berarti virtualisasi perangkat keras belum aktif di BIOS atau tidak tersedia. Mesin virtual masih bisa jalan, tetapi seluruh instruksi ditiru perangkat lunak sehingga kecepatannya turun jauh.

Versi yang terpasang bisa diperiksa dengan virsh -v. Ubuntu 24.04 LTS membawa libvirt 10.0.0, sementara AlmaLinux 9 dan 10 membawa 11.10.0.

Kenapa virsh list Anda Kosong: Soal URI, Bukan Soal Izin

Ini pertanyaan paling sering di seluruh topik virsh, dan jawabannya hampir tidak pernah berkaitan dengan izin berkas. Penyebabnya ada pada URI koneksi, alamat yang menentukan libvirt mana yang sedang Anda ajak bicara. Libvirt memisahkan dua wilayah yang berbeda sama sekali:

1. qemu:///system: wilayah sistem. Definisi tersimpan di /etc/libvirt/qemu/, prosesnya dijalankan daemon dengan hak istimewa, dan mesin virtual di sini bisa memakai jaringan bertipe bridge serta perangkat PCI.
2. qemu:///session: wilayah pribadi tiap pengguna. Definisi dan berkas disknya tersimpan di direktori home, prosesnya berjalan sebagai pengguna itu sendiri, dan jaringan bertipe bridge maupun perangkat PCI tidak tersedia.

Ketika Anda menjalankan virsh tanpa menyebut URI, libvirt akan menebak. Dijalankan dengan sudo, tebakannya biasanya jatuh ke qemu:///system; dijalankan sebagai pengguna biasa, ia jatuh ke qemu:///session. Mesin virtual yang dibuat lewat sudo karena itu tidak terlihat saat Anda memanggil virsh list --all tanpa sudo. Daftarnya kosong bukan karena datanya hilang, melainkan karena Anda sedang melihat ke lemari yang berbeda.

qemu:///system menyimpan VM di /etc/libvirt/qemu dan terlihat di virsh list, qemu:///session di home dan sering kosong.

Untuk membuktikannya, tanyakan langsung ke virsh:

virsh uri

Perintah itu mencetak URI yang sedang aktif. Bila jawabannya qemu:///session padahal mesin virtual Anda dibuat sebagai root, penyebabnya sudah ketemu. Sambungan bisa dipaksa dengan -c:

virsh -c qemu:///system list --all

Ada tiga cara membuatnya permanen, dan sebaiknya dipilih salah satu saja:

1. Masuk ke grup libvirt dengan sudo usermod -aG libvirt $USER, lalu keluar dan masuk kembali ke sesi agar keanggotaan berlaku.
2. Isi berkas konfigurasi pengguna ~/.config/libvirt/libvirt.conf dengan baris uri_default = "qemu:///system".
3. Tetapkan variabel lingkungan LIBVIRT_DEFAULT_URI, yang menimpa berkas konfigurasi dan menghentikan libvirt menebak-nebak.

Cara ketiga cocok ditulis di ~/.bashrc agar berlaku di semua sesi:

export LIBVIRT_DEFAULT_URI="qemu:///system"

Perhatikan jumlah garis miringnya. Alamat yang benar memakai tiga garis miring, seperti qemu:///system. Menulis qemu://system dengan dua garis miring membuat kata system dibaca sebagai nama host jarak jauh. Galatnya pun berbunyi Cannot read CA certificate, pesan yang sama sekali tidak mengarah ke penyebabnya.

URI yang sama bisa dibawa melewati SSH untuk mengelola server lain:

virsh -c qemu+ssh://root@10.10.10.5/system \
  list --all

Dua Belas Perintah Virsh untuk Pekerjaan Sehari-hari

Man page resmi virsh memuat 282 subperintah dalam 15 kelompok, dan 117 di antaranya khusus menangani domain. Angka itu menjelaskan kenapa menghafal daftar perintah bukan cara belajar yang masuk akal.

Pendekatan yang lebih hemat adalah menguasai dua belas perintah berikut lebih dulu, karena kedua belasnya menutup hampir seluruh pekerjaan harian pengelola host.

Keadaan domain virsh berpindah lewat start, shutdown, suspend, dan resume; destroy memutus paksa ke mati.

Dua kebiasaan kecil membuatnya lebih nyaman dipakai.

Pertama, virsh punya mode interaktif. Mengetik virsh tanpa argumen membuka shell tersendiri, sehingga kata virsh tidak perlu diulang di setiap baris. Perintah virsh help mencetak seluruh daftar subperintah, sedangkan virsh help domain mempersempitnya ke kelompok domain saja. Autostart pun dimatikan lagi dengan menambahkan --disable pada perintah yang sama.

Kedua, beberapa perintah bisa digabung dalam satu argumen dengan pemisah titik koma. Bentuk ini berguna saat menulis skrip Bash atau tugas terjadwal:

virsh "shutdown web01; shutdown db01; list"

Perlu diperhatikan bahwa shutdown, setmem, dan setvcpus bekerja asinkron: ketiganya kembali ke prompt sebelum pekerjaannya selesai, sehingga status akhirnya harus diperiksa terpisah lewat virsh domstate.

Shutdown, Destroy, dan Undefine: Tiga Nasib yang Berbeda

Tiga kata kerja ini terdengar mirip dan sering tertukar, padahal akibatnya berbeda jauh. Salah memilih di antara ketiganya adalah penyebab kehilangan data yang paling sering menimpa pengguna baru libvirt.

shutdown meminta dengan sopan. Libvirt mengirim sinyal ke sistem operasi tamu, lalu menunggu tamu itu mematikan layanannya sendiri. Man page resminya menyatakan tidak ada jaminan perintah ini berhasil, dan lamanya bergantung pada layanan yang harus dihentikan. Tamu yang macet total akan mengabaikannya.

destroy memutus paksa. Man page menggambarkannya sebagai tindakan yang setara mencabut kabel listrik dari mesin fisik, tanpa memberi kesempatan tamu bereaksi. Nama perintah ini menyesatkan, karena destroy tidak menghapus apa pun. Definisi domainnya tetap ada, berkas disknya utuh, dan domain bisa dinyalakan lagi dengan virsh start. Tambahkan --graceful bila Anda ingin virsh menyerah dengan galat ketimbang memaksa dengan SIGKILL.

undefine yang benar-benar menghapus. Perintah inilah yang membuang definisi domain dari libvirt. Perilakunya tergantung status: domain yang sedang mati langsung kehilangan definisinya, sedangkan domain yang menyala hanya berubah menjadi domain sementara (transient) dan baru lenyap setelah dimatikan.

Urutan yang aman untuk membuang satu mesin virtual beserta disknya karena itu ada dua langkah:

Di virsh, shutdown dan destroy menyisakan definisi dan berkas disk; undefine menghapus definisinya.

virsh destroy web01
virsh undefine web01 --remove-all-storage

Tanpa --remove-all-storage, berkas disk tertinggal di storage pool dan diam-diam memakan kapasitas. Sebaliknya, opsi itu berbahaya bila disknya masih dipakai domain lain, jadi periksa dulu dengan virsh domblklist.

Bila undefine gagal pada domain yang sudah mati, penyebabnya hampir selalu metadata yang tertinggal. Domain yang masih memiliki snapshot membutuhkan --snapshots-metadata, sedangkan domain yang pernah disimpan dengan managedsave membutuhkan --managed-save.

Menyunting Spesifikasi VM lewat XML Domain

Seluruh spesifikasi mesin virtual — jumlah vCPU, kapasitas memori, disk, kartu jaringan — tersimpan sebagai berkas XML. Berkas inilah sumber kebenarannya, dan virsh dumpxml cara membacanya. Untuk mengubahnya, tersedia perintah yang lebih nyaman:

virsh edit web01

Perintah itu membuka XML domain di editor yang ditunjuk variabel $EDITOR, memvalidasi hasil suntingan, lalu menyimpannya kembali. Di balik layar ia mengambil XML dengan dumpxml --inactive, membuka editor, lalu mendaftarkan ulang dengan define.

Konsekuensinya penting diingat. Perubahan lewat virsh edit berlaku pada boot berikutnya, bukan seketika, sehingga domain yang menyala tidak berubah sampai dimatikan dan dinyalakan lagi.

Berkas XML itu juga bisa dipindahkan antar host. Simpan dengan virsh dumpxml web01 > web01.xml, salin, lalu daftarkan di host tujuan dengan virsh define web01.xml. Berkas disknya tetap harus disalin terpisah, karena XML hanya memuat penunjuk ke lokasinya.

Untuk perubahan yang berlaku langsung, virsh menyediakan pasangan --live dan --config. Opsi --live mengubah domain yang sedang berjalan, --config mengubah definisi tersimpan untuk boot berikutnya, dan keduanya boleh dipakai bersamaan:

virsh setvcpus web01 4 --config
virsh setmem web01 4GiB --config --live

Kapasitas disk adalah pengecualian: ia tidak diubah lewat XML, melainkan dengan virsh blockresize. Perintah itu memperbesar berkas qcow2 di sisi host, sedangkan partisi di dalam tamu tetap harus diperluas sendiri setelahnya.

Satu jebakan menunggu di perintah kedua. Angka pada setmem dibaca sebagai kibibyte bila ditulis tanpa sufiks. Menulis virsh setmem web01 4096 berarti meminta memori 4 MiB, bukan 4 GB, dan mesin virtual akan tercekik seketika. Selalu tulis sufiksnya: GiB, MiB, atau KiB. Jumlah vCPU terbatas pada nilai maksimum di definisi domain, sehingga menambah CPU melewati batas itu menuntut penyuntingan XML lebih dulu.

Hindari menamai domain dengan angka. Man page resmi memperingatkan bahwa domain seperti itu hanya bisa dipanggil lewat domain id, karena virsh membaca argumen berupa angka sebagai id, bukan nama.

Masuk ke Konsol VM dan Cara Keluar darinya

Setelah mesin virtual menyala, Anda butuh cara masuk ke dalamnya lewat konsol serial tamu:

virsh console web01

Pertanyaan yang lebih sering muncul justru bukan cara masuk, melainkan cara keluar. Menekan Ctrl + C tidak melepaskan Anda, karena sinyal itu diteruskan ke dalam tamu. Urutan pelolosnya adalah Ctrl + ], mengikuti kebiasaan telnet, dan bisa diganti lewat opsi -e.

Konsol yang tetap diam setelah tersambung bukan berarti gagal. Penyebab paling umum adalah konsol serial yang belum diaktifkan di tamu. Pada tamu Linux modern, layanan serial-getty@ttyS0.service perlu dinyalakan lebih dulu dari dalam.

Dua perintah lain melengkapinya. Yang pertama menunjukkan alamat konsol grafis:

virsh vncdisplay web01

Keluarannya berupa alamat dan nomor display yang bisa dibuka dengan klien VNC. Cara ini berguna untuk tamu Windows atau tamu yang macet saat booting, ketika konsol teks belum tersedia.

Yang kedua mencari alamat IP tamu agar bisa di-SSH:

virsh domifaddr web01 --source agent

Opsi --source menentukan dari mana alamat itu diambil, dan pilihannya menentukan keberhasilan. Nilai bawaan lease membaca catatan sewa DHCP milik jaringan virtual libvirt, sehingga gagal bila tamu memakai IP statis atau jaringan bridge. Nilai agent bertanya langsung ke dalam tamu dan paling akurat, tetapi mensyaratkan paket qemu-guest-agent terpasang di sana. Nilai arp membaca tabel ARP host, dan hanya bekerja bila tamu pernah mengirim lalu lintas. Seluruh sewa yang tercatat di satu jaringan virtual bisa dilihat sekaligus dengan virsh net-dhcp-leases default.

Snapshot, Jaringan, dan Storage: Tiga Kelompok Perintah Virsh Berikutnya

Setelah domain, tiga kelompok inilah yang paling cepat dibutuhkan. Pola penamaannya konsisten dan mudah ditebak setelah terbiasa.

Snapshot

Snapshot merekam kondisi mesin virtual pada satu titik waktu, sehingga Anda bisa kembali ke sana bila sebuah perubahan berujung kacau:

virsh snapshot-create-as web01 sebelum-upgrade \
  "Sebelum upgrade PHP 8.4" --disk-only --atomic
virsh snapshot-list web01
virsh snapshot-revert web01 sebelum-upgrade

Dua catatan perlu diperhatikan. Man page menyebut snapshot-revert sebagai tindakan merusak: seluruh perubahan sejak snapshot dibuat hilang tanpa konfirmasi. Selain itu, Red Hat menyatakan snapshot internal sudah deprecated di RHEL 9, sedangkan snapshot eksternal didukung penuh sejak RHEL 9.4. Jenis snapshot yang sudah ada bisa diperiksa dengan virsh snapshot-dumpxml web01 sebelum-upgrade | grep external.

Snapshot bukan pengganti backup. Keduanya berada di disk fisik yang sama dengan mesin virtualnya, sehingga kerusakan disk host menghabiskan snapshot bersama datanya.

Jaringan virtual

Mesin virtual yang tidak mendapat IP sering disebabkan jaringan default yang mati:

virsh net-list --all
virsh net-start default
virsh net-autostart default

Perintah kedua menyalakannya sekali, perintah ketiga memastikannya menyala otomatis setiap host melakukan boot. Tanpa perintah ketiga, masalah yang sama kembali setelah host di-restart.

Storage pool

Storage pool adalah tempat libvirt menyimpan berkas disk, dan isinya diperiksa dengan dua perintah:

virsh pool-list --all
virsh vol-list --pool default

Keduanya berguna saat mencari berkas disk yatim yang tertinggal karena domainnya dihapus tanpa --remove-all-storage.

Kelemahan Virsh dan Hal yang Perlu Anda Pertimbangkan

Virsh bukan alat yang cocok untuk semua situasi, dan beberapa kelemahannya bersifat mendasar.

1. Tidak nyaman untuk membuat mesin virtual dari nol. Virsh mendefinisikan domain dari berkas XML yang sudah ada, bukan menyusunnya untuk Anda. Pembuatan mesin virtual baru lebih masuk akal dikerjakan dengan virt-install, alat terpisah dari proyek virt-manager.
2. Tidak ada konfirmasi untuk perintah merusak. virsh destroy dan virsh undefine langsung dieksekusi tanpa pertanyaan. Satu kesalahan ketik pada nama VM sudah cukup untuk mematikan mesin yang salah.
3. Pesan galatnya berbicara dalam istilah libvirt. Kalimat seperti Requested operation is not valid baru bisa ditindaklanjuti setelah Anda paham konsep domain, URI, dan status.
4. Keluarannya berupa tabel untuk mata manusia. Memakainya di dalam skrip berarti mengurai teks yang formatnya bisa berubah antar versi. Sebagian perintah menyediakan --name atau keluaran JSON, tetapi tidak semuanya.
5. Permukaan perintahnya sangat besar. Dengan 282 subperintah, menebak nama perintah yang tepat sering lebih lambat daripada membuka man page.
6. Sebagian perintah dicabut per distro. Kelompok virsh iface-* untuk mengelola antarmuka jaringan host, misalnya, sudah tidak didukung di RHEL 9.

Pertimbangan praktisnya sederhana. Untuk host yang dikelola dari jauh lewat SSH dan pekerjaan yang perlu diotomasi, virsh adalah pilihan yang tepat. Untuk pemasangan sistem operasi pertama kali atau pemakaian sehari-hari di komputer desktop, virt-manager jauh lebih hemat waktu. Keduanya membaca definisi yang sama, jadi dipakai bergantian pun tidak menimbulkan masalah.

Pertanyaan Seputar Virsh

Kenapa muncul virsh: command not found padahal libvirt sudah dipasang?

Karena paket daemon dan paket klien terpisah, sehingga memasang libvirt-daemon-system saja tidak membawa berkas /usr/bin/virsh. Di Debian dan Ubuntu, berkas itu ada di paket libvirt-clients; di keluarga Red Hat, di libvirt-client.

Kenapa muncul failed to connect to the hypervisor: Permission denied?

Karena pengguna Anda belum berhak membuka soket UNIX milik libvirt. Perbaikan paling lazim adalah menambahkan diri ke grup yang ditunjuk direktif unix_sock_group di /etc/libvirt/libvirtd.conf, umumnya bernama libvirt, lalu keluar dan masuk kembali ke sesi. Bila galatnya justru berbunyi Cannot read CA certificate, periksa jumlah garis miring pada URI Anda.

Kenapa virsh meminta please enter your authentication name?

Karena libvirt meminta autentikasi lewat mekanisme SASL, bukan lewat izin soket biasa. Ini terjadi saat menyambung ke daemon jarak jauh melalui TCP, atau saat /etc/libvirt/libvirtd.conf disetel auth_unix_rw = "sasl". Untuk pemakaian lokal, izin grup lebih sederhana; untuk jarak jauh, qemu+ssh:// lebih mudah diatur.

Apakah virsh bisa mengelola server lain dari jauh?

Bisa, dan inilah salah satu kekuatan utamanya. Bentuk URI-nya qemu+ssh://pengguna@host/system, dan seluruh lalu lintasnya melewati SSH sehingga tidak ada port tambahan yang perlu dibuka. Libvirt juga menyediakan sambungan TCP dan TLS, tetapi keduanya menuntut penyiapan sertifikat. Pemindahan domain yang sedang menyala dari satu host ke host lain ditangani perintah tersendiri, virsh migrate.

Apa bedanya virsh dengan virt-install dan virt-manager?

Ketiganya bekerja di atas libvirt yang sama, tetapi berasal dari proyek berbeda. Virsh datang bersama libvirt dan mengelola mesin virtual yang sudah ada. virt-install dan virt-manager berasal dari proyek virt-manager: yang pertama membuat mesin virtual baru dari baris perintah, yang kedua menyediakan antarmuka grafis. Proyek itu juga membawa virt-clone, virt-viewer, dan virt-xml.

Apakah virsh bisa dipakai di Windows atau macOS?

Tidak sebagai host KVM, karena KVM adalah modul kernel Linux. Yang bisa dilakukan adalah memasang klien libvirt di Windows atau macOS, lalu menyambung ke host Linux memakai qemu+ssh://. Cara yang lebih umum adalah menjalankan virsh langsung di host lewat sesi SSH biasa.

Bisakah virsh dipakai untuk hypervisor selain KVM?

Bisa. Dokumentasi resmi libvirt menyebut dukungan untuk Xen, QEMU, KVM, LXC, OpenVZ, VirtualBox, dan VMware ESX. Yang berubah hanya URI koneksinya, misalnya xen:///system atau lxc:///system untuk container Linux. Perlu diperhatikan bahwa kelengkapan tiap driver berbeda, sehingga tidak semua subperintah tersedia di semua hypervisor.

Kesimpulan

Virsh adalah klien baris perintah libvirt yang dipakai di sisi host, bukan di dalam mesin virtual yang dihasilkannya. Nilai terbesarnya terletak pada satu antarmuka yang sama untuk beberapa hypervisor, bekerja melalui SSH, dan mudah dimasukkan ke dalam skrip. Harganya adalah permukaan perintah yang sangat luas dan tidak adanya jaring pengaman untuk perintah yang merusak.

Bila Anda memiliki host KVM sendiri dan mengelolanya dari jauh, mulailah dari dua belas perintah di artikel ini. Pastikan URI koneksinya tepat, dan biasakan membedakan shutdown, destroy, serta undefine sebelum menyentuh mesin produksi. Bila kebutuhan Anda hanya memasang satu sistem operasi di komputer desktop, antarmuka grafis lebih hemat waktu. Semoga artikel ini membantu.