在线迁移的好处太多太多，前段时间由于客户用的虚拟机对内存需求量过高，导致节点内存不够需要扩容，而由于是线上，只好两方人员凌晨来进行内存扩容，涉及到开发，测试，运维以及客户机房，运维一堆人，而且需要各种验证，关机，扩容，开机等，时间拉得十分长，如果顺利则已，由于是和硬件打交道，假如出现了硬件之间不兼容之类的问题，肯定会是一个大坑，甚至出现节点上虚拟机无法使用等风险，此时遥想如果能够在不中断服务的前提下，直接通过一种在线迁移的方式，将各种运行着业务的虚拟机迁移到大容量的节点上，既过渡平滑又节省大量人力，是一个完美的解决方案
去年测试过H版OpenStack的live-migration接口，对于配额容量比较小的虚拟机，直接调用在线迁移接口，的确丝毫感觉不到任何动静，就的确更换了其宿主机，但是做了一种极端的情形，创建了一台32G内存的虚拟机，然后通过一个内存负载工具，将虚拟机内存负载增加到80%~90%，来测试一下服务中断时间，这里主要就关注网络连通性情形
负载如下
top - 09:13:41 up 12:32, 2 users, load average: 0.63, 0.19, 0.10 Tasks: 72 total, 2 running, 70 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 33018772 total, 32800052 used, 218720 free, 936 buffers KiB Swap: 0 total, 0 used, 0 free, 7180 cached
测试的结果网络的中断时间达到了几百秒
Start: 2015-07-19 09:15:38 Stop: 2015-07-19 09:20:52
当时刚来公司，也没有进一步细细地测试以及原因是什么，当时的结论就是虚拟机内存负载占满，热迁移持续时间很长，而且网络会中断许久
今年在许多新需求的要求下，重新进行了在线迁移的测试
而在今年与同事一起进行测试的时候，在当前nova-compute的配置下，调用libvirt热迁移接口时传入的flag值是默认的“VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER”。根据flag的值，源端虚拟机在迁移开始时会被pause，这样网络就会中断，迁移完成之后才会恢复。调用libvirt热迁移接口时可以指定flag参数为“VIR_MIGRATE_LIVE, VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER”,这样在迁移时就会保持源端虚拟机始终处于running状态。但是如果源端虚拟机内存刷新率较高就会出现qemu无限迭代拷贝内存的情况，这时热迁移永远不会结束或者需要非常久的时间才会结束。
这里可以得到两个信息量：
1：目前测试的在线迁移，调用接口之后，就会立马将虚拟机PAUSE住，直到迁移结束，也就是说这个过程中是断网的
2：想要不断网也是可以的，改变一下flag参数即可，但是会出现另一个问题，如果内存刷新率比迁移数据传输更快的话，那么迁移永远赶不上刷新的进度，导致迁移永远无法结束
下面再来看看去年测试的这套环境，庆幸还在
先看看网络传输环境，其实才前兆传输速率
~$ /sbin/ethtool eth0.100 Settings for eth0.100: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: off Cannot get wake-on-lan settings: Operation not permitted Link detected: yes
那么在迁移过程中，宿主机上验证留传输速率，正好大概在前兆范围内
######################################################################################################################## 2016-07-28 14:48:59 eth0.100 | rx bps: 110.9 M bytes/s | rx packets: 10.0 K pkts/s | rx dropped: 0.0 pkts/s 2016-07-28 14:48:59 eth0.100 | tx bps: 3.7 M bytes/s | tx packets: 9.5 K pkts/s | tx dropped: 0.0 pkts/s ######################################################################################################################## 2016-07-28 14:49:00 eth0.100 | rx bps: 111.7 M bytes/s | rx packets: 10.1 K pkts/s | rx dropped: 0.0 pkts/s 2016-07-28 14:49:00 eth0.100 | tx bps: 2.2 M bytes/s | tx packets: 9.8 K pkts/s | tx dropped: 0.0 pkts/s ######################################################################################################################## 2016-07-28 14:49:01 eth0.100 | rx bps: 110.4 M bytes/s | rx packets: 10.9 K pkts/s | rx dropped: 0.0 pkts/s 2016-07-28 14:49:01 eth0.100 | tx bps: 4.5 M bytes/s | tx packets: 10.2 K pkts/s | tx dropped: 0.0 pkts/s ######################################################################################################################## 2016-07-28 14:49:02 eth0.100 | rx bps: 110.7 M bytes/s | rx packets: 11.0 K pkts/s | rx dropped: 0.0 pkts/s 2016-07-28 14:49:02 eth0.100 | tx bps: 2.8 M bytes/s | tx packets: 10.1 K pkts/s | tx dropped: 0.0 pkts/s ######################################################################################################################## 2016-07-28 14:49:03 eth0.100 | rx bps: 112.4 M bytes/s | rx packets: 10.7 K pkts/s | rx dropped: 0.0 pkts/s 2016-07-28 14:49:03 eth0.100 | tx bps: 1.3 M bytes/s | tx packets: 9.8 K pkts/s | tx dropped: 0.0 pkts/s ######################################################################################################################## 2016-07-28 14:49:04 eth0.100 | rx bps: 112.0 M bytes/s | rx packets: 11.0 K pkts/s | rx dropped: 0.0 pkts/s 2016-07-28 14:49:04 eth0.100 | tx bps: 4.8 M bytes/s | tx packets: 10.8 K pkts/s | tx dropped: 0.0 pkts/s ######################################################################################################################## 2016-07-28 14:49:05 eth0.100 | rx bps: 111.3 M bytes/s | rx packets: 10.1 K pkts/s | rx dropped: 0.0 pkts/s 2016-07-28 14:49:05 eth0.100 | tx bps: 1.7 M bytes/s | tx packets: 9.4 K pkts/s | tx dropped: 0.0 pkts/s ########################################################################################################################
因此在我测试过程中，所有的时间都花在了32G内存负载的拷贝中，此时已经被pause住了，就不会有内存刷新了，就直接依赖网络传输，32GB /100MBps 大约300秒左右，与去年验证的5分钟左右相符
也就是说，其实耗时长以及导致断网，与云网络其实没有任何关系，主要取决于live-migration的接口传参导致虚拟机pause断网，而耗时过长则取决于宿主机数据传输的带宽
