[libvirt] new openvz driver (bossonvz)

Tue Jul 1 12:55:43 UTC 2014

  Hi David,

 I think it's worth checking also if the technical approach used
by thr driver will be compatible with current and future versions,
not sure how much Parallels want to certify their current API/ABI
kernel wise. Historically libvirt was started because we had similar
issues with Xen at the time, so definitely something to check out
to estimate the cost of maintaining the driver long term :)

  thanks,

Daniel

On Tue, Jul 01, 2014 at 02:37:49PM +0200, Bosson VZ wrote:
> Helo Daniel,
> 
> thanks for the initial tips. I have submitted a new (more personal) email so within a few days all should be settled.
> 
> To the feedback. I did not expect anything less than a request for a batch of smaller git patches. My first post here was merely to raise some public awareness of the driver and this seemed like a logical place where the information should go. I also wanted to know if I should even try to do the preparatory work for the patches considering there is already another OpenVZ driver included in libvirt.
> 
> I will try to prepare some initial patches next week or so to test the proper way the code should flow upstream.
> 
> --
> David Fabian
> Cluster Desgin, s.r.o.
> 
> Dne Po 30. června 2014 11:51:20, Daniel Veillard napsal(a):
> > 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/