解读三种虚拟化之路连载三：虚拟化技术趋势

最新推荐文章于 2024-11-13 17:24:18 发布

weixin_34352005

最新推荐文章于 2024-11-13 17:24:18 发布

阅读量123

点赞数

文章标签：运维操作系统数据结构与算法

本文链接：https://blog.csdn.net/weixin_34352005/article/details/85025793

版权

本文探讨了虚拟化领域的几种主要技术趋势，包括通过BT实现的全虚拟化、硬件辅助虚拟化及半虚拟化技术。其中，BT支持下的全虚拟化目前仍为主流；硬件辅助虚拟化虽面临挑战，但其未来发展被看好；半虚拟化技术则因其维护成本问题受到质疑。VMware提出透明半虚拟化接口VMI，旨在平衡性能与维护成本。

摘要由CSDN通过智能技术生成

1. 通过 BT 实现的全虚拟化今天仍是主流 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

BT支持下的全虚拟化目前仍然是主流，是今天就可以部署的最可靠的虚拟化技术。VMware的虚拟化也在Windows和Linux操作系统环境下提供最高的性能，同时提供了丰富的企业级功能和管理性。通过 BT ，除了在 Intel CPU 上不支持 64 位的客户操作系统， VMware 可以在生产环境下支持全虚拟化和硬件辅助虚拟化，并且性能良好。

BT 支持下的全虚拟化在未来的几年内将继续保持良好发展势头，不需要更改操作系统，通过高级 BT 来提高性能。当然，硬件辅助虚拟化也将慢慢走向成熟，推进虚拟化性能不断提升。

2. 硬件辅助虚拟化是未来方向，但是目前性能仍然没有达到预期

去年 Intel 和 AMD 发布的硬件辅助虚拟化硬件辅助虚拟化的第一步，通过硬件辅助虚拟化，可以移除 BT 或对操作系统的修改。就像 Xen 利用的那样， As Xen has 这些初期的功能将建立 hypervisor 变得简单了很多，再也不需要借助 BT 或者修改操作系统了。 Xen 利用这些硬件辅助功能来实现 Windows 虚拟化，但是性能很差，远不如 VMware 的 BT 虚拟化或者 XenLinux 的半虚拟化。第一代硬件辅助虚拟化部署了苛刻的编程模式，将 hypervisor 到客户操作系统的损耗大大提高了，这使得第一代硬件辅助虚拟化的性能低于 VMware 的 BT 虚拟化实现。 VMware 正在同 Intel 和 AMD 一起努力，来增强未来硬件虚拟化的设计，进一步提高硬件辅助虚拟化的灵活性和性能。

第二代的硬件虚拟化将提供更高的性能，大大降低虚拟化损耗。 AMD 和 Intel 都已经发布了他们的产品路线图，包括硬件支持内存虚拟化 (AMD NPT 和 Intel EPT) 和硬件支持设备和 I/O 虚拟化 (Intel VT-d 和 AMD IOMMU) 。

计算密集的负载已经可以通过 BT 运行在虚拟化平台上，部署 NPT/EPT 将无需影子页表，而影子页表直接消耗系统内存，为此进一步显著改善虚拟化性能。将来的CPU对虚拟化支持进一步增强，这将推动硬件辅助虚拟化的广泛应用，但不要期望革命性的变化。处理器在进行着快速的升级换代，处理器速度的提升对虚拟化密度和性能的影响预期将远高于硬件辅助对虚拟化的优化。

半虚拟化技术的进步预期不会带来性能进一步巨大提升，而硬件辅助虚拟化的深化，将通过对 CPU 、内存和 I/O 的虚拟化，预期会有很大的性能提升，而未来的 hypervisor 将会普遍支持硬件辅助虚拟化，也就是说硬件辅助虚拟化将成为 hypervisor 的默认配置，从而带来虚拟化的性能、管理性的进一步改善。

3. Xen 的 CPU 半虚拟化带来了性能优势的同时，增加了维护成本

Xen 经常将半虚拟化定位为第二代的虚拟化，而将 VMware 的虚拟化技术标记为第一代虚拟化技术。实际上，半虚拟化是很老的、有用的虚拟化技术，它可以为某些负载带来很好的性能，但一般都会增加维护成本。我们不否认在客户操作系统里安装虚拟化管理应用和设备驱动能提高虚拟化性能，但是数据中心用户必须清晰认识到半虚拟化的性能优势和运行修改过的客户操作系统而花费的大量维护成本之间的厉害冲突。半虚拟化带来的性能提升依赖于运行的负载，大多数用户应用可能因此性能提高很少，很少情况下能达到接近物理机的性能。

