libvirt domin的生命周期控制

libvirt 可以控制域的整个生命周期，域可以在下面几种状态中进行转换：
1.undefined.这是基线状态，域没有被定义或创建
2.Defined.域被定义了但没有运行，该状态也可以描述为Stopped
3.Running,一个正在运行的域被定义并且在一个hypervisor上定义
4.Paused.已暂停的客户域处于运行状态的挂起状态。它的内存映像已经被临时存储，并且可以在客户域操作系统不知道它曾经挂起的情况下恢复到Running状态。
5.Saved.已保存的域已将其在暂停状态下捕获的内存映像保存到持久存储。可以将它恢复到Running状态，而客户域操作系统不知道它曾经挂起。

Provisioning指的是创建新客户域的任务，通常使用某种形式的操作系统安装介质。提供来宾机的方法有很多种，但可用的选择将根据所提供的hypervisor和来宾域的类型而有所不同。应用程序支持几种不同的供应方法是很常见的。启动是指在管理程序上执行已供应的客户域。
有三种方式来提供guests,createXML方法将创建并立即启动一个临时的guest domain,当shuts down时，它就会消失。defineXML方法会保存配置为永久的guest domain.create方法将启动已经defined的domain,注意，defineXML命令可以将一个先前已经启动的临时域转换为一个永久域。
要引导一个短暂的客户域，只需要一个到libvirt的连接和一个包含描述所需客户配置的XML文档的字符串，以及一个控制域启动的标志。
如果设置了VIR_DOMAIN_START_PAUSED标志，客户域将被启动，但其cpu将保持暂停状态。以后可以使用resume方法手动启动cpu。
如果设置了VIR_DOMAIN_START_AUTODESTROY标志，那么当virConnect对象最终被释放时，客户域将被自动销毁。如果客户机应用程序崩溃或失去与libvirtd守护进程的连接，也会发生这种情况。任何标记为自动销毁的域将阻止迁移、保存到文件或快照的尝试。

import sys
​import libvirt
​
​xmlconfig = '<domain>........</domain>'
​
​conn = None
​try:
​    conn = libvirt.open("qemu:///system")
​except libvirt.libvirtError as e:
​    print(repr(e), file=sys.stderr)
​    exit(1)
​
​dom = conn.createXML(xmlconfig, 0)
​if dom == None:
​    print('Failed to create a domain from an XML definition.', file=sys.stderr)
​    exit(1)
​
​print('Guest '+dom.name()+' has booted', file=sys.stderr)
​
​conn.close()
​exit(0)

如果域创建尝试成功，则返回的virDomain实例，否则返回None。虽然域已成功启动，但这并不保证域仍在运行。客户域完全有可能崩溃，在这种情况下，尝试使用返回的virDomain对象将产生错误，因为临时domain在关闭时将不再存在(无论是计划中的关闭，还是崩溃)。要处理这个场景，需要使用持久domain。
在引导持久域之前，必须定义它的配置。这同样需要一个到libvirt的连接和一个包含描述所需客户机配置的XML文档的字符串。从定义客户机获得的virDomain对象可以用于引导它。

import sys
​import libvirt
​
​xmlconfig = '<domain>........</domain>'
​
​conn = None
​try:
​    conn = libvirt.open("qemu:///system")
​except libvirt.libvirtError as e:
​    print(repr(e), file=sys.stderr)
​    exit(1)
​
​dom = None
​try:
​    dom = conn.defineXMLFlags(xmlconfig, 0)
​except libvirt.libvirtError as e:
​    print(repr(e), file=sys.stderr)
​    exit(1)
​
​if dom.create() < 0:
​    print('Can not boot guest domain.', file=sys.stderr)
​    exit(1)
​
​print('Guest '+dom.name()+' has booted', file=sys.stderr)
​
​conn.close()
​exit(0)

本节将首先说明两种配置，它们允许与物理机器使用的配置方法相媲美的配置方法。然后概述了第三种选择，它是虚拟化硬件特有的，但有一些有趣的好处。出于演示的目的，下面的示例将使用XML配置来设置一个KVM完全虚拟化的客户机，使用一个磁盘和网络接口，以及一个使用VNC显示的视频卡。

