在生产环境中运行微软Hyper-V的大多数组织都认为动态迁移是一个非常关键的功能。动态迁移失败可能带来毁灭性的结果，而一些配置错误可能导致动态迁移的失败。了解导致Hyper-V动态迁移失败的常见因素能够将问题扼杀在摇篮里。

　　没有足够的资源 Hyper-V不能进行动态迁移

　　导致动态迁移失败的最常见的问题之一同样也是最容易纠正的。为了将虚拟机从一台主机动态迁移至另一台主机，目标主机必须具有足够的物理资源来承载该虚拟机，比如足够的物理内存。如果目标主机没有足够多空闲的物理内存（或者其他物理硬件资源），那么动态迁移将以失败而告终。

　　问题的解决办法很简单。管理员将虚拟机迁移到其他具有足够硬件资源的主机或者关闭目标主机上优先级较低的虚拟机，腾出空间和资源。

　　处理器不兼容将导致迁移失败

　　微软Hyper-V不需要集群节点使用完全相同的硬件。然而， Hyper-V集群中的每台主机服务器必须具有类似的处理器用于动态迁移。意思是你需要确保所有的物理主机处理器出自相同系列。换句话说，你不能够将虚拟机从一台配置了Intel处理器的物理主机迁移至配置了AMD处理器的物理主机之上。

　　有时使用类似的CPU型号还不足以满足动态迁移的条件。例如，几周前我决定将配置6核AMD处理器的服务器替换为8核AMD处理器的新服务器。原本计划将这些新的服务器添加到现有的Hyper-V集群中，将VM从旧服务器动态迁移到新服务器，然后将这些旧服务器下线。不幸的是，由于处理器指令集差距过大导致了动态迁移的失败。

　　通过将VM配置为使用处理器兼容模式，我成功地完成了动态迁移。

　　处理器兼容模式存在缺陷

　　处理器兼容模式看起来像是解决了处理器不兼容的问题，但存在缺陷：只能够在同一系列的处理器之间进行动态迁移。你不能够在Intel和AMD处理器的主机之间进行动态迁移。然而，你能够使用这一模式在同一厂商或者同一系列的不同时期的CPU之间进行动态迁移。

　　这一模式截断了CPUID指令这样就掩盖了实际的CPU识别过程。反过来说，采用这一模式禁用了一些能够提升处理器性能的特性。如果你在使用VM进行多媒体或者高性能计算，或者说VM在执行CPU密集型加密运算时，微软建议不要使用处理器兼容模式。

　　为了启用处理器兼容模式，你必须关闭VM然后重启。在某些情况下，你可以将已关闭的VM迁移至目标主机上。事实上，在这种情况下处理器兼容模式就不是必须的了。

　　Hyper-V版本不匹配，iSCSI不兼容以及网络连接缓慢

　　故障转移群集中不匹配的Hyper-V版本可能导致动态迁移失败。集群可能由多个Windows Server版本组成，只要是每个Windows Server的副本属于同一个发行周期即可。例如，你不能在一个故障转移群集中混合Windows Server 2008以及Windows Server 2008 R2，因为Windows Server 2008中的Hyper-V不支持动态迁移。

　　ISCSI不兼容同样可能会妨碍动态迁移的完成。在Windows Server 2012发行以前，动态迁移需要使用集群共享卷（CSV）。CSV能够通过FC或者iSCSI进行连接。如果你选择使用iSCSI，那么目标主机必须符合iSCSI-3规范，因为动态迁移要用到iSCSI-3规范中的持久性保留特性。

　　最后，只有网络连接带宽不低于1Gb时才能支持动态迁移。虽然从理论上说在带宽更低的物理链路上也可能能够完成动态迁移，但是微软并不支持这样做。

　　很多不同的因素都可能导致虚拟机动态迁移的失败。学习并了解了可能会遇到的导致虚拟机动态迁移失败的这些最为常见的问题，那么你最好能够避免这些问题的出现。