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:
  • Hypervisor itu sendiri. Tergantung dari perangkat keras yang tersedia, paket yang tepat yang menyediakan xen-hypervisor adalah xen-hypervisor-4.14-amd64, xen-hypervisor-4.14-armhf, atau xen-hypervisor-4.14-arm64.
  • Sebuah kernel yang berjalan pada hypervisor itu. Setiap kernel yang lebih baru daripada 3.0 bisa, termasuk versi 5.10 yang ada dalam Bullseye.
  • Arsitektur i386 juga memerlukan pustaka standar dengan patch yang sesuai yang mengambil keuntungan dari Xen; ini ada dalam paket libc6-xen.
Hypervisor juga membawa xen-utils-4.14, yang berisi alat untuk mengontrol hypervisor dari dom0. Ini pada gilirannya membawa pustaka standar yang sesuai. Selama instalasi semua itu, skrip konfigurasi juga membuat entri baru di menu bootloader GRUB, untuk memulai kernel yang dipilih di Xen dom0. Perhatikan, bagaimanapun, bahwa entri ini biasanya tidak diatur untuk menjadi yang pertama dalam daftar, tetapi akan dipilih secara baku.
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, untuk menyatakan perintah debootstrap mana yang dipakai. Bakunya adalah debootstrap bila debootstrap dan cdebootstrap dipasang. Dalam hal ini, opsi --dist akan juga sering kali digunakan (dengan nama distribusi seperti misalnya bullseye).
  • --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=bullseye --role=udev

General Information
--------------------
Hostname       :  testxen
Distribution   :  bullseye
Mirror         :  http://deb.debian.org/debian
Partitions     :  swap            512M  (swap)
                  /               2G    (ext4)
Image type     :  sparse
Memory size    :  256M
Bootloader     :  pygrub

[...]
Logfile produced at:
	 /var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname        :  testxen
Distribution    :  bullseye
MAC Address     :  00:16:3E:C2:07:EE
IP Address(es)  :  dynamic
SSH Fingerprint :  SHA256:K+0QjpGzZOacLZ3jX4gBwp0mCESt5ceN5HCJZSKWS1A (DSA)
SSH Fingerprint :  SHA256:9PnovvGRuTw6dUcEVzzPKTITO0+3Ki1Gs7wu4ke+4co (ECDSA)
SSH Fingerprint :  SHA256:X5z84raKBajUkWBQA6MVuanV1OcV2YIeD0NoCLLo90k (ED25519)
SSH Fingerprint :  SHA256:VXu6l4tsrCoRsXOqAwvgt57sMRj2qArEbOzHeydvV34 (RSA)
Root Password   :  FS7CUxsY3xkusv7EkbT9yae
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.
Konfigurasi standar dari paket Xen tidak mengubah konfigurasi sistem jaringan seluruh sistem. Namun, daemon xend dikonfigurasi untuk mengintegrasikan antarmuka jaringan virtual ke jaringan bridge apa pun yang sudah ada sebelumnya (dengan xenbr0 didahulukan jika ada beberapa bridge). Kita karena itu harus menyiapkan sebuah bridge di /etc/network/interfaces (yang memerlukan instalasi paket bridge-utils, itulah sebabnya paket xen-utils merekomendasikannya) untuk menggantikan entri eth0 yang sudah ada (berhati-hatilah untuk memakai nama perangkat jaringan yang benar):
auto xenbr0
iface xenbr0 inet dhcp
    bridge_ports eth0
    bridge_maxwait 0
Setelah reboot untuk memastikan bridge secara otomatis dibuat, kita sekarang dapat memulai domU dengan perkakas kendali Xen, khususnya perintah xl. Perintah ini memungkinkan manipulasi yang berbeda pada domain, termasuk menampilkan daftar mereka dan, memulai/menghentikan mereka. Anda mungkin perlu menaikkan memori default dengan menyunting memori variabel dari berkas konfigurasi (dalam kasus ini, /etc/xen/testxen.cfg). Di sini kami telah mengaturnya ke 1024 (megabyte).
# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  3918     2     r-----      35.1
# 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  2757     2     r-----      45.2
testxen                                      3  1024     1     r-----       1.3
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 11 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.
Sebagian besar sub perintah xl mengharapkan satu atau lebih argumen, sering kali nama domU. Argumen ini dijelaskan dengan baik dalam halaman manual xl(1).

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.
Fitur ini dapat dikombinasikan untuk mengisolasi keluarga seluruh proses yang dimulai dari proses init, dan kumpulan yang dihasilkan terlihat sangat mirip dengan mesin virtual. Nama resmi untuk penyiapan seperti itu adalah "container" (maka moniker LXC: LinuX Containers), tapi perbedaan yang cukup penting dengan mesin virtual "nyata" seperti yang disediakan oleh Xen atau KVM adalah bahwa tidak ada kernel kedua; container menggunakan kernel yang sama dengan sistem host. Ini memiliki pro dan kontra: keuntungannya termasuk kinerja yang sangat baik karena total ketiadaan overhead, dan fakta bahwa kernel memiliki visi global dari semua proses yang berjalan pada sistem, sehingga penjadwalan dapat menjadi lebih efisien daripada jika dua kernel independen yang menjadwalkan set tugas yang berbeda. Paling utama di antara ketidaknyamanan adalah ketidakmungkinan untuk menjalankan sebuah kernel yang berbeda dalam container (apakah versi Linux yang berbeda atau sistem operasi yang berbeda sama sekali).
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

