何时是考虑多hypervisor环境的正确时机?
增加另一个hypervisor背后最大的商业动机之一就是通过采用更加有利的许可协议解决虚拟化成本问题。虚拟化许可成本具备延续性，而且当需要虚拟化的服务器有成百乃至上千台时这些许可成本可能会变得非常巨大。向另一个家hypervisor厂商打开大门很可能会降低许可成本——或者至少能够为与主要的hypervisor厂商交涉以获取更好的许可证条款提供商务支持。
采用第二个hypervisor的另一个很常见的原因就是避免厂商锁定。尽管hypervisor都提供了相同的基本功能套件，但是每家厂商可能在服务与支持、许可条款、功能特性等方面存在很大的不同。依赖于虚拟化技术的数据中心可能会不断测试并试用大量的hypervisor以确保当商业或者技术场景随着时间的推移发生变化时组织已经具备了hypervisor转换的专业技能。开展上述工作能够预先避免如下情况的发生，即：直到拖到最后一刻才迫切地期望能够找到另一个替代hypervisor产品。
采用另一个hypervisor的另一个原因可能是为了使用当前hypervisor还没有提供的特定功能与特性(而且所需要的功能可能不在当前厂商的产品路线图中)。例如，如果一家公司计划构建私有云基础设施但是当前的hypervisor并没有提供该功能，那么第二个hypervisor可能被用于提供该功能但是却不必取代目前在主要使用的hypervisor。
在很少的情况下，采用另一个hypervisor可能被用于提升互操作性——用于虚拟化主要的hypervisor可能无法全面支持的某些硬件平台。
如何添加第二类hypervisor
对于任何主流hypervisor而言，不存在限制其用于数据中心的生产环境的技术问题，但是在生产环境中使用多hypervisor的组织却很少见。这主要是因为IT人员很难对混合虚拟化平台都足够熟悉，培训所有人员熟悉混合hypervisor的方法成本很高也浪费时间。例如，假设某台使用ESXi环境的服务器发生问题，但是值班的管理员仅熟悉Hyper-V环境(反正亦然)，IT人员此时可能无法满足生产环境的响应需求。
当在生产环境中部署第二类hypervisor时，通常限制在第二级别或不重要的工作负载中。因此，如果分发或问题解决的过程出现延迟，对生产的影响也很小或不存在。在很多案例中，第二类hypervisor通常用于生产环境之外的测试和开发环境。
相应的，企业部署第二类hypervisor可能在特殊任务或特殊站点上。例如，第二类hyervisor可能用于个别工作组或分支办公室站点。类似的，第二类hypervisor也可能用于容灾、桌面虚拟化的支持、私有云计算等等。
数据中心多hypervisor管理面临的挑战
考虑到现在虚拟化技术带来的先进功能，很奇怪hypervisor不能够和其它环境共存。最大的问题在于虚机之间不兼容。例如，安装Hyper-V的服务器不能加载和运行ESXi虚机，ESXi虚机需要在额外的vSphere系统中加载或迁移。
这样最大的风险在于成本和IT人员的负担。记住一点，即使第二类hypervisor的测试和评估的直接成本很低，用于企业的生产环境或其它地方可能需要购买授权。由于这样会影响到首选hypervisor可以运行的虚机数量，您可能会发现第二类hypervisor会危害批量授权的采购，实际上变相增加了虚拟化实现的成本。
另外，第二类hypervisor也需要管理，这就需要更为强大的管理工具。很可能已经有了第三方管理平台可以支持第二类hypervisor。如果没有，还需要购买新的支持多hypervisor平台的工具，或者再引入一个管理软件用于第二类hypervisor的管理。无论哪种情况，都意味着购买新的管理工具增加的成本。
除了管理工具的成本问题外，IT人员还需要面对掌握新的或第二种管理平台的挑战。很可能的是，需要IT人员花费一些时间来适应这种挑战。同时，虚机在分发、配置、保护和其它管理任务时一定会有新问题。而且专业员工的风险，当只有个别管理员掌握新工具的话，可能由于某些原因对应人员不在时会影响到整个管理行为。
来源：