<domain type='kvm'>
​  <name>demo</name>
​  <uuid>c7a5fdbd-cdaf-9455-926a-d65c16db1809</uuid>
​  <memory>500000</memory>
​  <vcpu>1</vcpu>
​  <os>.... this block will vary per approach ....</os>
​  <clock offset='utc'/>
​  <on_poweroff>destroy</on_poweroff>
​  <on_reboot>restart</on_reboot>
​  <on_crash>destroy</on_crash>
​  <devices>
​    <emulator>/usr/bin/qemu-kvm</emulator>
​    <disk type='file' device='disk'>
​      <source file='/var/lib/libvirt/images/demo.img'/>
​      <driver name='qemu' type='raw'/>
​      <target dev='hda'/>
​    </disk>
​    <interface type='bridge'>
​      <mac address='52:54:00:d8:65:c9'/>
​      <source bridge='br0'/>
​    </interface>
​    <input type='mouse' bus='ps2'/>
​    <graphics type='vnc' port='-1' listen='127.0.0.1'/>
​  </devices>
​</domain>

所有的完全虚拟化技术都支持在来宾域中模拟CDROM设备，因此这是提供新来宾域的明显选择。然而，很难找到为半虚拟化客户机提供CDROM设备的管理程序。
要支持CDROM安装，XML配置需要做的第一个明显的更改是添加CDROM设备。来宾域的CDROM设备可以指向主机CDROM设备，也可以指向ISO镜像文件。下一个更改是确定BIOS引导顺序，有两个可能的选项。如果硬盘列在CDROM设备前面，那么CDROM媒体将不会被引导，除非硬盘上的第一个引导扇区是空的。如果CDROM设备列在硬盘前面，那么就有必要在安装后更改guest配置，使其从安装的磁盘启动。虽然这两种方法都可行，但第一种方法最容易实现。
前面显示的来宾配置将插入以下XML块:

​<os>
​  <type arch='x86_64' machine='pc'>hvm</type>
​  <boot dev='hd'/>
​  <boot dev='cdrom'/>
​</os>

注意，这假设硬盘启动扇区最初是空白的，因此第一次启动尝试落在CD-ROM驱动器。它还需要添加一个CD-ROM驱动器设备。

​<disk type='file' device='cdrom'>
​  <source file='/var/lib/libvirt/images/rhel5-x86_64-dvd.iso'/>
​  <target dev='hdc' bus='ide'/>
​</disk>

确定了配置后，现在就可以供应客户机了。这是一个简单的过程，只需要定义一个持久的客户机，然后引导它。

import sys
​import libvirt
​
​xmlconfig = '<domain>........</domain>'
​
​conn = None
​try:
​    conn = libvirt.open("qemu:///system")
​except libvirt.libvirtError as e:
​    print(repr(e), file=sys.stderr)
​    exit(1)
​
​dom = None
​try:
​    dom = conn.defineXMLFlags(xmlconfig, 0)
​except libvirt.libvirtError as e:
​    print(repr(e), file=sys.stderr)
​    exit(1)
​
​if dom.create() < 0:
​    print('Can not boot guest domain.', file=sys.stderr)
​    exit(1)
​
​print('Guest '+dom.name()+' has booted', file=sys.stderr)
​
​conn.close()
​exit(0)

如果不能保证硬盘的引导扇区是空白的，那么配置过程将分为两个步骤。首先，使用CD-ROM驱动器作为主引导设备引导一个临时客户端。完成之后，客户机的持久配置将被定义为从硬盘引导。
除了defineXML方法外，还可以使用另一种方法defineXMLFlags。
一些较新的完全虚拟化技术提供了能够使用PXE引导协议从网络引导的BIOS。如果某个环境已经部署了PXE引导配置服务器，那么对于客户域来说，这是一种可取的方法。
PXE引导客户机显然需要为客户机配置一个网络设备。该网卡所连接的LAN也需要一个可用的PXE / TFTP服务器。下一个更改是确定BIOS引导顺序，有两个可能的选项。如果硬盘列在网络设备前面，那么网卡将不会PXE引导，除非硬盘上的第一个引导扇区是空的。如果网络设备列在硬盘前面，那么就需要在安装后更改guest配置，使其从安装的磁盘启动。虽然这两种方法都可行，但第一种方法最容易实现。

<os>
​  <type arch='x86_64' machine='pc'>hvm</type>
​  <boot dev='hd'/>
​  <boot dev='network'/>
​</os>

注意，这假设硬盘启动扇区最初是空白的，因此第一次启动尝试落入网卡。确定了配置后，现在就可以供应客户机了。这是一个简单的过程，只需要定义一个持久的客户机，然后引导它。

