Libvirt 是一个工具包，和linux系统的虚拟化功能交互。提供了一种通用并且稳定的方式来管理虚拟机。

libvirt提供了各种用于管理虚拟机的api,such as: provision, create, modify, monitor, control, migrate and stop the domains。

Libvirt是一个软件集合，便于使用者管理虚拟机和其他虚拟化功能，比如存储和网络接口管理等等。这些软件包括一个API库、一个daemon（libvirtd）和一个命令行工具（virsh）。Libvirt的主要目标是：提供一种单一的方式管理多种不同的虚拟化提供方式和hypervisor。比如，命令行“virsh list -- all”可以列出所有任何支持的、基于hypervisor的虚拟机，这就避免学习、使用不同hypervisor的特定工具。
“使用libvirt”，意味着使用virsh、virt-manager、virt-install等工具管理虚拟机，这些工具都是围绕着libvirt开发的。人们不再直接使用基于XEN的xm、或是qemu【注1】/qemu-kvm【注2】等二进制工具。
libvirt的主要功能包括：

  • 虚拟机管理：包括不同的领域生命周期操作，比如：启动、停止、暂停、保存、恢复和迁移。支持多种设备类型的热插拔操作，包括：磁盘、网卡、内存和CPU。

  • 远程机器支持：只要机器上运行了libvirt daemon，包括远程机器，所有的libvirt功能就都可以访问和使用。支持多种网络远程传输，使用最简单的SSH，不需要额外配置工作。比如：example.com运行了libvirt，而且允许SSH访问，下面的命令行就可以在远程的主机上使用virsh命令行。 (可参考 http://libvirt.org/remote.html )

         virsh --connect qemu+ssh://root@example.com/system

  • 存储管理：任何运行了libvirt daemon的主机都可以用来管理不同类型的存储：创建不同格式的文件映像（qcow2、vmdk、raw等）、挂接NFS共享、列出现有的LVM卷组、创建新的LVM卷组和逻辑卷、对未处理过的磁盘设备分区、挂接iSCSI共享，等等等等。因为libvirt可以远程工作，所有这些都可以通过远程主机使用。（可参考http://libvirt.org/storage.html ）

  • 网络接口管理：任何运行了libvirt daemon的主机都可以用来管理物理和逻辑的网络接口。可以列出现有的接口卡，配置、创建接口，以及桥接、vlan和关联设备等，通过netcf都可以支持。

  • 虚拟NAT和基于路由的网络：任何运行了libvirt daemon的主机都可以用来管理和创建虚拟网络。Libvirt虚拟网络使用防火墙规则作为路由器，让虚拟机可以透明访问主机的网络。（可参考：http://libvirt.org/archnetwork.html ）

    Libvirt支持的Hypervisor列表： http://libvirt.org/drivers.html

  Libvirt基于GNU Lesser General Public License协议。


注1: QEMU 是一种处理器模拟器，依赖于动态二进制翻译机制，在易于移植至新的主机CPU架构的同时，还要获得合理的速度响应。除提供CPU模拟之外，它还提供了一系列设备模型，允许它运行多种未经修改的客户操作系统；因此QEMU可以被看做一个宿主虚拟机监控软件。它还提供了加速模式，以支持（供kernel code的）二进制翻译和原生执行（供user code）的混合方式，这与VMware Workstation和Microsoft VirtualPC相同。
QEMU 也可以用作纯用户级处理的CPU模拟，在这种运作模式下，它类似于Valgrind。
QEMU有一个特有的可移植×××，虚拟机可以运行在任何PC之上，即使用户只有有限的权限，而且没有管理员访问权限也没有关系，这让“USB优盘上的PC”这一概念变得可行。也有类似的应用，比如MojoPac，但是它们需要管理员权限才能运行。
注2: KVM，Kernel－based Virtual machine 。KVM是一种Linux下的kernel虚拟化基础结构，它自身无法进行任何模拟。需要用户空间的程序使用/dev/kvm接口来设置客户虚拟机的地址空间，像其输入I/O，并将其视频显示映射至主机。QEMU自0.10.0之后可以使用KVM。




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

Hypervisor and domains running on a node

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

http://www.libvirt.org/goals.html