Product SiteDocumentation Site

12.2. Virtualisasi

Virtualisasi adalah salah satu kemajuan yang paling besar dalam beberapa tahun terakhir komputasi. Istilah ini mencakup berbagai abstraksi dan teknik simulasi komputer virtual dengan tingkat kebebasan yang variabel pada perangkat keras sebenarnya. Satu server fisik kemudian dapat mewadahi beberapa sistem yang bekerja pada waktu yang sama dan dalam isolasi. Ada banyak aplikasi, dan sering diturunkan dari isolasi ini: lingkungan uji dengan berbagai konfigurasi misalnya, atau pemisahan layanan kebeberapa mesin virtual untuk keamanan.
Ada beberapa solusi virtualisasi, masing-masing dengan pro dan kontra. Buku ini akan fokus pada Xen, LXC, dan KVM, tetapi implementasi penting lain adalah sebagai berikut:

12.2.1. Xen

Xen adalah sebuah solusi "paravirtualization". Ini memperkenalkan lapisan abstraksi tipis, dinamai "hypervisor", antara perangkat keras dan sistem di atas; ini bekerja sebagai wasit yang mengendalikan akses ke perangkat keras dari mesin-mesin virtual. Namun, itu hanya menangani beberapa instruksi, sisanya dieksekusi secara langsung oleh perangkat keras atas nama sistem. Keuntungan utama adalah kinerja tidak menurun, dan sistem berjalan mendekati kecepatan native; kekurangannya adalah kernal dari sistem operasi yang ingin dipakai pada suatu hypervisor Xen perlu diadaptasi untuk berjalan pada Xen.
Mari kita bahas sejenak istilah-istilah. Hypervisor adalah lapisan terendah, yang berjalan langsung pada perangkat keras, bahkan di bawah kernel. Hypervisor ini dapat membagi sisa perangkat lunak di beberapa domain, yang dapat dilihat sebagai banyak mesin virtual. Salah satu domain (yang pertama dimulai) dikenal sebagai dom0, dan memiliki peran khusus, karena hanya domain ini dapat mengontrol hypervisor dan eksekusi domain lainnya. Domain lain tersebut dikenal sebagai domU. Dengan kata lain, dan dari sudut pandang pengguna, dom0 adalah "host" sistem virtualisasi lain, sementara domU dapat dilihat sebagai "tamu".
Menggunakan Xen di bawah Debian memerlukan tiga komponen:
  • The hypervisor itself. According to the available hardware, the appropriate package will be either xen-hypervisor-4.11-amd64, xen-hypervisor-4.11-armhf, or xen-hypervisor-4.11-arm64.
  • A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 4.19 version present in Buster.
  • Arsitektur i386 juga memerlukan pustaka standar dengan patch yang sesuai yang mengambil keuntungan dari Xen; ini ada dalam paket libc6-xen.
The hypervisor also brings xen-utils-4.11, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.
Setelah prapersyaratan ini diinstal, langkah berikutnya adalah untuk menguji perilaku dom0 sendiri; ini melibatkan reboot hypervisor dan kernel Xen. Sistem harus boot dalam cara standar, dengan beberapa tambahan pesan pada konsol selama langkah inisialisasi awal.
Sekarang adalah waktu untuk benar-benar menginstal sistem yang berguna pada sistem domU, menggunakan alat-alat dari xen-tools. Paket ini menyediakan perintah xen-create-image, yang mengotomatiskan sebagian besar tugas. Satu-satunya parameter wajib adalah --hostname, yang memberikan nama kepada domU; pilihan lainnya penting, tetapi mereka dapat disimpan dalam berkas konfigurasi /etc/xen-tools/xen-tools.conf dan ketidakhadiran mereka dari baris perintah tidak memicu kesalahan. Karena itu penting untuk memeriksa isi dari berkas ini sebelum membuat image, atau menggunakan parameter tambahan dalam pemanggilan xen-create-image. Parameter yang penting untuk diperhatikan adalah sebagai berikut:
  • --memory, untuk menentukan banyaknya RAM yang didedikasikan bagi sistem yang baru dibuat;
  • --size dan --swap, untuk menentukan ukuran "disk virtual" yang tersedia bagi domU;
  • --debootstrap-cmd, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as buster).
  • --dhcp menyatakan bahwa konfigurasi jaringan domU harus diperoleh dengan DHCP sedangkan --ip memungkinkan menentukan alamat IP statis.
  • Terakhir, metode penyimpanan harus dipilih untuk image yang akan dibuat (yang akan dipandang sebagai hard disk drive dari domU). Metode paling sederhana, sesuai dengan pilihan --dir, adalah untuk menciptakan satu berkas pada dom0 untuk setiap perangkat yang harus disediakan oleh domU. Untuk sistem yang menggunakan LVM, alternatifnya adalah dengan menggunakan pilihan --lvm, diikuti oleh nama grup volume; xen-create-image kemudian akan menciptakan volume logis baru di dalam grup, dan volume logis ini akan dibuat tersedia bagi domU sebagai hard disk drive.
