看起来我的上一篇文章“影响虚拟机性能的四大错误做法”已经在读者中引起了共鸣。在文章发表后，很多读者登录了我的主页question-and-answer forum，并提出了其他的一些Hyper-V系统中的常见错误做法。

　　本文将提及的四个问题被称为非常见错误，并非因为其不重要，而是因为相比之前的四个常见错误可能不太明显一些。接下来，TechTarget中国的特约虚拟化专家Greg Shields将讨论这些会影响Hyper-V虚拟机性能的非常见性错误。

　　简单错误一：在Hyper-V虚拟机上配置故障恢复

　　通过Windows Failover Clustering功能，Hyper-V可以支持虚拟机在发生故障后，从一台主机迁移到另外一台主机上。通过这种传统的集群技术同时也使我们在进行一些常见操作（如打补丁和重启主机）时，可以保持虚拟机在线运行。

　　Windows Failover Clustering 是一个非常强大的工具，可以帮助我们建立具备自动故障切换功能的集群架构体系，其最初是被设计用于建设一个通用集群系统的软件。正因为基于这样的一种出发点，其中很多的一些特殊管理功能都是为了满足一些特殊工作负载的需求而设计的，而这些功能在我们的Hyper-V系统环境中可能是毫无意义的。

　　例如其中的一项故障恢复（failback）功能，本身并没有什么问题，但是在使用时需要非常的小心。故障恢复功能支持当主机发生故障时,自动把虚拟机的工作进程分配给另外一台新的主机,在故障排除后再把进程切换回原先的主机中。

　　但是，如果切换过程重复发生，就可能会产生问题。在这个过程中，集群系统中的原主机状态在failure/success两种状态间不停地转换，而且每次状态发生变化时，都会试图把虚拟机在两台主机间来回地转移。这个过程就是通称为“跳跃（bounce）”的故障情形，这种情况的出现可能会导致整个虚拟机环境的崩溃。

　　在Hyper-V中，故障恢复（failback）在所有的集群系统中默认都是关闭的，而且通常在初期让其处于关闭状态才是我们推荐的做法。如果您希望启用这项功能，那么一定要把故障恢复（failback）的时间向后延迟几个小时。这样就可以有效地避免在您的虚拟机环境中发生跳跃故障的概率。

　　简单错误二：RAM可用假设

　　如果您现在正在考虑搭建一个Hyper-V集群环境，您应该阅读“如何为高可用集群Hyper-V系统选择合适的硬件配置？”这篇文章。

　　和其他的虚拟机技术环境中不同的是，Hyper-V不能支持内存过分配技术（memory overcommit ）。因此，当创建的虚拟机所占用的内存总数大于主机实际的物理内存时，您将无法启动虚拟机。如果您在分配完可用物理内存之后，尝试去启动另外的虚拟机，即使只是再多分配一台，结果只有一种可能就是返回错误提示信息。

　　如果在一台服务器环境中，这不会是一个大问题，因为所有的虚拟机启动过程都是由管理员人工管理的。在带有自动故障切换技术的集群环境中，这点就会变成一个很大的障碍。因此，搭建一个拥有足够的可用物理内存的Hyper-V集群环境就变得非常重要，只有满足这个条件后主机才可以成功的从发生故障的源节点切换到集群中的可用目标节点。这也就是说，如果在一个拥有两个节点的集群中，一半的物理内存必须预留出来；假如拥有四个节点，就意味着需要预留四分之一的物理内存，以此类推。

　　简单错误三：缺少支持CSV（Cluster Shared Volume，即集群共享卷）技术的备份方式

　　在Windows Server 2008 R2中，微软发布了一项称为Cluster Shared Volume的新技术。它基于现有NTFS格式文件系统基础上，为Hyper-V虚拟机提供特殊功能支持的技术。您可以把这项技术认为是R2版本的一个属性，使得分布在集群中的多个虚拟机可以同时访问一个共享的LUN。这项新技术解决了集群中的节点失效时，磁盘子系统也作为其一部分而无法工作的情况。允许必要情况下，虚拟机可以在一个LUN内无缝地迁移。
CSV技术面临一项潜在的挑战，那就是：很少有基于虚拟主机的备份产品可以支持。今天，甚至于微软的Windows Server Backup也无法实现支持。即使这样，还是有一些像Data Protection Manager 2010（仍然只有测试版本）这样的产品，可以实现对这种工作方式的支持。

　　简单错误四：对虚拟CPU的过度分配

　　今天，用户购买带有两个及更多物理CPU的服务器已经很普遍。拥有更多的CPU意味着多线程应用程序可以在多个CPU之间实现负载均衡。或者当其中一个CPU被某个单线程应用所占用时，还可以使用剩余的CPU来满足其他应用的需求。这就是为什么现在几乎所有的服务器都有至少两个甚至有时是四个或更多CPU的原因。现在的数据中心工作负载需要配备额外的处理器资源以满足性能以及可用性方面的需求。

　　在Hyper-V的虚拟化环境中，对虚拟处理器的分配方式是比较特别的。Hyper-V的虚拟机环境中的最佳做法是：在初期只为一台物理机分配一个单独的虚拟处理器，只有在需要的情况下才去分配额外的处理器资源。

　　虽然表面看起来增加虚拟处理器数量是一个很好的方式，但实际上这种操作反而会由于调度管理上引起的冲突而降低性能。当多个虚拟处理器被分配给虚拟机后，这些处理器必须通过调度管理的方式，把它们的使用情况跟实际的物理资源对应起来。假设两个虚拟处理器分配给一台虚拟机，hypervisor的调度程序（scheduler）必须等待对应的两个物理处理器都可用后再去分配虚拟处理器。当在多个虚拟机竞争处理资源时，每个请求的响应时间会变得比普通情况长得多。当物理处理器的个数少于所有虚拟机中分配的虚拟处理器之和时，情况甚至还会变得更糟。（关于这种情况为什么会产生，您可以参考文章Microsoft Developers Network site中的Measuring Processor Performanc部分。）

　　还有，请时刻谨记，管理程序（hypervisor）分配的虚拟处理器需要横跨服务器上所有可用的物理处理器。这样，虚拟处理器才可以充分利用所有可用的物理处理器资源。