[Users] OpenVZ/Virtozzo 7 packages distro packages? (was: Re: New setup - deploy OpenVZ or wait for VZ7?)

Corrado Fiore lists at corradofiore.it
Fri Jun 3 20:42:23 PDT 2016


Hello!

Great points Scott.  If I may add my very personal view, I would say that I see even more reasons for going RedHat-only on the host node.

It seems to me that RedHat made a remarkable work of bringing lower-level features to Linux (think of KSM, KVM, the merging of the FUSE enhancements from OpenVZ and so on), whereas the Debian team did the same on a higher level (I'm not a Debian expert but their APT package manager comes to mind as an example of a remarkable addition), not to mention Canonical's huge success on desktops.  So I agree that on the host node a RH-derived kernel looks like the best fit:  at the end of the day, the host doesn't run higher level apps.

Also, before reading Scott's points, I sent another message to the list proposing the idea of merging an online memory tester (specifically, RAMpage) into the VZ kernel.  I see it as a  good example of what we're discussing here:  a potentially valuable addition for the *server* market that works at a very low level, thus difficult to be ported to (and maintained on) different kernels.

As far as I'm concerned, I would be happy to trade multiple kernels support in exchange for more rock-solid features added to the VZ kernel.

(my 2 cents, of course)

Best,
Corrado Fiore

___________________________________________
> On 4 Jun 2016, at 6:25 AM, Scott Dowdle <dowdle at montanalinux.org> wrote:
> 
> Greetings,
> 
> The sub-subject of this should be: OpenVZ/Virtozzo 7 packages distro packages?
> 
> ----- Original Message -----
>> Is it possible to build kernel packages/userspace utilities for
>> debian jessie as well ?
>> 
>> Right now there is only kernel/userspaces utilities for debian wheezy
>> and userspace only for debian jessie.
> 
> Before I start my semi-rant, I want to make it clear that I'm just a user and I have no idea what Virtuozzo's plans are.  Clear?  Ok.  Now to start.
> 
> Will there be packages OpenVZ/Virtozzo 7 packages for other distros?  I don't think it is a good idea.  As you know, V7 is its own distro... rebuilt from EL7 (CentOS).  It supports both containers and KVM virtual machines... and offers its own library based tools as well as integrates with libvirt (and the goal is to upstream the libvirt stuff although I don't know the status of that).  There are a lot more userland tools than the small handful of things used in OpenVZ Legacy.  I believe there are also some lower level distro packages that have been modified to meet the needs of V7.
> 
> The host node is for running VMs and containers... not other services... not user accounts... just for virtualization.  The strength of say Debian... is that it is built for a wide range of arches and has a very, very big package collection.  None of that is needed for a V7 virtualization host.  Debian is a "universal OS" aka general purpose.  What Virtozzo is offering is a distro built just for the purpose.
> 
> The work involved in building all of the V7 packages for other distros would be significant.  Then what about the (probably very small number of) distro packages that V7 would want/need to replace?  What about testing it?  Both KVM VMs and containers?  How big is that test matrix going to be?  Your distro already has libvirt and KVM packages but you aren't going to try and use those are you?  You want the ones tested with V7.
> 
> Red Hat bought Qumranet... and is the main driving force behind KVM, libvirt, a significant chunk of every mainline Linux kernel's development (#1 identifiable company on most all kernel releases)... they ship and support KVM.  They have their own virtualization products built on top of it (well several if you count OpenShift and all of its flavors and RHEV).  They are the main driving force behind gcc and glibc, etc.  They sponsor a lot of work.  RHEL and the EL clones are supported for a long time.  Their kernels are supported for a long time.  It is the most appropriate platform (in my opinion) for building on top of especially when that product is related to a core competency of EL which is KVM, libvirt, etc.
> 
> When you have a product that has a lot of packages and requires it to all work together well... trying to shoehorn those all onto multiple distros is a lot of work.  There are two basic approaches... bundle everything you use... and totally ignore what the underlying distro provides... OR support a limited number of distros and build specifically for them (the Zimbra approach... with the number of supported distros dwindling over time).  I don't think either of those would be a good approach giving the nature of a newish company with a new major release coming out.
> 
> How long is it taking Virtuozzo to get the product to the market after EL7 was initially released?  How long of a lifespan does it have left on that platform?  Compare that to the lifespan of other distros.  If V7 was targeted at a Debian release how much life would that version of Debian have left in it?  It seems to me that about half of the distro lifespan would be devel time leaving only half of it for deployment time.
> 
> Are Red Hat, Gentoo, SUSE users demanding that Proxmox VE make packages for them?  Not really.  Proxmox VE is derived from Debian and can probably be used easily on any Debian-based distro that uses the stock Debian repos... but anything else... forget about it.
> 
> Now having said all of that... if you can make a compelling argument on why Debian (for the host node) would be a better distro to build upon for this use case (or any other distro), I'm all eyes/ears.
> 
> Or if someone wants to take all of the code and built packages on their own for other distros that's fine... but expecting Virtuozzo to do it I think is asking too much.
> 
> TYL,
> -- 
> Scott Dowdle
> 704 Church Street
> Belgrade, MT 59714
> (406)388-0827 [home]
> (406)994-3931 [work]
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users




More information about the Users mailing list