Setelah pilihan ini dibuat, kita dapat membuat image untuk domU Xen kita nanti:
# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=buster --role=udev

[...]
eneral Information
--------------------
Hostname       :  testxen
Distribution   :  buster
Mirror         :  http://deb.debian.org/debian
Partitions     :  swap            512M  (swap)
                  /               2G    (ext4)
Image type     :  sparse
Memory size    :  256M
Kernel path    :  /boot/vmlinuz-4.19.0-5-amd64
Initrd path    :  /boot/initrd.img-4.19.0-5-amd64
[...]
Logfile produced at:
         /var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname        :  testxen
Distribution    :  buster
MAC Address     :  00:16:3E:0C:74:2F
IP Address(es)  :  dynamic
SSH Fingerprint :  SHA256:PuAGX4/4S07Xzh1u0Cl2tL04EL5udf9ajvvbufBrfvU (DSA)
SSH Fingerprint :  SHA256:ajFTX54eakzolyzmZku/ihq/BK6KYsz5MewJ98BM5co (ECDSA)
SSH Fingerprint :  SHA256:/sFov86b+rD/bRSJoHKbiMqzGFiwgZulEwpzsiw6aSc (ED25519)
SSH Fingerprint :  SHA256:/NJg/CcoVj+OLE/cL3yyJINStnla7YkHKe3/xEdVGqc (RSA)
Root Password   :  EwmQMHtywY9zsRBpqQuxZTb
Kita sekarang memiliki mesin virtual, tetapi saat ini tidak berjalan (dan karena itu hanya menggunakan ruang hard disk dom0). Tentu saja, kita dapat membuat lebih banyak image, mungkin dengan parameter yang berbeda.
Sebelum menyalakan mesin virtual ini, kita perlu menentukan bagaimana mereka akan diakses. Mereka tentu saja dapat dianggap mesin terisolasi, hanya diakses melalui konsol sistem mereka, tapi ini jarang cocok dengan pola penggunaan. Sebagian besar waktu, domU akan dianggap sebagai server jarak jauh, dan diakses hanya melalui jaringan. Namun, itu akan kurang nyaman untuk menambahkan kartu jaringan bagi setiap domU; itulah sebabnya Xen memungkinkan menciptakan antarmuka virtual, yang bisa dilihat dan digunakan dengan cara yang standar oleh setiap domain. Perhatikan bahwa kartu ini, meskipun mereka virtual, akan hanya menjadi berguna setelah terhubung ke jaringan, bahkan yang virtual. Xen memiliki beberapa model jaringan untuk itu:
  • Model yang paling sederhana adalah model bridge; semua kartu jaringan eth0 (baik dalam dom0 dan sistem domU) bersikap seolah-olah mereka secara langsung terhubung ke switch Ethernet.
  • Kemudian ada model routing, dimana dom0 berperilaku sebagai router yang berdiri di antara sistem domU dan jaringan eksternal (fisik).
  • Akhirnya, dalam model NAT, dom0 lagi-lagi berada di antara sistem domU dan sisa jaringan, tetapi sistem domU tidak langsung dapat diakses dari luar, dan lalu lintas berjalan melalui perjemahan alamat jaringan pada dom0.
Ketiga simpul jaringan ini melibatkan sejumlah antarmuka dengan nama-nama yang tidak biasa, seperti vif*, veth*, peth*, dan xenbr0. Hypervisor Xen mengatur mereka sesuai tata letak yang telah didefinisikan, di bawah kontrol perkakas pengguna. Karena NAT dan model routing hanya disesuaikan dengan kasus-kasus tertentu, kami hanya akan membahas model bridge.
The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils-4.11 package recommends it) to replace the existing eth0 entry:
auto xenbr0
iface xenbr0 inet dhcp
    bridge_ports eth0
    bridge_maxwait 0
