Libvirt – The Unsung Hero of Cloud Computing (2013)

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

Libvirt Driver Based Architecture

Libvirt to support wide variety of hypervisor implements a driver-based architecture. Based on car analogy, it means delegating the actual implementation of control of different cars to the drivers specifically designed for make, model and engine of the specific car. Libvirt currently supports:

Hypervisor

• LXC - Linux Containers
• OpenVZ
• QEMU
• Test - Used for testing
• UML - User Mode Linux
• VirtualBox
• VMware ESX
• VMware Workstation/Player
• Xen
• Microsoft Hyper-V
• IBM PowerVM (phyp)
• Parallels
• Remote - Accessing libvirt on remote node through libvirtd (libvirt daemon)

Storage

• Directory backend
• Local filesystem backend
• Network filesystem backend
• Logical Volume Manager (LVM) backend
• Disk backend
• iSCSI backend
• SCSI backend
• Multipath backend
• RBD (RADOS Block Device) backend
• Sheepdog backend

Virtual Networks

• Bridging
• NAT
• VEPA (Virtual Ethernet Port Aggregator)
• VN-LINK

Libvirt API structure

The figure above shows the five main objects exported by the API:

virConnectPtr

Represents the connection to a hypervisor. Use one of the virConnectOpen functions to obtain connection to the hypervisor which is then used as a parameter to other connection API’s.

virDomainPtr

Represents one domain either active or defined (i.e. existing as permanent config file and storage but not currently running on that node). The function virConnectListAllDomains lists all the domains for the hypervisor.

virNetworkPtr

Represents one network either active or defined (i.e. existing as permanent config file and storage but not currently activated). The function virConnectListAllNetworks lists all the virtualization networks for the hypervisor.

virStorageVolPtr

Represents one storage volume generally used as a block device available to one of the domains. The function virStorageVolLookupByPath finds the storage volume object based on its path on the node.

virStoragePoolPtr

Represents a storage pool, which is a logical area used to allocate and store storage volumes. The function virConnectListAllStoragePools lists all of the virtualization storage pools on the hypervisor. The function virStoragePoolLookupByVolume finds the storage pool containing a given storage volume.

These names follow C conventions, but developers of cloud computing platforms and applications do not need to use C directly, there are language bindings available for major languages. Currently libvirt API language bindings are available for C#, Java, OCaml, Perl, PHP, Python, Ruby.

Domain Management Architecture

There are two distinct means for domain management using libvirt API.

1. Single node domain management

As illustrated in the figure above in this mode applications (cloud management platform i.e. CMP applications) and domains exist on the same node. In this scenario applications directly works through the libvirt api on the host operating system (os) to control and manage the local domains.

2. Multi node domain management

As shown in the figure above, applications (CMP applications) using libvirt API and the domains to manage or control are on separate nodes. In this mode a special domain called libvirtd (libvirt daemon) needs to run on remote nodes. The management application nodes use the nodes underlying network communicattion to communicate with remote libvirtd through the local libvirt using custom protocol. Actually libvirt uses Remote driver for communicating with remote node and remote API calls are handled synchronously. Remote driver for libvirt supports a range of transports like:

tls

TLS 1.0 (SSL 3.1) authenticated and encrypted TCP/IP socket, usually listening on a public port number. To use this you will need to generate client and server certificates. The standard port is 16514. This is the default transport, if no other is specified.

unix

nix domain socket. Since this is only accessible on the local machine, it is not encrypted, and uses Unix permissions or SELinux for authentication. The standard socket names are /var/run/libvirt/libvirt-sock and /var/run/libvirt/libvirt-sock-ro (the latter for read-only connections).

ssh

Transported over an ordinary ssh (secure shell) connection. Requires Netcat (nc) installed and libvirtd should be running on the remote machine. You should use some sort of ssh key management (eg. ssh-agent) otherwise programs which use this transport will stop to ask for a password.

ext

Any external program which can make a connection to the remote machine by means outside the scope of libvirt.

tcp

nencrypted TCP/IP socket. Not recommended for production use, this is normally disabled, but an administrator can enable it for testing or use over a trusted network. The standard port is 16509.

libssh2

Transport over the SSH protocol using libssh2 instead of the OpenSSH binary. This transport uses the libvirt authentication callback for all ssh authentication calls and therefore supports keyboard-interactive authentication even with graphical management applications. As with the classic ssh transport netcat is required on the remote side.

from Hacker News https://ift.tt/3jLnPsQ