[libvirt] new openvz driver (bossonvz)

[Daniel Veillard]

On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote:
> Hello,

  Hello,

first small rule here, trust is build on persons like most open source
projects, so please change your email, I want to communicate with a person
not with the name of a company.

> 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.

  it's true that the openvz diver is lagging behind a bit, I didn't see
any real update since 2012. That wouldn't be the first time that we have
multiple drivers for a given hypervisor, Xen is a precedent at least,
though that's not a perfect situation as it dilutes manpower to maintain
drivers for the hypervisor.

> 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. 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).
> 
> 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.

  The proper way to get feedback on the driver is:
    1/ rebase your code to the current version, there is nothing we
       can do with a patch for 1.1.2
    2/ split the changes logically, nobody will review a 44312 line
       patch, remove garbage from diffing generated files like configure
    3/ submit the patches on this list for review, each patch having
       details about what it does, etc ... best manage all this with
       git on a branch from the upstream or you will be mad very quickly
       see how other does, that's standard practice and if you're not
       familiar with it, learning it won't be a lot time really.
    4/ you will need to add patches adding documentation, no doc, no
       upstream :)

 If you think it's too much, then don't bother because we will need
commitment to maintaining the driver over the years, and the sum of
the work will be even larger than those initial steps. What you gain
in exchange is integration in upstream, easier maintainance, easier
rebase and recognition in the community.

   Makes sense ?

Daniel

-- 
Daniel Veillard      | Open Source and Standards, Red Hat
veillard at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | virtualization library  http://libvirt.org/