After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the xl command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, /etc/xen/testxen.cfg). Here we have set it to 1024 (megabytes).
# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  1894     2     r-----      63.5
# xl create /etc/xen/testxen.cfg
Parsing config from /etc/xen/testxen.cfg
# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  1505     2     r-----     100.0
testxen                                     13  1024     0     --p---       0.0
Perhatikan bahwa domU testxen menggunakan memori nyata yang diambil dari RAM yang bila tidak demikian, tidak akan tersedia bagi dom0, bukan memori yang tersimulasi. Karena itu perlu hati-hati ketika membangun sebuah server yang dimaksudkan untuk mewadahi instansi Xen, untuk menyediakan RAM fisik yang sesuai.
Voilà! Mesin virtual kami memulai. Kita dapat mengaksesnya dengan satu dari dua mode. Cara yang biasa adalah untuk menyambung "jarak jauh" melalui jaringan, seperti kita akan menyambung ke mesin nyata; ini biasanya akan memerlukan mendirikan penyiapan server DHCP atau beberapa konfigurasi DNS. Cara lain, yang mungkin satu-satunya cara jika konfigurasi jaringan salah, adalah dengan menggunakan konsol hvc0, dengan perintah xl console:
# xl console testxen
[...]

Debian GNU/Linux 10 testxen hvc0

testxen login: 
Kita kemudian dapat membuka sesi, seperti yang orang akan lakukan jika duduk di papan ketik mesin virtual. Melepaskan dari konsol ini dicapai melalui kombinasi tombol Control+].
Setelah domU hidup, itu dapat digunakan seperti server lain (karena itu adalah sistem GNU/Linux juga). Namun, status mesin virtual memungkinkan beberapa fitur tambahan. Sebagai contoh, domU dapat diistirahatkan sementara kemudian dilanjutkan kembali, dengan perintah xl pause dan xl unpause. Perhatikan bahwa meskipun domU yang diistirahatkan tidak menggunakan prosesor apapun, memori yang dialokasikan masih digunakan. Mungkin menarik untuk mempertimbangkan perintah xl save dan xl restore: menyimpan domU membebaskan sumber daya yang sebelumnya digunakan oleh domU ini, termasuk RAM. Ketika dipulihkan (atau dilanjutkan kembali), domU bahkan tidak melihat apapun selain berlalunya waktu. Jika domU sedang berjalan ketika dom0 dimatikan, skrip yang dikemas secara otomatis menyimpan domU, dan memulihkannya pada boot berikutnya. Ini tentu saja akan melibatkan ketidaknyamanan standar yang timbul ketika menhibernasi komputer laptop misalnya; khususnya, jika domU disuspensi terlalu lama, koneksi jaringan mungkin berakhir. Perhatikan juga bahwa Xen sejauh ini tidak kompatibel dengan sebagian besar manajemen daya ACPI, yang menghalangi mensuspensi sistem host (dom0).
Menghentikan atau reboot domU dapat dilakukan baik dari dalam domU (dengan perintah shutdown) atau dari dom0, dengan xl shutdown atau xl reboot.

12.2.2. LXC

Meskipun hal ini digunakan untuk membangun "mesin virtual", LXC bukanlah, secara tegas, suatu sistem virtualisasi, tetapi sebuah sistem untuk mengisolasi kelompok proses dari satu sama lain meskipun mereka semua berjalan pada host yang sama. Ini memanfaatkan evolusi baru-baru ini pada kernel Linux, yang secara kolektif dikenal sebagai grup kendali, dimana set proses yang disebut "grup" yang berbeda memiliki pandangan yang berbeda atas aspek-aspek tertentu dari sistem secara keseluruhan. Paling menonjol di antara aspek-aspek ini adalah pengidentifikasi proses, konfigurasi jaringan, dan titik kait. Sebuah kelompok proses terisolasi tidak akan memiliki akses ke proses lain dalam sistem, dan aksesnya ke sistem berkas dapat dibatasi ke subset spesifik. Itu dapat juga memiliki antarmuka jaringan dan tabel routing sendiri, dan mungkin dikonfigurasi untuk hanya melihat subset dari perangkat yang tersedia yang ada pada sistem.
These features can be combined to isolate a whole process family starting from the init process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: LinuX Containers), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).
Karena kita berhadapan dengan isolasi dan virtualisasi yang tidak polos, menyiapkan container LXC lebih kompleks daripada hanya menjalankan debian-installer pada mesin virtual. Kami akan menjelaskan beberapa prasyarat, kemudian pergi ke konfigurasi jaringan; kami kemudian akan dapat benar-benar membuat sistem untuk dijalankan dalam container.

