[libvirt] new openvz driver (bossonvz)

[Bosson VZ]

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
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140701/8c4ac9f9/attachment-0001.htm>