virtulization - Libvirt/KVM/Qemu

1, Libvirt: http://libvirt.org/
Anatomy of the libvirt virtualization library (From IBM, 2010)

Libvirt provides a hypervisor-agnostic API to securely manage guest operating systems running on a host. Libvirt isn't a tool per se but an API to build tools to manage guest operating systems. Libvirt itself is built on the idea of abstraction. It provides a common API for common functionality that the supported hypervisors implement. Libvirt was originally designed as a management API for Xen, but it has since been extended to support a number of hypervisors.

developed by Redhat.


The two fundamental differences are that libvirt calls the physical host a node, and the guest operating system is called a domain. Note here that libvirt (and its application) runs in the domain of the host Linux operating system (domain 0).
-----------------------------



Control of remote hypervisors with libvirtd
-----------------------------


To support extensibility over a wide variety of hypervisors, libvirt implements a driver-based architecture, which allows a common API to service a large number of underlying hypervisors in a common fashion. 

Hypervisors that libvirt supports

Hypervisor	Description
Xen	Hypervisor for IA-32, IA-64, and PowerPC 970 architectures
QEMU	Platform emulator for various architectures
Kernel-based Virtual Machine (KVM)	Linux platform emulator
Linux Containers (LXC)	Linux (lightweight) containers for operating system virtualization
OpenVZ	Operating system-level virtualization based on the Linux kernel
VirtualBox	Hypervisor for x86 virtualization
User Mode Linux	Linux platform emulator for various architectures
Test	Test driver for a fake hypervisor
Storage	Storage pool drivers (local disk, network disk, iSCSI volume)

libvirt introduction(chinese): http://smilejay.com/2013/03/libvirt-introduction/



Term & Goals from official website:

Terminology and goals

To avoid ambiguity about the terms used, here are the definitions for some of the specific concepts used in libvirt documentation:

• a node is a single physical machine
• an hypervisor is a layer of software allowing to virtualize a node in a set of virtual machines with possibly different configurations than the node itself
• a domain is an instance of an operating system (or subsystem in the case of container virtualization) running on a virtualized machine provided by the hypervisor

Now we can define the goal of libvirt: to provide a common and stable layer sufficient to securely manage domains on a node, possibly remote.

As a result, libvirt should provide all APIs needed to do the management, such as: provision, create, modify, monitor, control, migrate and stop the domains - within the limits of the support of the hypervisor for those operations. Not all hypervisors provide the same operations; but if an operation is useful for domain management of even one specific hypervisor it is worth providing in libvirt. Multiple nodes may be accessed with libvirt simultaneously, but the APIs are limited to single node operations. Node resource operations which are needed for the management and provisioning of domains are also in the scope of the libvirt API, such as interface setup, firewall rules, storage management and general provisioning APIs. Libvirt will also provide the state monitoring APIs needed to implement management policies, obviously checking domain state but also exposing local node resource consumption.

This implies the following sub-goals:

• All API can be carried remotely though secure APIs
• While most API will be generic in term of hypervisor or Host OS, some API may be targeted to a single virtualization environment as long as the semantic for the operations from a domain management perspective is clear
• the API should allow to do efficiently and cleanly all the operations needed to manage domains on a node, including resource provisioning and setup
• the API will not try to provide high level virtualization policies or multi-nodes management features like load balancing, but the API should be sufficient so they can be implemented on top of libvirt
• stability of the API is a big concern, libvirt should isolate applications from the frequent changes expected at the lower level of the virtualization framework
• the node being managed may be on a different physical machine than the management program using libvirt, to this effect libvirt supports remote access, but should only do so by using secure protocols.
• libvirt will provide APIs to enumerate, monitor and use the resources available on the managed node, including CPUs, memory, storage, networking, and NUMA partitions.

So libvirt is intended to be a building block for higher level management tools and for applications focusing on virtualization of a single node (the only exception being domain migration between node capabilities which involves more than one node).

2, relationship between QEMU & KVM （chinese)

http://blog.chinaunix.net/uid-23769728-id-3256677.html

QEMU is an independent virtualization tool/env, it can work without KVM. but if we have KVM and hardware(CPU) support (e.g. Intel VT), QEMU can use KVM to improve the performance in CPU virtualization.

KVM has two kernel modules: kvm.ko & kvm_intel.ko(kvm_amd.ko), these modules are used to provide CPU virtualization. for others, like IO virtuzalition, KVM based on QEMU's solution, all in all, it's qemu-kvm. KVM has dependency on QEMU.