12.2.2.1. Langkah Pendahuluan

Paket lxc berisi alat-alat yang diperlukan untuk menjalankan LXC, dan karenanya harus dipasang.
LXC juga memerlukan sistem konfigurasi control group, yang berupa sistem berkas virtual untuk dipasang pada /sys/fs/cgroup. Karena Debian 8 beralih ke systemd, yang juga bergantung pada control group, hal ini sekarang dilakukan secara otomatis saat boot tanpa konfigurasi lebih lanjut.

12.2.2.2. Konfigurasi Jaringan

The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the bridge-utils package will be required.
The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:
auto eth0
iface eth0 inet dhcp
Mereka harus dinonaktifkan dan diganti dengan yang berikut:
#auto eth0
#iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
  bridge-ports eth0
Efek dari konfigurasi ini akan mirip dengan apa yang dapat diperoleh jika container itu adalah mesin yang terhubung ke jaringan fisik yang sama seperti host. Konfigurasi "jbridge" mengelola transit dari frame-frame Ethernet antara semua antarmuka yang dijembatani, yang mencakup fisik eth0 maupun antarmuka yang didefinisikan untuk container.
In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual tap interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.
Selain bridge-utils, konfigurasi "kaya" ini memerlukan paket vde2; berkas /etc/network/interfaces kemudian menjadi:
# Interface eth0 is unchanged
auto eth0
iface eth0 inet dhcp

# Virtual interface 
auto tap0
iface tap0 inet manual
  vde2-switch -t tap0

# Bridge for containers
auto br0
iface br0 inet static
  bridge-ports tap0
  address 10.0.0.1
  netmask 255.255.255.0
Jaringan kemudian dapat diatur baik secara statis dalam container, atau secara dinamis dengan server DHCP yang berjalan pada host. Server DHCP tersebut perlu dikonfigurasi untuk menjawab pertanyaan pada antarmuka br0.

12.2.2.3. Menyiapkan Sistem

Mari kita sekarang menyiapkan sistem berkas yang akan digunakan oleh container. Karena "mesin virtual" ini tidak akan berjalan secara langsung pada perangkat keras, beberapa tweak diperlukan bila dibandingkan dengan sistem berkas standar, terutama bila menyangkut kernel, perangkat, dan konsol. Untungnya, lxc menyertakan skrip yang kebanyakan mengotomatisasi konfigurasi ini. Sebagai contoh, perintah berikut (yang membutuhkan debootstrap dan rsync paket) akan menginstal sebuah container Debian:
root@mirwiz:~# lxc-create -n testlxc -t debian
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... 
Downloading debian minimal ...
I: Retrieving Release 
I: Retrieving Release.gpg 
[...]
Download complete.
Copying rootfs to /var/lib/lxc/testlxc/rootfs...
[...]
root@mirwiz:~# 
Perhatikan bahwa sistem berkas awalnya dibuat di /var/cache/lxc, kemudian dipindah ke direktori tujuannya. Hal ini memungkinkan membuat container-container identik secara jauh lebih cepat, karena kemudian hanya perlu menyalin.
Note that the Debian template creation script accepts an --arch option to specify the architecture of the system to be installed and a --release option if you want to install something else than the current stable release of Debian. You can also set the MIRROR environment variable to point to a local Debian mirror.
Sistem berkas yang baru dibuat sekarang berisi sistem Debian yang minimal, dan secara default container tidak memiliki antarmuka jaringan (selain loopback). Karena ini tidak benar-benar diinginkan, kita akan menyunting berkas konfigurasi container (/var/lib/lxc/testlxc/config) dan menambahkan beberapa entri lxc.network.*:
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.hwaddr = 4a:49:43:49:79:20
Entri ini berarti, masing-masing, bahwa suatu antarmuka virtual akan dibuat di dalam container; bahwa itu akan secara otomatis dihidupkan ketika container dimulai; itu akan secara otomatis terhubung ke bridge br0 pada host; dan bahwa alamat MAC-nya akan seperti yang ditentukan. Bila entri terakhir ini hilang atau dinonaktifkan, alamat MAC acak akan dibuat.
Entri lain yang berguna dalam berkas itu adalah pengaturan nama host:
lxc.uts.name = testlxc

