<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'Monospace'; font-size:9pt; font-weight:400; font-style:normal;"> 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 > > </body></html>