import sys
​import libvirt
​
​xmlconfig = '<domain>........</domain>'
​
​conn = None
​try:
​    conn = libvirt.open("qemu:///system")
​except libvirt.libvirtError as e:
​    print(repr(e), file=sys.stderr)
​    exit(1)
​
​dom = None
​try:
​    dom = conn.defineXMLFlags(xmlconfig, 0)
​except libvirt.libvirtError as e:
​    print(repr(e), file=sys.stderr)
​    exit(1)
​
​if dom.create() < 0:
​    print('Can not boot guest domain.', file=sys.stderr)
​    exit(1)
​
​print('Guest '+dom.name()+' has booted', file=sys.stderr)
​
​conn.close()
​exit(0)

如果不能保证硬盘的引导扇区是空白的，那么配置过程将分为两个步骤。首先，使用网络作为主引导设备引导一个临时客户端。完成之后，客户机的持久配置将被定义为从硬盘引导。
半虚拟化技术模拟了一组相当严格的硬件，这常常使我们无法使用刚刚概述的配置选项。对于这种情况，通常可以直接从存储在主机文件系统上的内核和initrd映像引导新的客户域。这有一个有趣的优点，那就是可以直接设置内核命令行引导参数，使完全自动化安装变得非常容易。这种优势非常引人注目，甚至可以将这种技术用于具有CD-ROM驱动器/PXE支持的完全虚拟化的客户域。
直接内核引导的一个复杂之处在于，配置过程分为两个步骤。对于第一步，需要将来宾XML配置配置为指向内核/initrd。

​<os>
​  <type arch='x86_64' machine='pc'>hvm</type>
​  <kernel>/var/lib/libvirt/boot/f11-x86_64-vmlinuz</kernel>
​  <initrd>/var/lib/libvirt/boot/f11-x86_64-initrd.img</initrd>
​  <cmdline>method=http://download.fedoraproject.org/pub/fedora/linux/releases/11/x86_64/os console=ttyS0 console=tty</cmdline>
​</os>

请注意，内核命令行如何提供下载站点的URL，该站点包含与内核/initrd匹配的发行版安装树。这允许安装程序自动下载所有资源，而无需提示用户输入安装URL。它还可以用于为完全无人参与的安装提供一个kickstart文件。最后，这个命令行还告诉内核将第一个串行端口和VGA卡作为控制台激活，而后者是默认的。以这种方式在串行端口上复制内核消息是一种有用的调试方法。当然，有效的命令行参数根据所引导的特定内核而有所不同。请参阅内核供应商/分发服务器的文档以获得有效选项。
启动客户机之前的最后一个XML配置细节是将’on_reboot’元素操作更改为’destroy’。这确保了当客户安装程序完成并请求重新启动时，客户程序将被关闭。这允许管理应用程序更改配置，使其从刚安装的硬盘重新启动。现在可以通过使用第一个XML配置创建一个临时客户机来启动配置过程.

import sys
​import libvirt
​
​xmlconfig = '<domain>........</domain>'
​
​conn = None
​try:
​    conn = libvirt.open("qemu:///system")
​except libvirt.libvirtError as e:
​    print(repr(e), file=sys.stderr)
​    exit(1)
​
​dom = conn.createXML(xmlconfig, 0)
​if dom == None:
​    print('Unable to boot transient guest configuration.', file=sys.stderr)
​    exit(1)
​
​print('Guest '+dom.name()+' has booted', file=sys.stderr)
​
​conn.close()
​exit(0)

一旦该来宾程序关闭，供应过程的第二阶段就可以开始了。对于这个阶段，'OS’元素将删除内核/initrd/cmdline元素，并由对主机端引导加载程序或BIOS引导设置的引用替换。前者用于Xen半虚拟化客户机，而后者用于完全虚拟化客户机。
Xen半虚拟化客户的阶段2配置如下:

​<domain>
​  ...
​  <bootloader>/usr/bin/pygrub</bootloader>
​  <os>
​    <type arch='x86_64' machine='pc'>xen</type>
​  </os>
​  ...
​</domain>

而完全虚拟化的客户机将使用:

<domain>
​  ...
​  <bootloader>/usr/bin/pygrub</bootloader>
​  <os>
​    <type arch='x86_64' machine='pc'>hvm</type>
​    <boot dev='hd'/>
​  </os>
​  ...
​</domain>