容器和hypervisor长期以来一直被放在一起比较，但现在开发人员正在改变这种看法，寻找某种方法能把这两种技术的能力融合在一起。
绝大多数有关容器和hypervisor这两种虚拟化核心技术的讨论，都突出强调两者字面上的特点区别。这种思路想要将这两种技术对立起来，将容器与hypervisor做对比，仿佛两者间存在一场战争，直到一种技术彻底压倒另一种技术。
而现实中，除了两者的冲突外，还有很多问题值得讨论。容器与hypervisor的对比并不应该成为一个问题。事实上，容器和hypervisor将可能会一直并存甚至融合在一起。
容器的重要特点在于它不需要对操作系统进行重复多份镜像，而在hypervisor虚拟化中每台虚拟机都需要一个独立的操作系统镜像。显然，这意味着日常运行开销需要的内存要少得多，更多的存储空间也可以被释放用于应用程序及其数据。
这些在内存和存储空间上的增益并不小。在一台使用容器的服务器上，运行的实例数可达到hypervisor的三倍。一些特例中，例如所有虚拟桌面完全统一的环境中，这种增益可达到10倍之多。从另一个方面看，给定工作负荷所需的服务器数量显著减少。软件授权也会受到影响。每个服务器上一个软件将只需要一个授权。因为软件变成了共享镜像的一部分，这种增益也延伸到了软件上。
容器能够提升性能和安全性
容器还带来其他效益。它启动的速度快于hypervisor实例，主要是由于它的镜像不需要从scratch分区上重载。容器用的镜像更便携，更容易构造，带来使用过程中的便于部署和灵活性的优势。而且，一些对比评分系统一致显示容器在性能上优于hypervisor，完成相同的工作容器所需时间有15%的优势。
存在这么多优势，我们有理由好奇，除了工业界的保守应用以外，为什么容器还没有完全取代hypervisor。毕竟，Docker容器引擎在容器工具领域正在占据主导地位，而且这项技术基本上是没什么问题的。
容器技术非常新，而且正在快速发展中。而另一方面，hypervisor技术是成熟的而且是久经考验的。在安全性上，hypervisor是非常可靠的，通过x86 VTx这种方式的硬件辅助，使跨租户的黑客行为基本上是不可能的。很容易想到，容器要更脆弱很多，通过攻击底层操作系统，可以将威胁扩展到一台服务器的所有实例上。
这一安全问题导致的结果是容器通常都运行在hypervisor上。每个租户的容器实例被分隔在各自独立的一个虚拟机上，用硬件保护功能来防止跨租户攻击。这种方法的缺点是显而易见的。这种方法不仅更为复杂，它还导致了hypervisor有关的代码的多份授权问题，还需要更多的操作系统副本。性能也遭受了损失。而且也损失了灵活性——但至少实例是安全的。
容器的生态系统已经抓住了转变的时机。瘦虚拟机监管软件，例如Intel的Clear Containers，被设计利用硬件隔离优势来保护容器——无需使用许多存储空间或过度拖累性能。还有其他一些安全机制的改进，特别是镜像的认证和授权方上，意味着容器现在正在缩小与hypervisor在安全性上的差距。
Hypervisor的响应
Hypervisor的开发人员们也没闲着。尽管最初否认容器的威胁，他们最终开始关注容积技术的关键优势。例如VMware通过页面重复数据删除技术处理内存最小化问题;该技术将整个重复的内存页面替换为指向单一副本的指针。然而，这是一种后负载操作，不能应对容器启动更快的问题。当然，有一些方法可以达到相同的操作性能。例如，内存页面重复数据删除可以发展为一种新的方式，通过载入镜像的索引，检查要读取的文件是否已经存在于系统中。该方式消除了任何文件载入的操作，显著得提升了重复数据删除的速度。我们倾向于将今天的hypervisor与未来期望的容器发展做对比，而忘了hypervisor虚拟化并不是停步不前的技术。
抛开这两种技术选择的内存和性能问题，这两种技术在使用方式上是有层次区别的。对于规模很大但交互很少——至少是直接交互很少——的任务，更适合在容器上部署。例如，容器非常适合网页服务。微服务也非常适合容器，我们可以想象在云上的容器中部署微服务是非常划算的。
当对比容器和hypervisor时，hypervisor更适合大的、自成一体的应用程序。在hypervisor中，应用程序能够更好的控制周围网络和存储结构，而且由于这些大的应用程序通常是关键任务，节约存储空间和启动速度并不是需要重点关注的问题——特别是与潜在的停机或安全问题损失相比时。
科学计算在最近几年才进入虚拟化领域，该应用方向已经通过虚拟化显著的提升了生产效率。尽管这些科学计算工具通常是自定义的，它们能满足许多大问题的需要。
当考虑到经济问题，应用软件和操作系统的授权方式需要改进以便所有人都能用得起虚拟化，无论选择哪种虚拟化方式。每实例每分钟的计费方式可能会成为常态。
由于有稳健的生态系统和大量的已经部署的基础，hypervisor将在IT运维中继续占有重要地位。在容器和hypervisor的竞争中，只有当hypervisor的设计者不再响应进步，容器才会成为胜利者。这显然是不可能的。事实上，未来可能的发展趋势是hypervisor和容器技术的融合，至少是在特点和效益两方面的融合。已经在hypervisor基础设施上投入巨大投资的IT公司可能希望继续使用hypervisor，无论是改进的hypervisor实例还是在hypervisor实例中的容器。而另一方面，一些还未开始投入的建设，可能将直接转向Docker或类似的容器化设施。根据应用软件特点的分层使用两类虚拟化技术也是可能的，因为hypervisor虚拟化似乎是的自成一体的大应用软件的最佳选择。