Tujuan dari memasang LXC adalah untuk menyiapkan mesin virtual; walaupun tentu saja kita bisa menjaga mereka terisolasi dari jaringan, dan hanya berkomunikasi dengan mereka melalui sistem berkas, penggunaan umumnya memberikan setidaknya akses jaringan minimum ke container. Dalam kasus yang tipikal, masing-masing akan mendapatkan antarmuka jaringan virtual, yang terhubung ke jaringan nyata melalui sebuah bridge. Antarmuka virtual ini dapat dipasang langsung ke antarmuka jaringan fisik host (dalam hal ini container langsung berada pada jaringan) atau ke antarmuka virtual lain yang didefinisikan pada host (dan host kemudian dapat menyaring atau mengarahkan lalu lintas). Dalam kedua kasus, paket bridge-utils akan diperlukan.
Kasus sederhana ini hanya sekadar menyunting /etc/network/interfaces, memindah konfigurasi untuk antarmuka fisik (misalnya, eth0 atau enp1s0) ke antarmuka bridge (biasanya br0) dan mengonfigurasi tautan antara mereka. Misalnya, jika berkas konfigurasi antarmuka jaringan pada awalnya berisi entri seperti berikut:
auto eth0
iface eth0 inet dhcp
Mereka harus dinonaktifkan dan diganti dengan yang berikut:
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.
Dalam kasus-kasus yang mana konfigurasi ini tidak dapat digunakan (misalnya, jika tidak ada alamat IP publik dapat diberikan ke container), antarmuka virtual tap akan dibuat dan terhubung dengan bridge. Topologi jaringan kemudian menjadi suatu host dengan kartu jaringan kedua yang ditancapkan ke sebuah switch yang terpisah, dengan container juga dicolokkan ke switch itu. Host kemudian mesti bertindak sebagai sebuah gateway untuk container jika mereka dimaksudkan untuk berkomunikasi dengan dunia luar.
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 paket debootstrap dan rsync) akan memasang sebuah container Debian:
# 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...
[...]
# 
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.
Perhatikan bahwa skrip penciptaan templat Debian menerima pilihan --arch untuk menentukan arsitektur sistem yang akan diinstal dan pilihan --release jika Anda ingin menginstal sesuatu yang lain daripada rilis stabil Debian. Anda juga dapat menetapkan variabel lingkungan MIRROR untuk menunjuk ke mirror Debian lokal.
Paket lxc selanjutnya membuat antarmuka bridge lxcbr0, yang secara baku digunakan oleh semua kontainer yang baru dibuat melalui /etc/lxc/default.conf dan layanan lxc-net:
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
Entri ini berarti, masing-masing, bahwa antarmuka virtual akan dibuat di setiap kontainer baru; bahwa itu akan secara otomatis dibawa ketika wadah tersebut dimulai; dan itu akan secara otomatis terhubung ke bridge lxcbr0 pada host. Anda akan menemukan pengaturan ini dalam konfigurasi kontainer yang dibuat (/var/lib/lxc/testlxc/config), di mana juga alamat MAC perangkat akan ditentukan dalam lxc.net.0.hwaddr. Jika 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
Sistem berkas yang baru dibuat sekarang berisi sistem Debian minimal dan sebuah antarmuka jaringan.

12.2.2.4. Memulai Container

Sekarang setelah image mesin virtual kita sudah siap, mari kita jalankan container dengan lxc-start --daemon --name=testlxc.
Dalam rilis LXC setelah 2.0.8, sandi root tidak ditetapkan secara baku. Kita dapat mengaturnya dengan menjalankan lxc-attach -n testlxc kata_sandi jika kita mau. Sekarang kita bisa login dengan:
# lxc-console -n testlxc
Connected to tty 1
Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself

