【IT168 专稿】在上篇，我们总体介绍了三大虚拟化环境管理工具的各自的优劣势，并详细介绍了VMware虚拟化管理软件的诸多特点，本文将接续上篇，对微软的虚拟化管理软件MVS，以及Xensourse的虚拟化管理软件的优势与不足作深入的剖析。参考：评测：三大虚拟化巨人管理软件之战
通过评测我们认为：尽管VMware的表现相对较好较成熟，但严格来说，这三款虚拟化环境的管理工具都还存在一些需要改进的地方。下面让我们看看其他两款虚拟化管理工具的评测表现。
微软虚拟化工具：未来将融于windows server 2008
大部分微软的虚拟化产品在未来一段时间都围绕着Windows 2008 服务器版本的改变而变化，这些虚拟化设备的基础架构也将变成操作系统的整体。微软目前的虚拟化设备架构将转变成一个主机的管理程序，这个架构也是Windows 2008服务器版本的核心支撑。
一个大体基于Windows 2008系统的管理程序将变成一个依附于客户机操作系统的管理平台。与XenSource的兼容性仍将是微软重做虚拟化服务器的定期目标，这二者将要求具备64位的主机来提供虚拟化设备平台。
这些都是未来的发展规划，就目前而言，微软更接近于通过MVS 2005 SP1的服务器内置虚拟化设备作为硬件平台虚拟化的基础。微软提供了很多的方法在2003获得了客户机和服务器虚拟化设备的连接，目前应用于他提供的虚拟机和服务器之间。
微软的MVS 2005的使用还是有些让人头疼。他简单管理镜像的能力比较缺少，它只能管理很少的虚拟化设备主机。信息鉴识的完成也非常不简单，并且原始的镜像建立仅仅是半自动的，而且要求在安装客户机通过微软系统管理服务器操作系统之后。
微软SC-VMM：细节丰富的管理工具
微软的SC-VMM是在这个月早些时候推出的，它可以管理MVS的部署，也可以管理WSV的组件。我们测试了SC-VMM的一个小版本。这种应用的商业价值是巨大的，GUI控制台列出主机、虚拟化设备、镜像和资源库以及监控工作等等。主机和虚拟化设备能够通过视图收集信息，并且能够收集例如移动镜像、监察设置和处理器特性等信息。SC-VMM同时具备命令行接口CLI和托放接口来帮助控制移动、添加和改变个别的和组的虚拟化设备。
管理的动作能够代表身份鉴别、用户角色定义。像VirtualCenter, SC-VMM都可以通过数据库跟踪全世界任何地方的微软虚拟化设备，并且数据库本身会被存储在一个客户机操作系统上。
SC-VMM并没有隐瞒对同步虚拟化设备物理镜像的修改能力，虚拟化设备的物理镜像也就是我们通常那个所说的虚拟硬盘（VHD），在微软的说法中，他们并没有鉴别它们，也没有一种合适的方法对VHD或者生产客户机操作系统进行打补丁或者修复一些错误。
我们同样测试了SC-VMM平台从物理设备到虚拟设备的转换特性。在这个过程里，SC-VMM首先把一个工作服务器包装起来，然后发现其内部可用的资源，包括文件和应用程序，然后选择一个候选虚拟化设备主机，找到适合镜像作为一个目标存放的地点。然而，数据的使用常常不是很久和历史性的。代替它的是一个满足条件的快照，所以如果这个条件相对发生变化，这种启发式快照的应用往往能够或者不能够完全替代这个镜像。
这个从物理设备到虚拟化设备的方法使得微软的全部虚拟化设备获得了很多的经验，过程也不那么让人感到乏味。哪些是看不见的？尽管这个方法冻结了整个过程并且给出了一个可以被识别和鉴别的VHD。
根据它对信息鉴识的能力，微软的SC-VMM具备丰富的细节。如果全部的主机服务器崩溃，那么在系统全部崩溃之后通过MVS 2005我们能做的微乎其微，我们只能通过信息鉴识的分析看到所发生的一切。如果想分析出设备是如何崩塌的，那还要借助日志分析和其他的工具。
XenSource XenEnterprise 4：正在迅速成熟
Xen最初获得强大功能是通过超虚拟化技术“paravirtualization”的方法实现的，这是由于两年多以前SLES 9的开始使用，而包含Xen的SUSE Linux 企业级版本的服务器也使得Novell的得以普及。
我们感受并回顾了一下在SLES 9上运行Xen程序，结果显示它并没有准备好在实验中的使用。我们发现Xen虚拟化设备的建立、移植、管理和控制非常困难。
较老的，使用paravirtualization方法的Xen的版本3过去常常用在一个主机操作系统上，它的内核针对于虚拟化已经作了重新修改。自适应的Xen客户机操作系统装在已经修订的内核/主机操作系统之上。
客户机操作系统不停的运转所有组件（外围驱动器、GUI和其他加强的CPU管理事务），因此内置Xen的构造只能在理论上对客户机操作系统的使用效率有所增强。
Xen正在迅速的成熟，并且，它已经在今年早些时候包含在Red Hat Enterprise Linux 5投放市场，我们发现它越来越强大。我们的很多异议都通过它的强大而变得缓和，它主要改进了安装、配置和管理等行为。
XenSource已经在今年8月份以5亿美元的价格被Citrix收购，巧合的是，这天正是VMware成功首次公开募股的第二天。
Xen虚拟计划开始于一所大学，并且对大家的吸引力迅速增长，尤其是它为超虚拟化技术（paravirtualization）的先进性做好了很好的证明。XenSource，通过Intel和其他厂商投资的半成品，在商业层次发展，因为相对于不太友好的基础组件和依附于额外内核的开源Xen的发展（同许多厂商联系在一起）。
这个结果也表明了XenSource的商业层次，随着Xen内核—虚拟化组件的迅速发展，带来了很多能够通过VMware完成的和通过微软连接获得的服务器组件的一些新特性。
最新版本的XenEnterprise 4使用64位的管理程序内核和自适应的Xen主机和兼容性良好的客户机（包含许多版本的Linux和Solaris，也支持较老的系统版本，目前也将很快支持Windows 2008版本）。微软和众多的分布式Linux厂商都已经宣布或者已经采购Xen自适应的服务器和分布式客户端错作系统。
XenSource XenEnterprise 4：有限的新特性
像VMware ESX一样，XenEnterprise 4列表的附加软件和附加项非常多，XenEnterprise提供强大的附加软件XenCenter，这个应用程序能够管理服务器和虚拟化设备的池。XenSource目前宣布XenCenter的一些基本模块已经开始投放市场。
Unix/Linux的管理员将会发现很多类似于以前管理员非常容易理解的选项。相关文件也几乎包含了所有物理虚拟化可用的实例。但是这些都没能阻止我们对它一些虚拟化能力积极的测验，我们把它安装在SUSE SLES 10系统上进行了一次测试。
我们创建了非常容易管理的资源池，尽管我们非常沮丧的看到这个新特性要求了很多的条件，例如同类型的客户机操作系统虚拟化设备，这样我们才能看到我们期望的控制特性。
有一个非常容易的方法能够把一个开源的虚拟化设备移动到XenSource虚拟化设备。这就好像是设备必须重新回到物理实体，然后把物理服务器经过修改转换成虚拟的设备，重新投放进XenEnterprise的管理。
这种向后兼容的问题意味着从老的Xen安装程序到新的XenEnterprise需要做大量的工作。XenCenter并不提供任何自动化的方式来处理这部分过程。从XenSource Xen 3.0升级到Xen 4.0同样要求一个中间的过程，把Xen 3.0先转换成Xen 3.1。一个系统如果这样移动的话大概需要不到1小时的停机时间。
XenCenter具备一个可用的、基于Java的GUI控制台来做这些基本的工作，例如从一个具备条件的物理服务器建立一个虚拟化设备。然而，很多地调整也必须由命令行接口CLI工具来完成，它不能通过GUI完成。在这方面，XenCenter最不令人满意。
修改的同步处理、镜像鉴定、审计和跟踪、补丁和修复的控制，还有用户角色的定义和策略—这所有的要点都是我们在一个虚拟化设备管理过程中需要作的工作—在XenSource的XenCenter里都显得有些缺乏。对于它来说这所有的都是新的内容，像LeoStream公司也作为XenSource的合作伙伴来共同开发这些附加的基础组件。
通过三个管理计划的测试，XenSource的界面非常的成熟，但是它的向前移动是跳跃的，并且每次都需要在开源组件移动之后，它像VMware曾经的一样，进军商业领域。
总结：都需要进一步改进
事实上，所有这三家厂商都具备一个CLI或者非常强大的命令控制台，通过这个我们来改造体系架构和完成许多动作，这些都是GUI不能完成的。对于这三个产品，XenSource的GUI是最不令人满意的：我们必须按部就班的查阅命令行选项来做一些连接可用的Xen虚拟化以太网交换机或者连接客户机到主机应用程序网络资源的工作。
从这三种软件横向比较看，从它们各自建立和部署虚拟化设备实例的过程，我们发现我们对这些基本产品的测试也变成了相当漫长的过程。它们针对虚拟化设备产品的共同趋势是在基本模块基础上增加相应的模块选择。这些可选择的模块可以帮助我们实现管理的自动化。
作为一个组织，这些厂商一直争论着他们的广泛、全面性，但是我们发现他们在应用有效性、备份程序、安全和认证、近似于镜像管理和镜像建立资源、补丁和同步修复、审计主机操作系统等领域大部分都缺乏关键的管理特性，
但这些管理工作的每一个都成为所有这些虚拟化设备平台厂商需要提供的列表中功能时，我们不希望看到应用的建立是处在一个风险很高的境地。我们下一轮测试将检测这些软件是否具备有效的第三方的虚拟化设备管理产品，而这些产品可以确实的解决目前存在的这些问题。
