Virtualisation

Virtualisation in Mageia

This page is meant as an explanation on how the pieces fit together in Mageia (more directed towards libvirtd)

Virtualisation options

There's different ways of Virtualisation, which is really just choosing the hypervisor:

qemu

qemu is a "domain builder", it emulates certain hardware to be able to run a guest machine on it.

KVM

KVM is a hypervisor that's run as a kernel module. it takes advantage of, but also requires certain CPU and BIOS hardware instructions if you have them (enabled). it uses qemu to build the domain.

Xen

Xen is a hypervisor that's loaded before the kernel. it can take advantage of certain CPU and BIOS hardware instructions if you have them (enabled). Xen has 2 ways of virtualisation: one is with those instructions to get a full virtualisation (uses qemu to build the domain). and paravirtualisation, which doesn't require them, and doesn't fully virtualise hardware, but depends on Xen-specific drivers (doesn't build a domain as such), and since it sort of shares the kernel and hardware a bit, makes it only usable for linux guests, although these are by definition more (resource-)efficient.

Virtualbox

Virtualbox is from Oracle and is another way to virtualise guests, although this is meant for sporadic desktop use.

VMWare

VMWare is a corporate product meant for dedicated servers with extensive code that isn't fully open source.

Others

There's also OpenVZ containers and others i'm not mentioning cause i don't know anything of them.

Virtualisation layers

virtualisation is quite tricky with all the different components, this is a small explanation wrt libvirtd.

KVM:

1. host kernel
   • kvm module (kvm_intel or kvm_amd)
2. qemu tools
3. libvirtd virt. toolset driver (qemu/kvm)
4. libvirtd
5. libvirt client (like virt-manager, virt-viewer, virt-install, virsh) (can be remote)

Xen:

1. Hypervisor
2. host Kernel
3. (xend: only used with the xm/xapi toolset)
4. virtualisation toolset (xm/xl/xapi)
   • for full virtualisation, this uses qemu
5. libvirtd virt. toolset driver (libvirt-xend, libvirt-xenlight, ...)
6. libvirtd
7. libvirt client (like virt-manager, virt-viewer, virt-install, virsh) (can be remote)

I'll note that xend/xm toolset is being deprecated from Xen 4.3 onwards, making this a lot simpler.

Xen vs KVM

• paravirtualisation: this is very powerful if you have only linux guests, there's specific drivers, but you boot guests from an external precompiled static kernel, making this the most efficient way... plus you don't need any special hardware. This can't quite compare, so i'm leaving it out and compare only the so-called Xen-HVM guests with KVM. in Xen-HVM however, you can still use the efficient PV drivers.
• Xen has a seperate hypervisor that's loaded BEFORE the kernel. this has advantages and disadvantages, you have an extra part to configure, but it has the benefit that you can change kernels and still be compatible.
• Xen has the additional advantage that it can use both amd and intel virtualisation hardware. and even (live-)migrate hosts between them.
• Xen is more difficult to set up than KVM
• KVM is developped inkernel, but Xen is getting all it's advantages in the kernel as well. (you used to need a different kernel.)
• KVM starts a guest as a qemu-kvm process in the host; while Xen starts the guest via the hypervisor (which is on a higher level than the kernel), this means that the host is also a (privileged) guest to the hypervisor.
• as a result of the above, i think that KVM is useful for adding it to your desktop, while i think that Xen is more suited for a dedicated hypervisor, in large environments (multiple hypervisor, needing high uptime, etc)

How does qemu tie into all of this

Qemu has been around for a long time... it emulates hardware so you can do stuff with it.

qemu has different profiles:

• a large set of different architectures
• but also qemu-kvm and qemu-xen

you can execute these directly with different parameters, but this isn't so easy.

for Xen, there's some tricky stuff here:

• in the Xen build, there's a heavily modified qemu source tarball inside. they build their own version of qemu so as to have all the interesting stuff, called xen-qemu-traditional; it will be obsoleted later on.
• they are busy upstreaming this, and mostly it's been done, but some parts are still missing.
• this means that the qemu-xen binary from the qemu package itself isn't being used.
• in the Xen build, there's a second qemu tarball, which is the upstream qemu (and a small amount of additional patches), called xen-qemu.
• this means that the both the xen build and the qemu build have both qemu-xen, but they differ.
• in the nearby future, all this mess will disappear and qemu-xen will be built from qemu and xen it'self won't build qemu-xen anymore.

Keep in mind that qemu in Xen is only used by full virtualisation, and thus generally will be only used for non-linux guests.

libvirt

libvirt is a management tool for virtualisation. it has backend drivers, a daemon and frontends.

• backend drivers are alot and include things like KVM/Xen/OpenVZ/HyperV/Virtualbox/VMWare/... ideally it's a toolset by which you can manage several types of hypervisors centrally.
• the deamon is not used for virtualisation itself, but for libvirt clients to connect and managing the underlying hardware (storage pools and networks and starting and stopping guests etc...)
• virt-manager(remotely/locally) and virsh(locally) are the most used libvirtd frontends.