基于libvirt的虚拟化迁移

为什么要迁移呢？当一台主机的负载过高时，我们希望把虚拟机迁移到一台系统更好的主机上。当主机发生硬件故障需要停机维护时，我们需要迁移虚拟机，如果主机就只跑了一台虚拟机我们可以把它迁移到其他主机，提高资源的利用率，等等。

迁移命令：
# virsh migrate --live GuestName DestinationURI   （--live ：迁移过程中虚拟机一直保持运行状态）
GuestName指虚拟机名称，DestinationURI：目的主机的URI。
举例：# virsh  migrate --live vm0 qemu+tcp://192.168.0.200/system
迁移的要求是：需要目的主机和源主机有相同的环境，包括hypervisor。

注意点：
笔者在做迁移的时候，所有前置条件都一配置好，执行迁移命令：
sudo virsh migrate --live vm0 qemu+tcp://192.168.1.200/system
却出现的如下错误：
error: Unable to resolve address 'ubuntu1204' service '49152': No address associated with hostname
笔者的系统环境是Ubuntu，错误中‘ubuntu1204’是192.168.1.200的主机名，对此错误很是不解，说是‘ubuntu1204’无法解析，查得资料：http://wiki.libvirt.org/page/Migration_fails_with_%22Unable_to_resolve_address%22_error
在迁移的过程中，运行在目的主机中的libvirtd进程要根据address和port创建一个URI，URI是目的主机用来接收数据和发回数据到源主机的libvirtd进程的。上面的错误的原因是libvirtd没法解析主机名到IP地址。可以看下图：
目的主机libvirtd在发回数据的时候，把hostname发回去了，而源主机就用直接请求hostname而非IP，恰巧在源主机没有做DNS配置，因此才出现次错误。
如果是在REHEL系列的Linux中出现的错误如所示：Migration fails with "Unable to resolve address" error

解决方案一：
配置source源主机的 /etc/hosts文件：加入"192.168.1.200 ubnuntu1204"  参考：http://bbs.openzj.com/thread-7200-1-1.html

解决方案二：
# virsh migrate vm0 qemu+tcp://192.168.1.200/system tcp://192.168.1.200
这时目的主机libvirtd进程将使用“tcp://192.168.1.200“作为迁移连接，libvirt会自动生成的端口追加到此URI后面，(这里相当于开启另外一个连接来迁移数据，可以和方案三对比之）当然也可以手动指定端口号如：
# virsh migrate vm0 qemu+tcp://192.168.1.200/system tcp://192.168.1.200 12345

解决方案三：使用隧道(tunnelled) 迁移，该方式不会为迁移创建单独的连接，而是通过与目的libvirtd通信的这个连接来传输数据。（例如连接：qemu+tcp://192.168.1.200/system）
# virsh migrate vm0 qemu+tcp://192.168.1.200/system  --p2p --tunnelled

问题解决了，顺便学习下libvirt migrate的概念：

说到虚拟机的迁移，其实就是数据的转移，数据的转移就涉及数据的传输，数据的传输需要通过网络。libvirt提供了两种方案。

hypervisor native transport：
“本地”数据传输，相当于一种手动方式做的迁移。数据是否可以加密取决于hypervisor自身是否已实现。
Migration native path

libvirt tunnelled transport
隧道化的（tunnelled）数据传输支持很强的加密功能，这要归结于libvirt的RPC协议。不好的一方面是数据会在hypervisor和libvirtd之间的传输。
Migration tunnel path
迁移时的通信控制：（此景会有一个第三方的管理程序来管理，上面所说单纯是从两个主机直接的角度来说的）

虚拟机的迁移需要两个主机之间的密切协调，同时应用程序（虚拟机管理平台）也将参与进来，此应用可以是在源主机、目的主机、甚至是第三台主机。

受管理的直接迁移（Managed direct migration）：
直接管理迁移，libvirt客户端进程控制迁移的不同阶段。客户端应用程序必须连接以及获得在源主机和目的主机的libvirtd进程的认证。无需两个libvirtd进程间相互通信。如果客户端应用崩溃了，或者在迁移过程中失去了链接，一种办法就是强制终止迁移，重启源主机的guest CPU。
Migration direct, managed
受管理的点对点迁移：（Managed peer to peer migrate）
对于点对点，libvirt客户端程序只是与在源主机的libvirtd进程通信，源主机libvirtd进程自己控制整个迁移的过程，直接连接到目的主机的libvirtd。如果客户端应用崩溃了或者与libvirtd失去连接，迁移过程无需中断直至迁移完成。需要注意的是源主机认证（通常是root）链接到目的主机，而不是通过客户端应用链接到源主机。

Migration peer-to-peer
不受管理的直接迁移：（Unmanaged direct migrate）
此迁移方式既不受libvirt客户端控制，也不受libvirtd控制，迁移的控制过程委托给基于hypervisor之上的管理服务来处理。libvirt 客户只需要通过hypervisor的管理层做一下初始化。不管是libvirt 客户端还是libvirtd崩溃了，迁移还是会照样进行直至完成。

Migration direct, unmanaged

迁移URI：
虚拟机迁移时，客户端应用程序需要准备的URI可达三个，具体取决于控制流如何选择或者API如何调用。第一个URI就是应用程序到运行着虚拟机的源主机的连接，第二个URI就是目的主机到应用程序之间的连接（在点对点的迁移中，这个连接是来自源主机，而不是客户端应用程序）。第三个URI就是hypervisor指定的用来控制以何种方式迁移的连接。在任何一种受管理的迁移中，前两个URI是必不可少的，第三个是可选的。而在不受管理的直接迁移中，第一个和第三个是必须的，第二个并不会使用。


通常管理应用程序只需关心前两个URI。二者都是普通的libvirt 连接URI格式。libvirt会通过查找目的主机的配置文件中的hostname自动确定hypervisor指定的URI（第三个URI）。

应用程序获取第三个URI时可能会出现的如下几种情况：
1、hostname的配置不正确，或者DNS不正确，如果主机的hostname不能正确的解析到IP地址的化就会生成一个错误的URI，这刚好时文章开头出现的问题。此时需要明确指定IP地址或者使用正确的hostname。
2、主机有多个网络接口，此时需要用IP明确指定来关联某个具体的网卡。
3、防火墙限制端口的使用，当libvirt自动生扯功能的端口需要防火墙对其端口是开放的。