12.2.2.4. Memulai Container

Now that our virtual machine image is ready, let's start the container with lxc-start --daemon --name=testlxc.
In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd. Now we can login:
root@mirwiz:~# lxc-console -n testlxc
Debian GNU/Linux 9 testlxc console	

testlxc login: root
Password: 
Linux testlxc 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@testlxc:~# ps auxwf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.2  56736  6608 ?        Ss   09:28   0:00 /sbin/init
root        32  0.0  0.1  46096  4680 ?        Ss   09:28   0:00 /lib/systemd/systemd-journald
root        75  0.0  0.1  67068  3328 console  Ss   09:28   0:00 /bin/login --
root        82  0.0  0.1  19812  3664 console  S    09:30   0:00  \_ -bash
root        88  0.0  0.1  38308  3176 console  R+   09:31   0:00      \_ ps auxwf
root        76  0.0  0.1  69956  5636 ?        Ss   09:28   0:00 /usr/sbin/sshd -D
root@testlxc:~# 
Kita sekarang berada di dalam container; akses kita ke proses dibatasi ke hanya yang dimulai dari container itu sendiri, dan akses kita ke sistem berkas juga dibatasi ke subset yang terdedikasi dari sistem berkas penuh (/var/lib/lxc/testlxc/rootfs). Kita dapat keluar dari konsol dengan Kontrol+a q.
Perhatikan bahwa kita menjalankan container sebagai proses latar belakang, terima kasih kepada pilihan --daemon dari lxc-start. Kita dapat menginterupsi container dengan perintah seperti lxc-stop --name=testlxc.
Paket lxc berisi skrip inisialisasi yang dapat secara otomatis memulai satu atau beberapa container ketika host mem-boot (bergantung pada lxc-autostart yang memulai container yang opsi lxc.start.auto diberi nilai 1). Kontrol urutan startup yang lebih baik dimungkinkan dengan lxc.start.order dan lxc.group: secara default, skrip inisialisasi pertama-tama memulai container yang merupakan bagian dari grup onboot dan kemudian container yang bukan bagian dari grup manapun. Dalam kedua kasus, urutan dalam grup ditentukan oleh opsi lxc.start.order.

12.2.3. Virtualisasi dengan KVM

KVM, kependekan dari Kernel-based Virtual Machine, adalah pertama dan terutama sebuah modul kernel yang menyediakan sebagian besar infrastruktur yang dapat digunakan oleh virtualizer, tetapi bukan virtualizer itu sendiri. Kontrol aktual untuk virtualisasi ditangani oleh sebuah aplikasi berbasis QEMU. Jangan khawatir jika bagian ini menyebutkan perintah qemu-*: itu masih tentang KVM.
Tidak seperti sistem virtualisasi lain, KVM digabungkan ke kernel Linux sejak dari awal. Para pengembangnya memilih untuk mengambil keuntungan dari set instruksi prosesor yang didedikasikan untuk virtualisasi (Intel-VT dan AMD-V), yang menjaga KVM ringan, elegan, dan tidak boros sumber daya. Kekurangannya, tentu saja, adalah bahwa KVM tidak bekerja pada sebarang komputer tetapi hanya pada yang memiliki prosesor yang sesuai. Untuk komputer berbasis x86, Anda dapat memastikan bahwa Anda memiliki prosesor seperti itu dengan mencari "vmx" atau "svm" di bendera CPU yang tercantum dalam /proc/cpuinfo.
Dengan Red Hat secara aktif mendukung perkembangannya, KVM kurang lebih telah menjadi acuan untuk virtualisasi Linux.

12.2.3.1. Langkah Pendahuluan

Tidak seperti alat-alat semacam VirtualBox, KVM itu sendiri tidak menyertakan antarmuka pengguna untuk membuat dan mengelola mesin virtual. Paket qemu-kvm hanya menyediakan program yang bisa memulai sebuah mesin virtual, serta skrip inisialisasi yang memuat modul-modul kernel yang sesuai.
Untungnya, Red Hat juga menyediakan satu set alat lain untuk mengatasi masalah itu, dengan mengembangkan perpustakaan libvirt dan alat-alat manajer mesin virtual terkait. Libvirt memungkinkan mengelola mesin virtual dalam cara yang seragam, secara independen dari sistem virtualisasi yang terlibat di balik layar (saat ini mendukung QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare, dan UML). virtual-manager adalah sebuah antarmuka grafis yang menggunakan libvirt untuk membuat dan mengelola mesin virtual.
We first install the required packages, with apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system provides the libvirtd daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. libvirt-clients provides the virsh command-line tool, which allows controlling the libvirtd-managed machines.
Paket virtinst menyediakan virt-install, yang memungkinkan membuat mesin virtual dari baris perintah. Terakhir, virt-viewer memungkinkan mengakses sebuah konsol grafis VM.

