在你的环境中引入第二个Hypervisor，需要仔细计划和测试。第二个Hypervisor必须和现有的一样，完全支持预期的服务器硬件平台、设备驱动和操作系统版本，当然还有应用程序。使用双Hypervisor会有什么风险呢？需要怎么解决？

　　如果已经有一个第三方的Hypervisor管理工具，必须查清它与新Hypervisor的兼容性。如果同样的管理工具可以同时掌握两个Hypervisor，就可以简化管理进程了（点击图片放大）。

　　图1：一系列的事件可能会导致Hypervisor难以进行系统管理。

　　首先要查看新Hypervisor的兼容性表，必须得拿着表亲手在环境中操作。在服务器级做好开始的测试之后，把测试范围扩展到应用程序负载下的整个网络和存储兼容性。

　　需要Hypervisor的学习周期

　　测试Hypervisor能给IT部门机会来精通安装和管理。两个Hypervisor是相似的，但是有必要了解两者的不同，才能消除困惑，更快掌握配置。那些对现有Hypervisor熟练的人员才是最容易精通软件的，因为有实际操作经验。

　　虚拟化早期，IT工作站安装平台在多种服务器在按需分配的基础上，Hypervisor出现。现在，这个安装进程更加正式，主要是因为已经有Hypervisor用上了，所以知道在哪里安装第二个Hypervisor特别重要。

　　另一个因素是购买多种Hypervisor的公司通常足够大，可以在新平台配置上对形式和记录的级别做出要求。在动态数据中心、私有和公有云上，通过高级别的主动权来执行。IDC企业虚拟化软件调查经理Gary Chen说：“我们打算一步步执行审查步骤。”

　　什么时候适合开始？

　　什么时候从一个Hypervisor换到另一个？这可能会比较模糊。很少会有一个单独的契机来触发平台转换。合适的时机，是基于每个公司的唯一需要和情况。比如说：如果成本是初级的驱动力，那么转换的时机可能仅仅管理者觉得合适了。

　　另外一种情况，契机可能来源于对新功能和服务的需要，这些是旧的Hypervisor提供不了的。新的Hypervisor也许可以提供服务级的协议需求。重要的是了解需求，这些需求可以促成第二个Hypervisor的到来，除此之外还得考虑时间或其他能把新Hypervisor引入的情形。

　　现在，Hypervisor已经发展成完善、稳定、可靠的软件平台，但是记住风险也会向新的Hypervisor迁移。最大的风险是，管理层迫使IT部门购买与原来平台根本不一样的Hypervisor。如果没有足够时间给管理者测试和掌握新的工具，或者如果直接放弃了旧Hypervisor的功能和特征，恐怕会有潜在的危机。

　　另外一个风险是孤岛。比如某个公司的windows部分购买了一个Hypervisor，同时该公司的linux部分购买了另一个Hypervisor。这种分离Hypervisor的做法导致优化IT失败。“现在的人期望私有云迁移，而使用单独的资源池则与之相反。”