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:

QEMU is a software emulator for a full computer; performances are far from the speed one could achieve running natively, but this allows running unmodified or experimental operating systems on the emulated hardware. It also allows emulating a different hardware architecture: for instance, an amd64 system can emulate an arm computer. QEMU is free software.
→ https://www.qemu.org/
Bochs adalah mesin virtual lain yang bebas, tapi itu hanya mengemulasi arsitektur x86 (i386 dan amd64).
VMWare is a proprietary virtual machine; being one of the oldest out there, it is also one of the most widely-known. It works on principles similar to QEMU. VMWare proposes advanced features such as snapshotting a running virtual machine.
→ https://www.vmware.com/
VirtualBox is a virtual machine that is mostly free software (some extra components are available under a proprietary license). Unfortunately it is in Debian's “contrib” section because it includes some precompiled files that cannot be rebuilt without a proprietary compiler and it currently only resides in Debian Unstable as Oracle's policies make it impossible to keep it secure in a Debian stable release (see #794466). While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some snapshotting and other interesting features.
→ https://www.virtualbox.org/

HARDWARE Virtualization support

Some computers might not have hardware virtualization support; when they do, it should be enabled in the BIOS.

To know if you have virtualization support enabled, you can check if the relevant flag is enabled with grep. If the following command for your processor returns some text, you already have virtualization support enabled:

For Intel processors you can execute grep vmx /proc/cpuinfo
For AMD processors you can execute grep svm /proc/cpuinfo

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.

Let's spend some time on terms. The hypervisor is the lowest layer, which runs directly on the hardware, even below the kernel. This hypervisor can split the rest of the software across several domains, which can be seen as so many virtual machines. One of these domains (the first one that gets started) is known as dom0, and has a special role, since only this domain can control the hypervisor and the execution of other domains. These other domains are known as domU. In other words, and from a user point of view, the dom0 matches the “host” of other virtualization systems, while a domU can be seen as a “guest”.

KULTUR Xen dan berbagai versi Linux

Xen ini awalnya dikembangkan sebagai seperangkat patch yang berada di luar pohon resmi, dan tidak terintegrasi ke kernel Linux. Pada saat yang sama, beberapa sistem virtualisasi mendatang (termasuk KVM) memerlukan beberapa fungsi generik terkait virtualisasi untuk memfasilitasi integrasi mereka, dan kernel Linux memperoleh set fungsi (dikenal sebagai antarmuka paravirt_ops atau pv_ops). Karena patch Xen menduplikasi beberapa fungsionalitas antar muka ini, mereka tidak bisa diterima secara resmi.

Xensource, the company behind Xen, therefore had to port Xen to this new framework, so that the Xen patches could be merged into the official Linux kernel. That meant a lot of code rewrite, and although Xensource soon had a working version based on the paravirt_ops interface, the patches were only progressively merged into the official kernel. The merge was completed in Linux 3.0.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Since Jessie is based on version 3.16 of the Linux kernel, the standard linux-image-686-pae and linux-image-amd64 packages include the necessary code, and the distribution-specific patching that was required for Squeeze and earlier versions of Debian is no more.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

BUDAYA Xen dan kernel bukan Linux

Xen requires modifications to all the operating systems one wants to run on it; not all kernels have the same level of maturity in this regard. Many are fully-functional, both as dom0 and domU: Linux 3.0 and later, NetBSD 4.0 and later, and OpenSolaris. Others only work as a domU. You can check the status of each operating system in the Xen wiki:

→ https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen

Namun, jika Xen dapat bergantung pada fungsi perangkat keras yang didedikasikan untuk virtualisasi (yang hanya hadir dalam prosesor yang lebih baru), bahkan sistem operasi tanpa modifikasi dapat berjalan sebagai domU (termasuk Windows).

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).
LEBIH JAUH Memasang sistem bukan-Debian di domU
Dalam hal non-Linux sistem, perlu hati-hati untuk mendefinisikan kernel yang mesti dipakai oleh domU, menggunakan opsi --kernel.
--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.
CATATAN Penyimpanan di domU
Seluruh hard disk dapat juga diekspor ke domU, maupun partisi, larik RAID, atau volume logis LVM yang sudah ada sebelumnya. Namun operasi ini tidak diotomatiskan oleh xen-create-image, jadi perlu menyunting berkas konfigurasi image Xen setelah penciptaan awal dengan xen-create-image.

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