12.2.3.2. Konfigurasi Jaringan

Sama seperti Xen dan LXC, konfigurasi jaringan yang paling sering melibatkan bridge yang mengelompokkan antarmuka jaringan mesin virtual (lihat Bagian 12.2.2.2, “Konfigurasi Jaringan”).
Sebagai alternatif, dan dalam konfigurasi default yang disediakan oleh KVM, mesin virtual diberikan alamat pribadi (di kisaran 192.168.122.0/24), dan NAT diatur sehingga VM dapat mengakses jaringan luar.
Sisa bagian ini mengasumsikan bahwa host memiliki antarmuka fisik eth0 dan bridge br0, dan bahwa yang terdahulu terhubung ke yang terakhir.

12.2.3.3. Instalasi dengan virt-install

Membuat mesin virtual sangat mirip dengan menginstal sistem normal, kecuali bahwa karakteristik mesin virtual dijelaskan dalam baris perintah yang tampaknya tak berujung.
Secara praktis, ini berarti kita akan menggunakan installer Debian, dengan mem-boot mesin virtual pada drive DVD-ROM virtual yang memetakan ke image DVD Debian yang tersimpan di sistem host. VM akan mengekspor konsol grafisnya lewat protokol VNC (lihat Bagian 9.2.2, “Memakai Desktop Grafis Jarak Jauh” untuk rincian), yang akan memungkinkan kita untuk mengontrol proses instalasi.
Pertama kita perlu memberitahu libvirtd di mana tempat menyimpan image disk, kecuali bila lokasi default (/var/lib/libvirt/images/) baik-baik saja.
root@mirwiz:~# mkdir /srv/kvm
root@mirwiz:~# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

root@mirwiz:~# 
Mari kita sekarang mulai proses instalasi untuk mesin virtual, dan melihat lebih dekat pada pilihan-pilihan virt-install yang paling penting. Perintah ini mendaftarkan mesin virtual dan parameternya di libvirtd, kemudian memulainya sehingga instalasi dapat dilanjutkan.
# virt-install --connect qemu:///system  1
               --virt-type kvm           2
               --name testkvm            3
               --memory 1024             4
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10  5
               --cdrom /srv/isos/debian-10.2.0-amd64-netinst.iso  6
               --network bridge=virbr0   7
               --graphics vnc            8
               --os-type linux           9
               --os-variant debian10

Starting install...
Allocating 'testkvm.qcow'             |  10 GB     00:00

1

Opsi --connect menyatakan"hypervisor" yang akan dipakai. Bentuknya adalah URL yang memuat sistem virtualisasi (xen://, qemu://, lxc://, openvz://, vbox://, dan seterusnya) dan mesin yang harus menjadi host VM (ini dapat dibiarkan kosong dalam kasus hosting lokal). Selain itu, dan dalam kasus QEMU/KVM, setiap pengguna dapat mengelola mesin virtual yang bekerja dengan izin terbatas, dan path URL memungkinkan membedakan mesin "sistem" (/system) dari (/session) yang lain.

2

Karena KVM dikelola dengan cara yang sama seperti QEMU, --virt-type kvm mengizinkan menyatakan penggunaan KVM meskipun URL terlihat seperti QEMU.

3

Opsi --name mendefinisikan nama (unik) untuk mesin virtual.

4

The --memory option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.

5

The --disk specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the size parameter. The format parameter allows choosing among several ways of storing the image file. The default format (qcow2) allows starting with a small file that only grows when the virtual machine starts actually using space.

6

Opsi --cdrom digunakan untuk menunjukkan di mana menemukan disk optik yang digunakan untuk instalasi. Path bisa berupa path lokal untuk berkas ISO, URL tempat berkas dapat diperoleh, atau perangkat berkas dari drive CD-ROM fisik (yaitu /dev/cdrom).

7

--network menyatakan bagaimana kartu jaringan virtual mengintegrasi dalam konfigurasi jaringan host. Perilaku default (yang secara eksplisit kita paksa dalam contoh kita) adalah mengintegrasikannya ke dalam jaringan bridge apapun yang sudah ada. Jika bridge seperti itu tidak ada, mesin virtual hanya akan mencapai jaringan fisik melalui NAT, sehingga mendapat alamat di subnet pribadi (192.168.122.0/24).

8

--graphics vnc states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see Bagian 9.2.1.3, “Menciptakan Tunnel Terenkripsi dengan Penerusan Port”). Alternatively, --graphics vnc,listen=0.0.0.0 can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.