Xen 的第一大挑战就是处理器的半虚拟化不能支持未经修改的操作系统，很多情况下就不能使用这种方式，比如操作系统本来不允许修改（如 Windows ），或者有时候需要某种特定版本的 Linux 。实际上，大多数的数据中心都不愿意将自己的生产应用运行在开源 Hypervisor 上修改过内核的 Linux 操作系统中。另外，大量的内核修改会导致客户操作系统和 hypervisor 之间的数据结构依赖性，该操作系统因此会没法运行在其他的 hypervisor 或裸物理机上。

尽管很多 Linux 版本开始将半虚拟化捆绑到操作系统内核里，部署使用半虚拟化操作系统的服务器仍然会增加维护成本和降低灵活性。就象很多公司已经发现半虚拟化的 XenLinux 不适合企业级应用，许多虚拟化厂商基于开源 Xen 而开发的虚拟化产品本身已经放弃了 Linux 半虚拟化。比如 Virtual Iron ，他们已经声明半虚拟化走向死亡，已经专注基于硬件辅助的全虚拟化开发，来支持未经修改的操作系统。

这导致了 Xen 的第二个竞争挑战。 Xen 3.x 最近紧紧引进了硬件辅助全虚拟化来支持未经修改的操作系统 ( 比如： Windows) 。 VMware 的 BT 技术十分复杂，性能远高于 Xen 第一代的硬件辅助全虚拟化， Xen 厂商完全没法和 VMware 竞争，包括性能、可靠性、易于管理等方面。但今天经常引起一些误解：很多厂商说他们的 Linux 半虚拟化性能优势明显，而很多用户认为他们可能并不需要修改操作系统内核，其实这是非常错误的。

当然， VMware 也发现对于某些特定的负载，处理器的半虚拟化确实可以大幅提高性能，但是等到第二代硬件辅助出现之后，半虚拟化的性能优势还很难说清楚，性能提升可能会下降、甚至消失，这已经成为一个悬念。

在 VMware 看来，处理器半虚拟化的最大问题是对操作系统的修改，这会导致该操作系统对特定 hypervisor 的依赖性。对于 Xen 来说，部署深度半虚拟化将带来对 hypervisor 的极大依赖性，操作系统的内核紧密链接到 hypervisor 的实现，这带来严重的兼容性问题，因为此时的 XenLinux 不能在其他的 hypervisor 上运行，甚至根本没法直接运行在物理硬件上，从而导致必须维护更多的 Linux 版本。另外，半虚拟化只适用于新的、开源操作系统，因为对操作系统内核的修改需要操作系统厂商的支持。最后，对 hypervisor 的依赖性会拖累该操作系统内核的更新。

4. VMware 的透明半虚拟化可以平衡性能优势和维护成本

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />

图 1. 通过 VMI 实现的透明半虚拟化

Xen 致力于部署修改 Linux 内核的半虚拟化的时候， VMware 正在致力于标准接口的建立来应用操作系统辅助半虚拟化的同时，使得操作系统维护成本不至于增加很多。 2005 年， VMware 提出了透明半虚拟化接口 VMI （ Virtual Machine Interface ，虚拟机接口）的建议标准，建议将 VMI 作为客户操作系统和 hypervisor 之间的标准通讯接口。

如图 1 所示， VMI 是位于 hypervisor 和半虚拟化操作系统之间的接口层，透明半虚拟化保证了同一半虚拟化的操作系统内核可以运行在任何兼容的 hypervisor 或物理裸机上。它从设计上将所有的 VMI 调用分成两类，直接内部指令用于裸设备访问，间接调用客户操作系统和 hypervisor 之间的 VMI 层，两种方式都确保了性能优异，同时维护性和扩展性也通过 VMI 的独立性来维持。由于 VMI-Linux 可以运行适当版本的间接层，使得 VMI 层可以支持不同的 hypervisor 。

