虚拟机的迁移是指在源物理主机上运行的虚拟机操作系统及应用程序移动到目标物理主机上或虚拟机上，并且在目标主机上能够正常运行。在openstack中，openstack自带虚拟机的迁移功能，允许一个正在running的虚拟机实例从一个compute node迁移到另一个compute node。下面给大家推荐一篇相关的实战案例，作者是用友公有云技术总监，中国计算机学会高级会员，大数据专委会委员，前中科院副研究员。
以下是作者原文：
一直想和大家分享虚拟机的在线迁移，考虑到稳定性，我们在线上运行了几个月比较稳定后，再总结出来和大家分享。
大致描述一下场景：系统采用了计算存储松耦合结构，虚机的映像文件在远端共享存储上，所以迁移起来速度很快。在我们系统中，最快一个用了6秒，即完成了在线迁移，这是真正的live migration，我们一边迁移，一边故意在虚机里写数据，也正常完成。
配置方案
1.修改Nova.conf文件
添加： image_cache_manager_interval=0 live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_UNSAFE 修改： vncserver_listen=0.0.0.0
2.参与的计算节点机器名字都能ping通。
3.修改计算节点上 /etc/libvirt/libvirtd.conf:
before : #listen_tls = 0 after : listen_tls = 0 before : #listen_tcp = 1 after : listen_tcp = 1 add: auth_tcp = "none"
4.修改 /etc/sysconfig/libvirtd:
before :# LIBVIRTD_ARGS="--listen" after :LIBVIRTD_ARGS="–listen"
5.在源计算节点上修改要迁移虚机的/var/run/libvirt/qemu/instance–xxx.xml文件，删除migrate-qemu-fd这一行，将vnc参数修改成0.0.0.0
6.重启计算节点上nova
7备注：
1.由于云机之前没有配置在线迁移，在迁移虚机之前，需要重启虚机。 2..因为计算节点上libvirtd的配置中增加了auth_tcp="none"，算是一个安全漏洞，需要寻找更安全的办法，或者在迁移完成之后，注释掉这行，重启libvirt 3 已经编写了一个辅助程序自动做迁移
遇到的问题和解决办法
1.虚机的disk 的cache mode为writethrough，迁移的时候报错
openstack认为在CentOS上磁盘cache mod为writethrough时，迁移是不安全的。 解决的办法 ：在nova.conf live_migration_flag参数后面增加VIR_MIGRATE_UNSAFE，官方在线迁移配置文件里没有这个参数。
2.qemu1.4的一个bug导致迁移失败
迁移失败，在目的节点上/var/log/libvrit/qemu/instances--xxxx.log里： char device redirected to /dev/pts/1 (label charserial1) qemu: warning: error while loading state section id 2 load of migration failed 解决办法： 1.在源计算节点上修改要迁移虚机的/var/run/libvirt/qemu/instance–xxx.xml文中删除migrate-qemu-fd这一行 2.重启源计算节点上的libvirtd 3.然后再执行nova live-migration命令 这个操作已经编写了一个程序自动执行。
3.vncserver的问题，需要重启虚拟机才可以迁移。
由于之前Nova.conf中vncserver_listen=计算机节点的ip，所以在虚拟机Kvm进程中参数中vnc=计算节点的ip，迁移的时候报错，在目的节点绑定不了源节点的IP,所以需要修改Libvirt.xml配置文件，重启虚机，然后才能进行迁移。 解决办法： 1.在源计算节点上/var/run/libvirt/qemu/instance–xxx.xml文中将vnc的参数修改成0.0.0.0 2.重启源计算节点libvirtd 3.然后再执行nova live-migration命令 这个操作已经编写了程序来自动完成
4.迁移完成后console.log,disk属主变成了root/root
迁移完成后，发现虚机的console.log和disk文件属主由qemu.qumu变成了root.root，这个估计是openstack迁移程序的问题，这个问题目前没有影响虚机。 解决办法: 修改文件属主，这个操作已经编写了程序来自动完成
5.源节点和目的节点cpu不兼容问题
迁移失败，在/var/log/nova/compute的日志： "InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility.nn0nnRefer to <a href="http://libvirt.org/html/libvirt-libvirt.html#virCPUCompareResultn" ]"="" style="cursor: pointer; color: rgb(0, 102, 204); text-decoration: none;">http://libvirt.org/html/libvirt-libvirt.html#virCPUCompareResultn"] 解决办法： 目前还没有解决办法
6.目的节点内存为负，
迁移失败，从控制节点的api.log上输出的错误是目的节点内存为-3400，不能满足迁移的需要。 解决办法： 用nova命令指定在该计算节点上创建虚机，能够成功。估计是迁移时候的调度算法和创建虚机时的调度算法不一致。
7.错误日志，在2.4上api.log
迁移时候一般看的日志有： 1.目的节点上的/var/log/libvirt/qemu/instances–xxx.log 2.目的节点上的/var/log/nova/compute.log 3.源节点上的/var/log/nova/compute.log 有时候迁移失败，命令行执行后报错： ERROR: Live migration of instance bd785968-72f6-4f70-a066-b22b63821c3b to host compute-13 failed (HTTP 400) (Request-ID: req-180d27b5-9dc7-484f-9d9a-f34cccd6daa2) 但在上述的三个日志文件中都看不到任何的错误信息。 解决办法： 在控制节点或者是在操作迁移命令的节点上/var/log/nova/api.log有错误信息
走的弯路
1.尝试不用修改nova.conf里的vncserver_listen参数为0.0.0.0，
将/var/run/log/libvirt/qemu/instances--xxx.log里的vnc改成目的节点的ip，重启libvritd，然后进行迁移，可以成功，但如果迁移失败，当需要重新虚机的时候，虚机启动失败，在/var/log/libvrit/qemu/instances-xx.log的错误是 Failed to start VNC server on `172.18.2.15:0': Failed to bind socket: Cannot assign requested address 而/mnt/instances/instance--xxx/libvirt.xml里没有修改成目的节点的Ip。不知道这个参数被保存到了哪里
2.vnc 端口问题
在一次迁移失败后，在目的节点/var/log/libvirt/qemu/instance--xxx.log里的错误是： 2013-11-05 05:42:39.401 0000: shutting down qemu: terminating on signal 15 from pid 10271， 猜想是由于虚机在源节点上的vnc监听端口在目的节点上被占用，所以导致启动不了。后来在其他机器上做了测试发现，在迁移到目的节点后vnc的端口自己会调整。
参考：
How to Migrate an Instance with Zero Downtime: OpenStack Live Migration with KVM Hypervisor and NFS Shared Storage
