这个系列的四篇文章主要集中在改进Hyper-V集群的性能问题上。文章一主要涉及关于固件（firmware）、驱动、路径和补丁对虚拟主机集群稳定性的影响。文章二提供了两个帮助我改进了虚拟环境稳定性的实用技巧。本篇，也就是第三部分，我将进一步讲述一些解决Hyper-V集群性能问题的方法。

　　Hyper-V集群性能问题之三：GUID（唯一标识符）变化

　　由于工作负载的自然增长，对于虚拟机所在的LUN（logical unit number）大小做调整，是时常会发生的需求。在调整了Hyper-V集群中的一个LUN大小之后，它所在卷的唯一标识符（GUID）也发生了变化。这将会导致Quick Migration发生问题，而且会在System Center Virtual Machine Manager (SCVMM)中看到"unsupported cluster configuration"的故障提示。

点击图片本身就能放大

　　这个问题出现是由于LUN的volume GUID 发生变化以后，Hyper-V的相关配置中仍然保留着原来的卷唯一标识符（GUID）

　　多数情况下，虚拟机可以在集群中的某个节点上很好地运行。然而当我们试图把虚拟机迁移到其他节点上时，会发生无法加载LUN的问题。最后的结果是，虚拟机又返回到了迁移发生之前的节点上运行。

　　在虚拟机进入这种状态后，我发现了一个很管用的应急方法，这个方法包括关闭虚拟机和使用cluster.exe命令来重新注册虚拟机的配置变化。我曾经使用这个方法成功解决了一些问题。通常，我从Failover Cluster Manager中停掉虚拟机，然后从Hyper-V Manager中将它删除，最后再重新分配虚拟机（将其指向新的卷标识符GUID，并挂载原有的虚拟机文件-Virtual Hard Disks）。我的这个方法虽然需要重新配置虚拟机的网络设置，但是它可以使虚拟机运行起来。

　　想要避免这种情况重复发生的话，请在每台Hyper-V集群的节点上安装KB970529补丁。这个补丁可以解决GUID变化的问题，之后您将无需使用如上的应急方法来修复。但是，不幸的是，这个补丁无法修复已经发生问题的虚拟机。

　　（请注意：我在删除虚拟机时使用了Hyper-V Manager而不是SCVMM，因为Hyper-V Manager不会删除虚拟机硬盘文件）

　　Hyper-V集群性能问题之四：IT系统管理员错误

　　有一些Hyper-V集群的性能问题不是由于供应商的问题或者是突发故障导致的。有些时候，会发生IT系统管理员的操作失误问题，这时我们需要站出来并承担相应的责任。

　　在Hyper-V R1中，对Quick Migration有大量的复杂应用需求，诸如需要为每台虚拟机分配LUN。在我的一个集群中，有超过100台的虚拟机。这意味着系统中存在超过100个不同大小的LUN。而且，每个LUN都可以被六个不同的节点访问，也就是说虚拟机的LUN可以挂载给这六个中的任意一个节点使用。

　　假如发生了这样的问题：所有的节点都无法访问某个LUN。我就曾经遇到过，有一次多台虚拟机都无法迁移到一台特定的主机上。而且这是一台全新的主机，所以我想这可能是由于固件或驱动问题导致的。当一台虚拟机被设置为save状态，然后再卸载硬盘，如果这时集群系统试图把LUN迁移到其他节点运行，这个操作会失败并且会跳转到其他的集群节点执行。

　　在检查了固件和驱动程序之后，我检查了服务器的配置。最后，我发现我忘记了把旧的已经存在的虚拟机LUN分配给这台新的主机。而且由于在LUN和虚拟机之间没有光纤通道链路，新的节点无法直接加载这个LUN。幸运的是，这个问题已经可以通过Hyper-V R2的Cluster Shared Volumes (CSV)或者某个第三方的产品，像Melio FS,来解决，因为这些解决方案都不依赖于每台虚拟机分配一个LUN的架构实现。然而，除非有一种产品可以覆盖我所想到的所有问题，否则在发生变化后，仔细地分配并重新确认所有的虚拟机集群环境配置才是有效预防管理员人为错误的方法。

　　总的来说，在Hyper-V集群为虚拟环境带来更好的稳定性和灵活性的同时，也同时需要面临更高地环境复杂度问题。但是我认为，这样的交换是值得尝试的。但是前提是一定要能有效避免由于系统bug和系统管理员人为错误所带来的问题。另外，了解如何迅速地加强虚拟环境的稳定性也是一项需要不断加强的技术。

　　在文章四中，我将集中于解决一些不常见的虚拟网络相关问题，以及解释在什么时候适合采取一些大动作来修复虚拟网络问题。在那之后，如果您有任何问题，请及时反馈给我。