VMware 继续和 Linux 社区保持很好的沟通，一起来开发半虚拟化接口，以支持多种不同的 hypervisor 。 2006 年， VMware 发布了开源 VMI 规范，在渥太华 Linux 大会上的 VMI 建议推进了 Linux 社区 paravirt-ops 接口的开发。 paravirt-ops 接口规范由 IBM 、 VMware 、 Red Hat 和 XenSource 组成的联合小组共同开发，它包含了很多 VMI 里面提出的概念，来支持透明半虚拟化。通过这个接口，半虚拟化的 Linux 操作系统可以运行在任何兼容 paravirt-ops 接口的 hypervisor 上。 VMware 积极致力于 paravirt-ops 客户操作系统接口的开发，从 Linux 内核 2.6.20 开始， paravirt-ops 已经成为官方 Linux 内核的一部分。版本 2.6.22 内核也包括了 VMI 后端来补充 paravirt-ops 接口。通过这个同一的规范， Linux 操作系统厂商和 ISV 都只需要支持单一的内核，虽然进行了半虚拟化，但是没有影响性能或者可维护性，这将大大改善半虚拟化的兼容性。

为了让业界体验这个规范， VMware 在 Workstation 6.0 里已经开始尝试性支持 VMI ，在寄居架构支持半虚拟化的操作系统。该版本的 Workstation 实现了从 2005 年开始和 Linux 社区讨论的透明半虚拟化接口。你也可以下载完整版的 VMware Player 虚拟机监控器，它也可以支持主流厂商的半虚拟化 Linux 内核。 VMware 想通过 VMware Player 和 Workstation 里对半虚拟化的尝试性支持，来让开发人员感受 VMware 的半虚拟化技术实现。

由于这次尝试性支持是基于寄居的虚拟架构，因此并不是来演示半虚拟化的性能，但它可以演示大量消耗 CPU 负载性能的提升。接下去 VMware 将会在我们的 hypervisor 产品上支持半虚拟化，到那时能就可以尽情体验基于标准的半虚拟化带来的 CPU 和 I/O 性能的提升。等到半虚拟化操作系统正式投入商业应用， VMware 就会在所有的虚拟架构产品线上支持半虚拟化的操作系统。

5. VMware 通过多模式 VMM 架构来确保性能和灵活性

很多虚拟化公司由于资源的限制，他们的产品都只支持一种虚拟化战略。他们一般都专注于自己的虚拟化实现优势，而很少考虑自己的劣势和功能缺陷，这因此产生了很多的误解。而 VMware 作为业界翘楚，所有的产品都将各种新的虚拟化技术整合在自己的产品中，以平衡性能、可靠性、功能性和易于管理性。同时， VMware 也和业界伙伴紧密合作，不断开发完善虚拟化的生态系统

图 2. 多模式 VMM 架构

VMware 提供了灵活的多模式 VMM 架构来支持每个虚拟机，如图 2 所示。 VMware 可以根据不同的负载来选择不同的模式来达到最优性能。在 VMware 的产品线中应用了同样的 VMM 架构，包括 ESX Server 、 VMware Player 、 VMware Server 、 Workstation 和 ACE 。

今天的负载可以通过 32 位的 BT VMM 、 64 位的 BT VMM 或者 VT-x 来实现，从而获得性能最优化，将来的负载将可以运行在同时支持 AMD-V+NPT 和 VT-x+EPT 的 32/64 位的 VMM 上。 VMware 提供了灵活的架构来支持新的虚拟化技术，而多模式的 VMM 利用了 BT 、硬件辅助和半虚拟化技术，针对不同负载和处理器的组合来选择最为合适的运行模式，从而达到性能最优化。硬件辅助将逐渐走向成熟，并将广泛支持各种不同的负载。

6. 结论

实际上， VMware 正在尝试不同的虚拟化技术来提升虚拟化性能， BT 、硬件辅助和半虚拟化都是比较有效的 x86 虚拟化技术，但是他们的价值和重要性仍然在变化中。 VMware 从 1998 年开始引领虚拟化的革命，到今天为止仍然继续引领虚拟化业界和标准的发展。未来虚拟化的将会出现基于标准的半虚拟化实现，半虚拟化的操作系统应该可以运行在不同的 hypervisor 平台或物理裸机上，通过硬件辅助来管理 CPU 、内存和 I/O 设备，从而在提升性能的同时，确保兼容性和可管理性。