7,540
edits
Changes
KVM
,→Manage machines
=AlapfogalmakAlapok=
A hypervisor or virtual machine monitor (VMM) is computer software, firmware or hardware that creates and runs virtual machines. A computer on which a hypervisor runs one or more virtual machines is called a host machine, and each virtual machine is called a guest machine. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Multiple instances of a variety of operating systems may share the virtualized hardware resources
* '''Type 1 hypervisor''': hypervisors run directly on the system hardware – A “bare metal” embedded hypervisor,* '''Type 2 hypervisor''': hypervisors run on a host operating system that provides virtualization services, such as I/O device support and memory management.
:[[File:ClipCapIt-180622-175904.PNG]]
==Virtualizációs eszközök==
===KVM===
Type: 1 hypervisor 1 (bear metal)
Kernel-based Virtual Machine (KVM) is a virtualization infrastructure for the Linux kernel that turns it into a hypervisor. It was merged into the Linux kernel mainline in kernel version 2.6.20, which was released on February 5, 2007.KVM requires a processor with hardware virtualization extensions.
:[[File:ClipCapIt-231129-142926.PNG]][[File:ClipCapIt-231129-143903.PNG]]
A "KVM fölött egy QEMU doboz" ábrázolás valójában azt jelenti, hogy a KVM és a QEMU együttműködik a virtualizált gépek futtatásához. A KVM kezeli a hardveres virtualizációt, és a QEMU használható a gépek emulálására, ha a hardveres virtualizáció nem érhető el, vagy például akkor, ha a virtualizált gépek más architektúrát vagy operációs rendszert emulálnak.
KVM a hardvervirtualizációra épít, és lehetővé teszi, hogy a virtualizált gépek közvetlenül a processzor hardveres virtualizációs támogatását használják ki. Ezáltal a KVM nagyon hatékony és közel valós idejű teljesítményt nyújt.
===Qemu===
Type: hypervisor 2 (software based)
QEMU is performing hardware virtualization (not to be confused with hardware-assisted virtualization), such as disk, network, VGA, PCI, USB, serial/parallel ports, etc. It is flexible in that it can emulate CPUs via dynamic binary translation (DBT) allowing code written for a given processor to be executed on another (i.e ARM on x86, or PPC on ARM). Though QEMU can run on its own and emulate all of the virtual machine’s resources, as all the emulation is performed in software it is extremely slow.
:[[File:ClipCapIt-231129-143339.PNG]]
A QEMU egy szoftveres emulator, amely lehetővé teszi a gépek teljes emulációját. Ez a módszer általában lassabb és erőforrásigényesebb, mint a KVM, mivel az operációs rendszer és az alkalmazások teljes emulációját végzi el.
===KVM vs qemu===
As previously mentioned, QEMU can run independently, but due to the emulation being performed entirely in software it is extremely slow. To overcome this, QEMU allows you to use KVM as an accelerator so that the physical CPU virtualization extensions can be used. So to conclude: QEMU is a type 2 hypervisor that runs within user space and performs virtual hardware emulation, whereas KVM is a type 1 hypervisor that runs in kernel space, that allows a user space program access to the hardware virtualization features of various processors.[3]
Finally, It is also worth mentioning a little history, which in my opinion has led to some of the confusion around KVM/QEMU. Previously KVM was a fork of QEMU, named qemu-kvm. However, this has now been merged into QEMU upstream and the fork has now been discontinued. Or in other words, as per Linux KVM,
===Virtual Box===
Type: hypervisor 2 (software based)
Developed by Oracle, VirtualBox is an open source virtualization software that is a type 2 hypervisor. That means it runs on a conventional OS just as other computer programs do and abstracts guest operating systems from the host OS. Type 2 hypervisors like VirtualBox are sometimes called “hosted” hypervisors because they rely on the host machine’s pre-existing OS to manage calls to CPU, memory, storage, and network resources.
<br>
==Virtualizációt kezelő eszközök==
===libvirt===
libvirt is an open-source API, daemon and management tool for managing platform virtualization.[3] It can be used to manage KVM, Xen, VMware ESX, QEMU and other virtualization technologies. These APIs are widely used in the orchestration layer of hypervisors in the development of a cloud-based solution.
:[[File:ClipCapIt-180622-180343.PNG|400px]]
===Gnome boxes===
GNOME Boxes is an application of the GNOME Desktop Environment, used to access virtual systems. Boxes uses the QEMU, KVM, and libvirt virtualization technologies. Lényegében ez egy virsh grafikus kliens, pont olyan mint a 'Virtual Machine Manager' manager.
<br>
<br>
=Manage machineswith virsh=
==List machine==
<br>
=Manage networks=
===List all===
Bridge: virbr0
</pre>
===List IP addresses of the guest===
<pre>
# virsh domifaddr mg0
Name MAC address Protocol Address
-------------------------------------------------------------------------------
vnet0 52:54:00:09:36:24 ipv4 192.168.123.36/24
vnet1 52:54:00:98:d3:28 ipv4 192.168.42.36/24
</pre>
===Add new network===
disk size: 192M
</pre>
{{note|The '''qemu-img''' command line tool is used for formatting various file systems used by Xen and KVM. qemu-img should be used for formatting guest images, additional storage devices and network storage. qemu-img options and usages are listed below.}}
<hr>
<br>
<br>
==Mount host folder on guest==
A host ugyan azon mappáját mount-olhatjuk több guest-en is, ami az alapját képezheti kommunikációnak, vagy perzisztens tárként használhatjuk. A host egy adott mappáját '''9p''' (Plan 9 folder sharing over Virtio - I/O virtualization framework) típusú fájlrendszeren ajánlja ki a KVM a guest-nek.
{{warning|A 9p-vel felcsatolt host mappákat nem lehet felcsatolni a guest-en futó docker konténerbe. A olyan perzisztens közös meghajtóra van szükségünk, ami több guest-en futó docker konténer is elér, akkor NFS fájlrendszert használjunk}}
A host egy mappáját a guest-en két lépésben lehet felcsatolni. Első lépésben a host egy mappáját fel kell venni a guest domain.xml fájljába mint felcsatolható mappa. Ha ez megvan, akkor a guest-re be kell lépni, és ott a már elérhető 9p típusú meghajtót fel tudjuk csatolni.
Nem tudok róla, hogy lenne direkt virsh parancs ami egy új mappa megosztást hozzá tudna adni egy domain-hez. Ezért első lépésként exportálni kell a domain xml leíróját, majd abba xmlstarlet-el be fogjuk szúrni a megfelelő file megosztó szekciót, az új xml-ből újra fogjuk definiálni a domain-t, majd újra fogjuk indítani a virtuális gépet, hogy a változtatások érvényre jussanak.
A domain.xml-ben a device szekcióban ezt kell elhelyezni:
<source lang="xml">
<filesystem type="mount" accessmode="mapped">
<source dir="/home/adam/Projects/DockerCourse/portainer/data"/>
<target dir="portainerdata"/>
</filesystem>
</source>
A target tartalma nem a guest-en a mappa ahova fel akarjuk csatolni a host mappáját. Ez csupán a meghajtó neve, ahogy a guest-en elérhető lesz a host mappája, a mount parancsban majd ezzel a névvel kel hivatkozni a megosztásra.
Az alábbi példában '''mg0'''-nak hívják a virtuális gépet, ahova fel akarjuk csatolni a ''''/home/adam/Projects/DockerCourse/portainer/data'''' mappát. A megosztás neve: portainerdata
<source lang="sh">
#!/bin/bash
virsh dumpxml mg0 > mg0.xml
xmlstarlet ed --inplace --subnode "/domain/devices" --type elem -n filesystem -v "" mg0.xml
xmlstarlet ed -O --inplace --insert "/domain/devices/filesystem" --type attr -n type -v mount mg0.xml
xmlstarlet ed -O --inplace --insert "/domain/devices/filesystem" --type attr -n accessmode -v mapped mg0.xml
xmlstarlet ed --inplace --subnode "/domain/devices/filesystem" --type elem -n 'source' -v "" mg0.xml
xmlstarlet ed -O --inplace --insert "/domain/devices/filesystem/source" --type attr -n dir -v '/home/adam/Projects/DockerCourse/portainer/data' mg0.xml
xmlstarlet ed --inplace --subnode "/domain/devices/filesystem" --type elem -n target -v "" mg0.xml
xmlstarlet ed -O --inplace --insert "/domain/devices/filesystem/target" --type attr -n dir -v portainerdata mg0.xml
virsh define mg0.xml
ssh ... sudo mkdir /var/lib/boot2docker/portainerdata
ssh ... sudo chmod 777 /var/lib/boot2docker/profile
ssh ... "echo 'sudo mount -a -t 9p -o trans=virtio,rw,version=9p2000.L portainerdata /var/lib/boot2docker/portainerdata' >> /var/lib/boot2docker/profile"
virsh shutdown mg0
sleep 15s
virsh start mg0
</source>
{{note|A fenti példában a guest-en boot2docker operációs rendszer fut, ami egy különleges állatfaj. Kizárólag a /var/lib/boot2docker mappa tartalma boot perzisztens, mind máshol eszközölt változtatás eltűnik újrainduláskor. Így az fstab-ba sem lehet írni, kizárólag a /var/lib/boot2docker/profile fájlba elhelyezett parancsokkal lehet a mount-ot boot perzizstenssé tenni. Ha a guest-en normál disztribúció fut, akkor írhatjuk a mount-ot az fstab-ba is. }}
A Virtual Machine Manager-ben így néz ki a végeredmény:
:[[File:ClipCapIt-180823-194215.PNG]]