[...]
General 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.

Before turning these virtual machines on, we need to define how they'll be accessed. They can of course be considered as isolated machines, only accessed through their system console, but this rarely matches the usage pattern. Most of the time, a domU will be considered as a remote server, and accessed only through a network. However, it would be quite inconvenient to add a network card for each domU; which is why Xen allows creating virtual interfaces that each domain can see and use in a standard way. Note that these cards, even though they're virtual, will only be useful once connected to a network, even a virtual one. Xen has several network models for that:

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

HATI-HATI Hanya satu domU per image!

While it is of course possible to have several domU systems running in parallel, they will all need to use their own image, since each domU is made to believe it runs on its own hardware (apart from the small slice of the kernel that talks to the hypervisor). In particular, it isn't possible for two domU systems running simultaneously to share storage space. If the domU systems are not run at the same time, it is, however, quite possible to reuse a single swap partition, or the partition hosting the /home filesystem.

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.

LEBIH JAUH Xen tingkat lanjut

Xen has many more features than we can describe in these few paragraphs. In particular, the system is very dynamic, and many parameters for one domain (such as the amount of allocated memory, the visible hard drives, the behavior of the task scheduler, and so on) can be adjusted even when that domain is running. A domU can even be migrated across servers without being shut down, and without losing its network connections! For all these advanced aspects, the primary source of information is the official Xen documentation.

→ https://xenproject.org/help/documentation/

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).

CATATAN Batas isolasi LXC

Container LXC tidak memberikan tingkat isolasi yang dicapai oleh emulator atau virtualizers yang lebih berat. Khususnya:

karena kernel dipakai bersama antara sistem host dan container, proses yang dibatasi ke container masih dapat mengakses pesan kernel, yang dapat menyebabkan kebocoran informasi jika pesan dipancarkan oleh kontainer;
untuk alasan yang sama, jika sebuah container terganggu dan kerentanan kernel dieksploitasi, container lain mungkin akan terpengaruh juga;
pada sistem berkas, kernel memeriksa izin menurut pengenal numerik untuk pengguna dan kelompok; pengidentifikasi ini dapat menetapkan pengguna dan kelompok yang berbeda tergantung pada container tersebut, yang harus diingat jika bagian-bagian yang dapat ditulisi dari sistem berkas dipakai bersama diantara wadah.

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.

LEBIH JAUH Virtualisasi masal

Karena LXC adalah sebuah sistem isolasi yang sangat ringan, itu dapat diadaptasi untuk hosting besar-besaran dari server-server virtual. Konfigurasi jaringan mungkin akan sedikit lebih lanjut dari apa yang dijelaskan di atas, tetapi konfigurasi "kaya" menggunakan antarmuka tap dan veth mestinya cukup untuk banyak kasus.

Mungkin juga masuk akal untuk berbagi bagian dari sistem berkas, seperti sub pohon /usr dan /lib, untuk menghindari duplikasi perangkat lunak yang mungkin perlu sama untuk beberapa container. Ini biasanya akan dicapai dengan entri lxc.mount.entry di berkas konfigurasi container. Efek samping yang menarik adalah bahwa proses kemudian akan menggunakan memori fisik yang lebih kecil, karena kernel mampu mendeteksi bahwa program dipakai bersama. Biaya marjinal dari satu container tambahan kemudian dikurangi menjadi ruang disk yang didedikasikan untuk data tertentu, dan beberapa proses tambahan yang harus dijadwalkan dan dikelola oleh kernel.

Kami tentu saja belum menguraikan semua pilihan yang tersedia; informasi lebih lengkap dapat diperoleh dari halaman manual lxc(7) dan lxc.container.conf(5) dan yang mereka acu.

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  
               --virt-type kvm           
               --name testkvm            
               --memory 1024             
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10  
               --cdrom /srv/isos/debian-10.2.0-amd64-netinst.iso  
               --network bridge=virbr0   
               --graphics vnc            
               --os-type linux           
               --os-variant debian10

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

	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.
	Karena KVM dikelola dengan cara yang sama seperti QEMU, `--virt-type kvm` mengizinkan menyatakan penggunaan KVM meskipun URL terlihat seperti QEMU.
	Opsi `--name` mendefinisikan nama (unik) untuk mesin virtual.
	The `--memory` option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.
	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.
	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`).
	`--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).
	`--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.
	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