[libvirt] new openvz driver (bossonvz)

[Daniel P. Berrange]

On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote:
> Hello,
> 
> in the company I work for, we use openvz and qemu/kvm on our clusters
> side-by-side. To manage our domains, we used libvirt/qemu for qemu/kvm
> domains and vz tools for openvz domains in the past. This was very
> inconvinient since the management differed in many ways. So we have
> decided to unify our management and use libvirt exclusively. Since the
> openvz driver already included in libvirt lacks features that need, we
> have implemented a new libvirt backend driver for openvz called the
> bossonvz driver.

Are there any particular reasons why you were unable to extend the
existing openvz driver to do what you needed ? I know openvz driver
has been mostly unmaintained and its code isn't too pleasant, but
it'd still be nice to know what show-stopper problems you saw with
using it as a base for more work.

> Unlike the openvz driver, bossonvz is a complete, feature-rich stateful
> libvirt driver. It uses the libvirt driver API exclusively and
> communicates with the kernel directly, much like the LXC driver. The
> code is hugely inspired by the LXC driver and the Qemu driver, but adds
> a bit of functionality to the libvirt core too. More details and the
> source code can be found at
> 
> http://bossonvz.bosson.eu/
> 
> The driver is completely independent of vz tools, it needs only a
> running vz kernel.

That's very interesting. Do you know if there is any statement of
support for the OpenVZ kernel <-> userspace API. I know the mainline
kernel aims to maintain userspace API compatibility, but are all the
custom additions that the OpenVZ fork has maintained in a compatible
manner as OpenVZ provides new versions ?

eg is there any significant risk that when a new OpenVZ release
comes out, kernel changes might break this new driver, or are they
careful to maintain compat for the mgmt layer ?

Also is there interoperability between this driver and the openvz
tools. eg if openvz tools launch a guest, can it be seen and managed
by this driver, and vica-verca ? Or are they completely separate
views and non-interacting ?

>                    One of the things, we are most proud of, is the
> possibility to access the domain's tty via VNC (hurray to uniform
> management web interfaces).

That's nice - care to elaborate on the technical architecture
of this ? Presumably when you say 'tty' you mean the VNC is just
a frontend to the text-mode console, it isn't providing any kind
of virtualized graphical framebuffer.   Is this VNC support you
have part of the libvirt patches, or a standalone component that
just interacts with it ?

Basically I'm wondering whether this VNC support is something we
can leverage in the LXC driver too ?

> Since the code was developed in-house (primarily for internal
> purposes), it is based on an older libvirt release (1.1.2). There
> are also some modifications to the libvirt core (virCommand) and
> the domain file (mount options syntax) which might need some
> redesign.
> 
> At the moment I would like to get some feedback on the driver. In
> the future, I would like to see the driver merged upstream, and
> am prepared to do the work but I need to know if there is any
> interest in doing so.

As you've probably already figured out, we generally welcome support for
new virtualization drivers. The two big questions to me are

 - Are you able to provide ongoing maintaince and development of
   this driver for the future ? We're already suffering from a lack
   of people able to maintain the existing openvz driver and the
   related parallels isn't too active either. Basically we'd like
   to see a commitment to be an active  maintainer of the code.

 - What do you see as the long term future of the driver ? I've
   already asked whether there's any risk from future OpenVZ releases
   potentially breaking things. Historically the idea with the kernel's
   namespace support was that the OpenVZ forked kernel would be able
   to go away. IIUC, the openvz userspace can already run on top of a
   plain mainline kernel, albeit with reduced features compared to when
   it runs on openvz kernel fork.  If we assume the trend of merging
   OpenVZ features into mainline continues, we might get to a point
   where OpenVZ kernel fork no longer exists. At that point I wonder
   what would be the compelling differences between BossonVZ and the
   LXC driver ?  ie why would we benefit from 2 container drivers for
   the same kernel functionality.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|