为了追赶上VMware虚拟化霸主的脚步，微软从Hyper-V 2.0开始支持物理机与虚拟机之间的动态迁移。动态迁移对于实验室来说，需求可能并不高；但对于企业来说，这却是虚拟化成熟度的一个分水岭。
在开始之前，需要明确一个概念。
动态迁移（Hyper-V Live Migration）并非故障状态下的非计划宕机。
该应用场景仅用于升级、硬件更换等计划宕机。
动态迁移步骤：
• 在源和目标计算机之间建议连接
• 传送虚拟机配置及设备信息
• 传送虚拟机内存
• 暂停（挂起）源虚拟机并传送状态
• 恢复目标虚拟机
一、在源和目标计算机之间建议连接
该部分的通信涉及到两个WMI对群集中两个dll的调用：
clusres.dll
群集资源管理dll（基本的网络、存储、WINS、DHCP、脚本。。）
vmclusres.dll
虚拟机群集资源管理dll
Live Migration从本质上来说还是群集的一种实现方式。
通信的速度与效率与源服务器和目标服务器的负载有关。
在源服务器或目标服务器负载过高情况下会出现WMI调用clusres.dll超时失败的情况。
该场景出现在PRO调用Live Migration过程中，将会造成第4步，即暂停（挂起）源虚拟机并传送状态卡死，导致虚拟机长时间处于挂起状态。
错误信息如下：
错误 (12711)
由于出现错误 [MSCluster_Resource.Name="SCVMM XXX01 Configuration"] ，找不到元素，VMM 无法在服务器 HOST01.contoso.com 上完成 WMI 操作。
详细信息 (找不到元素(0x490))
微软提供的相关的补丁，需要在所有节点上部署：
http://support.microsoft.com/kb/974930
二、传送虚拟机配置及设备信息
这里值得注意的是，该部分传送的并非虚拟机目录中的XML配置文件，仅仅是注册表中的信息。
以上两步完成的是迁移的准备工作，告知了目标服务器虚拟机所需的资源，并分配所需资源。
三、传送虚拟机内存
该部分是迁移的核心技术部分。不论是VMware还是Hyper-V来做迁移，都是无法逃避的问题。
那些销售所谓的服务不会断线，不过是传说。从技术的角度来说只是断线的时间由秒这个级别降低到了毫秒级而已。
我们来详细描述一下内存传送的过程：
1、锁定Guest主机内存，并将该部分的信息传送到目标服务器。
2、Guest主机继续运行，在Host主机中开启一个新的内存分区为Guest主机提供服务。该区域仅保存变更的内容。
3、新内存分区将继续分片锁定，并传送。
4、重复2~3，保证原HOST服务器与目标HOST服务器变更内存的差异在一个极小的时钟周期之内，直至操作1中的内存传送完成。
四、暂停（挂起）源虚拟机并传送状态
这部分包含3个操作：
1、挂起源虚拟机
2、传送***的源虚拟机内存变更片段
3、通知存储，将存储挂载至目标服务器
第四步是迁移时间消耗的关键。
而关键的关键是实时内存状态的保存。
在Hyper-V 1.0中Quick Migration采取的方式是挂起源虚拟机，再处理内存的方式。
所以在迁移过程中会发现宕机的时间与虚拟机所消耗的内存量成正比。
而在Live Migration中，宕机时间不再由所迁移虚拟机消耗的内存来决定。
决定宕机时间的关键点内存大小是一个相对较小的变更内存片段。
根据实测，在Live Migration操作中，ping包监视根据系统负载不同在丢包为2~6之间。
完全可以满足一般企业高可用的需求。
五、恢复目标虚拟机
这个部分与普通的恢复相同。不做详细说明。