Debian GNU/Linux 11 testlxc tty1

testlxc login: root
Password: 
Linux testlxc 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) 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.
Last login: Wed Mar  9 01:45:21 UTC 2022 on console
root@testlxc:~# ps auxwf
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.2  18964 11464 ?        Ss   01:36   0:00 /sbin/init
root          45  0.0  0.2  31940 10396 ?        Ss   01:37   0:00 /lib/systemd/systemd-journald
root          71  0.0  0.1  99800  5724 ?        Ssl  01:37   0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid [..]
root          97  0.0  0.1  13276  6980 ?        Ss   01:37   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root         160  0.0  0.0   6276  3928 pts/0    Ss   01:46   0:00 /bin/login -p --
root         169  0.0  0.0   7100  3824 pts/0    S    01:51   0:00  \_ -bash
root         172  0.0  0.0   9672  3348 pts/0    R+   01:51   0:00      \_ ps auxwf
root         164  0.0  0.0   5416  2128 pts/1    Ss+  01:49   0:00 /sbin/agetty -o -p -- \u --noclear [...]
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 kami menjalankan kontainer sebagai proses latar belakang, berkat lxc-start memulai menggunakan opsi --daemon secara baku. Kita dapat menginterupsi kontainer dengan perintah sepertilxc-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 pustaka 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). virt-manager adalah sebuah antarmuka grafis yang menggunakan libvirt untuk membuat dan mengelola mesin virtual.
Kita pertama kali menginstal paket-paket yang diperlukan, dengan apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system menyediakan daemon libvirtd, yang memungkinkan manajemen mesin virtual (berpotensi remote) yang berjalan pada host, dan memulai VM yang diperlukan ketika host boot. libvirt-clients menyediakan alat bantu baris perintah virsh, yang memungkinkan mengendalikan mesin-mesin yang dikelola oleh libvirtd.
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 baku (/var/lib/libvirt/images/) baik-baik saja.
# mkdir /srv/kvm
# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

# 
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 2048             4
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10  5
               --cdrom /srv/isos/debian-11.2.0-amd64-netinst.iso  6
               --network bridge=virbr0   7
               --graphics vnc            8
               --os-type linux           9
               --os-variant debiantesting


Starting install...
Allocating 'testkvm.qcow'

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

Opsi --memory memungkinkan menentukan banyaknya RAM (dalam MB) yang dialokasikan untuk mesin virtual.

5

--disk menyatakan lokasi berkas image yang mewakili hard disk mesin virtual; berkas itu dibuat, kecuali sudah ada, dengan ukuran (dalam GB) yang ditentukan oleh parameter size. Parameter format memungkinkan memilih antara beberapa cara untuk menyimpan berkas image. Format default (qcow2) memungkinkan mulai dengan berkas kecil yang hanya tumbuh ketika mesin virtual mulai benar-benar menggunakan ruang.

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).
Konfigurasi jaringan baku, yang berisi definisi untuk antarmuka bridge virbr0, dapat disunting menggunakan virsh net-edit default dan dimulai melalui default virsh net-start jika belum dilakukan secara otomatis selama sistem mulai.

8

--graphics vnc menyatakan bahwa konsol grafis harus dibuat tersedia menggunakan VNC. Perilaku default untuk server VNC terkait adalah hanya mendengarkan pada antarmuka lokal; jika klien VNC akan dijalankan pada host yang berbeda, membuat koneksi akan memerlukan pengaturan tunnel SSH (lihat Bagian 9.2.1.4, “Menciptakan Tunnel Terenkripsi dengan Penerusan Port”). Sebagai alternatif, --graphics vnc,listen=0.0.0.0 dapat digunakan sehingga server VNC dapat diakses dari semua antarmuka; perhatikan bahwa jika Anda melakukannya, Anda benar-benar harus merancang firewall Anda sesuai dengan itu.

9

Pilihan --os-type dan --os-variant memungkinkan mengoptimalkan beberapa parameter mesin virtual, berdasarkan fitur yang dikenal dari sistem operasi yang disebutkan di sana.
Daftar lengkap jenis OS dapat ditampilkan menggunakan perintah osinfo-query os dari paket libosinfo-bin.
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: 
Menyambung ke sesi pemasang memakai virt-viewer

Gambar 12.1. Menyambung ke sesi pemasang memakai virt-viewer

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.