主流的虚拟化技术有虚拟机（Virtual Machine）和容器（Container）两种，虚拟机能够完整虚拟机器的软硬件资源，目前常见到的虚拟机技术包括Kvm，Xen，VirtualBox，VMware，Hyper-V等；容器则会以只读的方式共用操作系统的内核以及部分应用程序(bin)和函数库(lib)，主流的容器技术包括OpenVz和LXC（及近亲docker）等。
由于容器技术非常轻量，成为很多场景下的最佳选择，OpenVz和LXC都是不错的容器技术，后者甚至是linux官方指定容器化方案（毕竟Linux Container的简称嘛），但是实际上我们也看到服务器市场上还是OpenVz远远比LXC要用的多一些，这就很奇怪了，OpenVz明明已经在对新内核的支持上渐显颓势，明显不是未来，商家还是更愿意选择用OpenVz，要知道支持LXC并不需要多少额外的工作。
看了一篇文章，感觉写的挺好，稍解疑惑，转载一下：
先说结论，综合来说，目前OpenVz还是要比LXC好用不少。OpenVz和LXC的一些比较：
第一点,磁盘配额问题
lxc是利用namespace和cgroups来实现进程网络隔离的， namespace和cgroups并没有实现磁盘的配额，一般lxc是配合lvm磁盘管理技术来实现磁盘空间限制的。LVM屏蔽了底层磁盘布局,使用户可以很方便于动态调整磁盘容量，很方便进行额外扩容。 但是会降低磁盘的直接读写性能。用户多了很容易开出石头盘
openvz直接patch内核，把磁盘的io操作请求直接rewrite过去，应该是修改了内核中的函数，当程序调用fopen()，open()，内核自动写到指定区域，并返回写入成功的指针。当超过分配的上限时间，直接返回NULL。
测试了一下，用的本地虚拟机，相同配置。母鸡都是2c4G,nvme 60g固态硬盘，小鸡都是1c 512M
openvz磁盘测试
lxc磁盘测试
第二点，内存管理问题
lxc的内存限制是直接killed掉相关程序来实现内存限制的
当lxc内存不足时，lxc管理程序直接kill相关程序。
当openvz内存不足时，通过kernel里面相关的函数，返回给malloc()指针NULL。并且告诉guestos内存不足
openvz通过修改kernel里面的函数，当guestos程序 malloc()函数请求内存限制在规定范围内，返回正确指针，当内存超出限制时，malloc()函数返回NULL。并模拟内存不足的signal传给gusetos，guestos进行相关操作，在vz7以上可以增加swap，经过patch的kernel可以把openvz里面的部分内存放到分配给guestos的swap空间里面。
你知道lxc是怎么干的吗？内存显示通过挂载lxcfs直接overlay掉/proc/meminfo ,使guestos使用free命令直接显示分配的内存，都是有些软件不认啊
cpu信息也是直接overlay掉/proc/cpuinfo。如果软件不使用/proc/cpuinfo获取信息，问题就会出现。问题还挺久的
最重要的，如果很多小内存程序把内存占满了，会发生什么？（都是256M，这个是用1M的块往内存中写入256次，之前是256M的块写入1次，内存的申请不一样，一个是256Mx1，一个是1Mx256）
openvz会返回失败
lxc直接崩溃了
第三，特权容器问题
在特权容器下，lxc可以mount系统目录，如果允许挂载，那么如果用户挂载/sysfs，/dev会导致逃逸问题。一般解决方法是使用非特权容器启动，都是这样用户无法使用mount挂载。
只能用一些其他方法挂载，比如先挂载到母鸡（宿主机）
非特权LXC中挂载Nas的共享目录 。
vps的母鸡根本不可能这样操作好吧openvz是patch内核，没有什么特权容器问题。mount也不可能挂载到母鸡的文件如果说openvz 的 kernel 漏洞会导致逃逸，那么lxc的kernel 漏洞不也是一样逃逸lxc的vps，io容易出现石头盘，加上不稳定的因素，用户口碑很差，除了钱给够，部分affman狂推外。几乎没有mjj去买
最后，lxc在私有云上的部署比较多，公有云还是算了吧，可操作性比openvz还要少，许多功能需要在宿主机（母鸡）上配合操作才行。对于卖vps的公有云根本不可能，而且卖vps的商家也不可能给lxc容器特权
附1：openvz为Centos7中的openvz7，lxc为debian11。
实测debian11直接安装lxc和pve中lxc性能基本相同（lxc版本号，内核也相同）。
附2：libvirt的开发人员开发lxc接口时还抱怨过lxc特权挂载问题。
后来使用lxc非特权容器解决了lxc幸运的是，相关核心代码被并入了kernel之中，可以跟着kernel一起维护。openvz就没有那么幸运了，自从xen被踢出kernel后，发展一天不如一天，用的人越来越少了，维护的人也越来越少。kvm被被并入了kernel之中，维护的人也越来越多，用的人越来越多。没有挤进kernel的代码，现在看起来都要被淘汰了，openvz和xen就是这样。lxc，kvm能抱住大腿真好。openvz没有抱住大腿，已经有一股要淘汰的样子，xen也是。lxc核心在kernel中，以后使用肯定会超过openvz，但是我还是觉得openvz的要好一些。说不定以后vz的内核只有自己patch了
LXC虚拟小鸡之前开过几车，上面提到的问题好多都遇到了，包括内存占用一高小鸡就会直接掉线，IO性能下降较快的问题。在小内存机器上尤其明显，对于公有云分享的效果来看，OpenVz看起来合适很多。
bdbd，玩机不多只见过一台vps是lxc架构的，然后赶紧开工单让改成kvm去了
看见熟悉的回答
我用c语言写的程序malloc()申请过高的内存有概率断片，申请失败但是不会返回NULL，导致程序bug卡死。实体机和openvz没有问题。
有一样有openvz和lxc差别的疑问,发现vps使用openvz远远比LXC多。搜到知乎的这个回答,发现没有明确的回答.。于是用内核调试工具进行调用追踪发现lxc的问题。
搜索源码中找到了相关函数发现了实现的原理，发现lxc管理程序使用的内核调用和docker一模一样，心想这就是一个大号的docker啊。发现openvz没有这个问题，又看了openvz的源码，发现openvz的实现隔离性和资源管理较好。
上面说的问题都是看源码s想到的理论上会发生的问题，简单测试了一下就回答了，没有过多的测试，后面看了网友们使用lxc VPS的bug,发现还真是这样，就把网友的bug也贴上去印证了。