如今，写一篇关于文章赞成或反对虚拟化是很危险的事情，部分原因是在过去几年中，正反双方在虚拟化管理软件上进行了激烈且刻薄的争论。然而，不管您在争论中支持谁，最终都要管理和维护现有的虚拟化管理软件，对于这一点您无法改变。

　　随着微软Hyper-V的推出，最引人关注的管理解决方案就是微软的系统中心虚拟机管理器(VMM) 2008 R2（ System Center Virtual Machine Manager 2008 R2）。对于管理员来说，该版本的虚拟机管理器功能上并没有太多的改进。当然不可否认的是，VMM 2008 R2中增加了对实时迁移、各种网络优化功能和集群共享卷的支持，以及其它一些功能。 但是这些所谓的“新”功能其实只是Hyper-V R2自身升级的体现。

　　即使有了这些升级，管理员们仍然觉得，VMM 2008 R2在一些已经占据优势的关键方面管理能力依然不足。让我们来看看管理员们（至少我是如此）希望能得到更多支持的四个方面。

　　Dead simple主机集群：我赞成和支持微软的决定，依靠微软现有的Windows 故障转移集群服务来集成Hyper-V主机到一个集群中。即使是该服务开始的时候非常糟糕，但是这个服务已经发展成具有广泛用途且产品化的集群解决方案。使用该解决方案，您可以集群许多不同的Windows服务器角色来增加正常运行时间。

　　在VMware中使用SCVMM

　　系统中心虚拟机管理器也能用于管理VMware虚拟机。详情请访问虚拟化专家Mike Laverick的文章《用SCVMM管理VMWare虚拟机的绝妙之处》。

　　然而，这种“为所有人提供所有服务”的方式也使得Hyper-V主机集群变得过于复杂，这没有必要。对于大多数Hyper-V的部署，这是个极大限制；复杂的施工要求和太多的问题，集群Hyper-V主机简直就是一个极其困难的过程。

　　微软已经看到了在Exchange Server 2010 中使用数据库有效性组（DAG）工具包装传统集群界面的价值。 使用dead simple界面，就可以很容易创建一个DAG。 但是大多数人没有马上认识到DAG其实就是一个变相的Windows 故障转移集群，在一个简单的界面后面隐藏了所有复杂的集群配置。

　　Hyper-V主机集群配置应该尽可能简单。所以，在微软在Hyper-V集群上使用相同方法之前，我恐怕不会使用Hyper-V。

　　Dead simple主机和客户监控。这是个监控虚拟机的全新办法，它表示应该放弃使用基于百分比的监控指标（如%处理器时间）。这个方法告诉我们基于整数的指标事实上是一个衡量虚拟机性能（如1150MHz处理器需求）的更有效方法。依靠整数而不是百分比来测量虚拟机性能，只需简单相加就可以计算出一个私有云的资源供求关系。当然，其它一些临时因素也会影响性能，但是，通常情况下，虚拟服务器的性能效率随着时间的推移会符合一个可预测的稳定状态。

　　我也理解并尊重微软的决定， 卸载VMM的深层次监控并移植到系统中心操作管理中（SCOM）。这样做的目的是使企业的SCOM基础架构能以更统一的方式处理虚拟环境的监控。然而，问题就在这样的整合和系统本身。简单的把微软的SCOM监控功能用于Hyper-V，这样做缺乏真正理解虚拟机性能的深度视角。 进而，他们无法理解资源需求关系数据，可能导致功能管理假死（dead simple）。最大的挑战就是整合过程本身，把两个独立的解决方案（VMM和SCOM）简单地放在一起，感觉不像是一个统一的解决方法，而更像是强凑在一起。

　　在之前，我一直认为简单虚拟化技术向商业化的私有云计算发展将要求更为详细的虚拟机活动监控，而且应该以管理员日常管理的行为方式呈现这些监控信息。

　　集群感知(Cluster-aware)负载均衡。不久前，我曾经疯狂地研究虚拟机管理器（VMM）（捆绑了SCOM专业工具）有关决定集群负载的逻辑原理。但是，我几乎一无所获。

　　在竞争中，微软有一些长期优势，这意味着他们有足够的时间为其部署和添加这些必须的功能来完善其产品。

　　下篇文章中，我们将继续分析还有什么功能是用户期待在VMM 2008 R2中见到的。