|
|
Subscribe / Log in / New account

OpenVZ 7.0 released

OpenVZ 7.0 has been released. The new release focuses on merging OpenVZ and Virtuozzo source codebase and replacing its hypervisor with KVM. There are many other improvements and new features in container management and more.

to post comments

OpenVZ 7.0 released

Posted Jul 26, 2016 7:41 UTC (Tue) by zoobab (guest, #9945) [Link] (4 responses)

OpenVZ is dying slowly, most of the containers users have switched to Docker or LXC, OpenVZ sticks to Redhat based distros to target the "hosting" market, while most people wants Ubuntu LTS based distros on their servers.

I was an heavy user of OpenVZ, but this behaviour of being a Redhat lackey made me drop it.

OpenVZ 7.0 released

Posted Jul 26, 2016 8:03 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link]

What? OpenVZ definitely supports multiple Linux distro guests. I rent an OpenVZ Slackware VPS from VPSCheap for $15 per year.

Support for not redhat

Posted Jul 26, 2016 9:08 UTC (Tue) by TimSmall (guest, #96681) [Link]

I support OpenVZ for a client. Nearly all the containers run Debian - mainly current stable (Jessie). The host nodes also run Debian oldstable (Wheezy). OpenVZ run their own kernel apt repository - this packages the OpenVZ version of the RHEL 6 kernel.

https://openvz.org/Installation_on_Debian

OpenVZ 7.0 released

Posted Jul 26, 2016 16:13 UTC (Tue) by dowdle (subscriber, #659) [Link] (1 responses)

A few comments... RHEL and clones are doing just fine. See any Red Hat quarterly report and notice that they have, so far as I recall, not had any quarter without growth.

Why pick EL7 to base a product on? First of all, for a virtualization host that will be running containers and (now with VZ7) VMs... you want a light weight and easy to maintain underlying distro... that is also supported for a long time. You don't really care whether or not it has a huge package repository (Ubuntu mostly because of Debian) because you really SHOULD NOT be running other services on it. I don' t really see much benefit of Canonical over CentOS in that regard.

Why use a RHEL-based kernel? Look here on LWN and you will find their occasional Who Wrote It articles about kernel releases. I don't think they are able to do it for every single kernel release but they do it frequently enough... and a long-term patterned has emerged... and that is of Red Hat contributing around 10-12% of the code for each kernel release... and more often than not coming up as the top identifiable contributing company. Canonical? Never been in the top 10... or top 100... so far as I know. Also consider the answer to this question? Who is the primary contributor to KVM? To libvirt? To virsh and virt-manager? To qemu? To systemd, etc?

As you also probably know, a new mainline kernel comes out every 2.75 - 3 months. Very few mainline kernel releases actually get adopted by major distros... and of those that do... hopefully they pick mainline LTS releases... that are supported for what? 2 years? That isn't a long time. Canonical supports their LTS kernels for 5 years... and RHEL/clone for 7. RHEL also works very hard to back port some features, bug fixes, and especially security fixes even when their kernels are fairly long in the tooth.

Do people want to use Ubuntu and Debian? Sure they do... but they also want to use RHEL, CentOS, Fedora, etc. There are a lot of different use cases... and luckily OpenVZ supports all of those as containers... so I don't think there is much of a problem there.

With VZ7, Parallels have cemented the stable base even further by making their own CentOS clone in VzLinux. Because they expanded the feature set to include both containers and KVM virtual machines... and support their own internally developed admin tools and technologies (prlctl, vzctl, ploop, etc) as well as the upstream ones (KVM, libvirt, virsh, qcow2) and given the fact that they have altered a few of the lower level packages to add necessary features... they decided for a better user experience and easier to offer quality support for... to provide a full distro. Trying to make their setup work on a range of different distributions with different distro provided versions of libvirt, qemu, kvm, etc... would have just made it a support nightmare. The bulk of everything is open source so any communities that want to take the code and adapt it for their preferred (virtualization host) distro can certainly do so.

I also do not think Docker application containers have really eaten into the distro containers much at all. LXC and OpenVZ do have quite a bit of overlap... but part of the problem with LXC has been its diversity across the range of distros that provide it... different kernel versions and different userland versions. I'm glad Canonical has sponsored a whole lot of work on LXC and developed LXD as well... but it remains to be seen just how widely adopted it will be. Given the fact that the first stable release of LXD was in Ubuntu 16.04, it hasn't really had much time in the market. Given that VZ7 is new as of yesterday... we'll just have to see how well they compete against each other. I think there is plenty of room for multiple players in this area... including others like Proxmox VE. For me, competition is good and a sign of a thriving market.

OpenVZ 7.0 released

Posted Jul 28, 2016 0:18 UTC (Thu) by abufrejoval (guest, #100159) [Link]

I fully agree on the RHEL kernel story.

Been a long fan and user of OpenVZ and It's sure been a very long wait.

I'm a bit sorry that much of the delay seems to have been around transitioning from the Parallels hypervisor to KVM.

I couldn't really care less, because I don't see VM and container coexistence as a strong selling point.
Sure in the home-lab and in some really small environments that's nice, but on a large scale?

For the Virtuozzo home market, the ISPs this may be somewhat more important, but OpenVZ would have been much better off with a timely v7 release.

Far more important is the ability to run Docker inside containers: Nesting *is* important on big machines and Docker's deployment capabilities sure are very nice.

I see OpenVZ and Docker as very, very complementary with OpenVZ having a lot of maturity in resource management and monitoring or the bottom up perspective while Docker does a great job at extending the application downwards while it's never quite "finished" with regards to security or resource management.

So naturally the first thing I tried was running Docker inside an VZ7 container and with a bit of tweaking it works just fine :-)

Change in long term support for open source Virtuozzo vs. OpenVZ

Posted Jul 26, 2016 9:17 UTC (Tue) by TimSmall (guest, #96681) [Link] (3 responses)

Although there are many nice looking changes with Virtuozzo 7 vz. OpenVZ, one significant policy change is lurking on the final row of this table:

https://openvz.org/Comparison

EOL policy for OpenVZ is "5 years of support"
EOL policy for Virtuozzo 7 is "EOL as soon as new major version released"

Whilst I can fully understand why they've done this, it's reasonably likely to push me to use lxd instead of Virtuozzo 7... I don't relish the thought of migrating big chunks of infrastructure the minute a new version comes out, and occasionally everyone has a bad initial release of a new major version. 6 months or even 3 months would be a less extreme change...

Maybe the community will step up and start backporting the upstream RHEL security fixes to the Virtuozzo 7 kernel, but unfortunately with just a few OpenVZ machines this starts to make lxd with the accompanying Ubuntu LTS lifecycle look more attractive.

Change in long term support for open source Virtuozzo vs. OpenVZ

Posted Jul 26, 2016 14:18 UTC (Tue) by Conan_Kudo (subscriber, #103240) [Link]

That should effectively be the same thing. Virtuozzo major releases are now tied to RHEL major releases, which are done on a five year cycle. That's the point of having VzLinux. Virtuozzo appears to want to take a more active role in supplying bug and security fixes, which explains the launch of VzLinux as part of Virtuozzo 7. There are also several other nice things that they are providing now, such as Linux kernel patching (kpatch-based). Enabling that requires competent Linux kernel engineers that understand how to craft such things to pull it off. I think they've got an interesting value proposition now.

Change in long term support for open source Virtuozzo vs. OpenVZ

Posted Jul 26, 2016 16:16 UTC (Tue) by dowdle (subscriber, #659) [Link]

Given the fact that the virtualization host is supposed to be light-weight and easy to manage... and that containers and VMs should be fairly easy to migrate from one host to another... and from one release to another... setting up a new host node with the new release, testing it out, and then migrating containers and VMs seems reasonable. As previously mentioned, I don't expect Parallels to have a "major" new release without an accompanying EL major release... and at least a year of development and testing... and as previously mentioned, the speed of EL releases has been slowing down quite a bit.

Change in long term support for open source Virtuozzo vs. OpenVZ

Posted Jul 28, 2016 10:16 UTC (Thu) by sergeyb (guest, #102934) [Link]

> EOL policy for OpenVZ is "5 years of support"

True.

> EOL policy for Virtuozzo 7 is "EOL as soon as new major version released"

Sorry, it was added to the table by mistake.


Copyright © 2016, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds