**[2023 important update]** *Things have taken a turn, and now I recommend LXC over OpenVZ.* LXC has become more mature. Unprivileged containers in LXC are significantly more robust and secure now. And with the introduction of LXD and Incus, using LXC has become much more user-friendly. With native support for OVS/OVN, the LXC network management has become equally easy and secure. It's worth noting that LXC has always been available in the mainline Linux kernel, eliminating the need for custom kernels and making it faster to receive security fixes. On the other hand, OpenVZ is struggling to keep up with Linux kernel development. OpenVZ 7 doesn't run on all the newer hardware available today and its latest version, OpenVZ 9 based on RHEL 5.14 kernel, has yet to be publicly released. When OpenVZ 9 does finally launch, its kernel version will already be outdated, potentially resulting in suboptimal hardware compatibility and performance. It is true that RedHat backports security fixes, some hardware compatibility and important features from newer kernels, but a 5.14 RHEL kernel certainly isn't exactly the same as a 6.6 (or newer) mainline kernel (and when it is, you still have to wait for such backports). --- **[2019 outdated answer]** **First:** both projects are awesome and I want both of them to succeed! --- My personal point of view is that LXC has more vulnerability records, including [concerning ones][1]. And, to me, OpenVZ offers a great, easier and more secure experience, including the new OpenVZ 7. Through the history of documented vulnerabilities from OpenVZ and LXC: - From the [three vulnerabilities][2] found on OpenVZ, even when they were not fixed, they didn't allow privilege escalation or code execution - From the [eight vulnerabilities][3] found on LXC, one [documented on 2019][4] allowed code execution with root privileges on the host machine and other [allowed privilege escalation][5] Some additional points: - The [venet][6] network model of OpenVZ is more secure and more isolated [ 1 ] - A container on `venet` network (OpenVZ) cannot sniff the network traffic of neighboring containers [ 1 ] [ 1 ] https://wiki.openvz.org/Differences_between_venet_and_veth As stated in [this article][7]: > OpenVZ does security via the "bottom up, all included principle". > Containers are very solidly isolated against each others. Over the > years there have been a few issues and vulnerabilities, but in general > you can say that they did a splendid job. Because security was first > and foremost on their mind. Not just the container isolation, but also > network security. If you allow root access to an untrusted client on > one Container, then you don't want him sniffing the network traffic of > neighboring Containers, the node or even the whole subnet. For that > reason OpenVZ had introduces the "venet" network interfaces, which > tackled that in a really neat, orderly and (for the end user) very > simple fashion. [1]: https://brauner.github.io/2019/02/12/privileged-containers.html [2]: https://www.cvedetails.com/vulnerability-list/vendor_id-12951/Openvz.html [3]: https://www.cvedetails.com/product/27105/Linuxcontainers-LXC.html?vendor_id=13134 [4]: https://www.cvedetails.com/vulnerability-list/vendor_id-13134/product_id-27105/year-2019/Linuxcontainers-LXC.html [5]: https://www.cvedetails.com/vulnerability-list/vendor_id-13134/product_id-27105/year-2014/Linuxcontainers-LXC.html [6]: https://wiki.openvz.org/Differences_between_venet_and_veth [7]: https://www.aventurin.net/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=28&cntnt01detailtemplate=Simplex%20News%20Detail&cntnt01category_id=1&cntnt01returnid=1