9

Pilihan --os-type dan --os-variant memungkinkan mengoptimalkan beberapa parameter mesin virtual, berdasarkan fitur yang dikenal dari sistem operasi yang disebutkan di sana.
Pada titik ini, mesin virtual sedang berjalan, dan kita perlu terhubung ke konsol grafis untuk melanjutkan dengan proses instalasi. Jika operasi sebelumnya berjalan dari lingkungan desktop grafis, hubungan ini harus secara otomatis dimulai. Jika tidak, atau jika kita beroperasi jarak jauh, virt-viewer dapat dijalankan dari setiap lingkungan grafis untuk membuka konsol grafis (perhatikan bahwa kata sandi root dari host remote diminta dua kali karena operasi memerlukan 2 koneksi SSH):
$ virt-viewer --connect qemu+ssh://root@server/system testkvm
root@server's password: 
root@server's password: 
Ketika proses instalasi berakhir, mesin virtual dijalankan ulang, sekarang siap untuk digunakan.

12.2.3.4. Mengelola Mesin dengan virsh

Sekarang setelah instalasi selesai, mari kita lihat bagaimana menangani mesin virtual yang tersedia. Hal pertama yang dicoba adalah untuk bertanya ke libvirtd daftar mesin virtual yang dikelolanya:
# virsh -c qemu:///system list --all
 Id Name                 State
----------------------------------
  8 testkvm              shut off
Mari kita mulai jalankan mesin virtual uji kita:
# virsh -c qemu:///system start testkvm
Domain testkvm started
Kita sekarang bisa mendapatkan petunjuk koneksi untuk konsol grafis (tampilan VNC yang dikembalikan dapat diberikan sebagai parameter ke vncviewer):
# virsh -c qemu:///system vncdisplay testkvm
127.0.0.1:0
Sub perintah virsh lain yang tersedia meliputi:
  • reboot untuk memulai jalankan lagi sebuah mesin virtual;
  • shutdown untuk memicu suatu shutdown yang bersih;
  • destroy, untuk menghentikannya secara brutal;
  • suspend untuk mengistirahatkannya;
  • resume untuk melanjutkan dari istirahat;
  • autostart untuk mengaktifkan (atau menonaktifkan, dengan pilihan --disable) memulai mesin virtual secara otomatis ketika host mulai;
  • undefine untuk menghapus semua jejak mesin virtual dari libvirtd.
Semua sub perintah ini mengambil sebuah identifier mesin virtual sebagai parameter.

12.2.3.5. Instalasi sistem berbasis RPM dalam Debian dengan yum

Jika mesin virtual dimaksudkan untuk menjalankan Debian (atau salah satu turunannya), sistem dapat diinisialisasi dengan debootstrap, seperti dijelaskan di atas. Tetapi jika mesin virtual diinstal dengan sistem berbasis RPM (seperti Fedora, CentOS, atau Scientific Linux), penyiapan akan perlu dilakukan menggunakan utilitas yum (tersedia dalam paket dengan nama yang sama).
Prosedur tersebut perlu memakai rpm untuk mengekstrak set awal berkas, termasuk terutama berkas konfigurasi yum, dan kemudian memanggil yum untuk mengekstrak kumpulan paket sisanya. Tapi karena kita memanggil yum dari luar chroot, kita perlu membuat beberapa perubahan sementara. Dalam contoh di bawah ini, chroot target adalah /srv/centos.
# rootdir="/srv/centos"
# mkdir -p "$rootdir" /etc/rpm
# echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath
# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-6.1810.2.el7.centos.x86_64.rpm
# rpm --nodeps --root "$rootdir" -i centos-release-7-6.1810.2.el7.centos.x86_64.rpm
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
warning: centos-release-7-6.1810.2.el7.centos.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
# sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo
# yum --assumeyes --installroot $rootdir groupinstall core
[...]
# sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo