Re: [libvirt] new openvz driver (bossonvz)
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(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/