On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote: > Hello, > > 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. Are there any particular reasons why you were unable to extend the existing openvz driver to do what you needed ? I know openvz driver has been mostly unmaintained and its code isn't too pleasant, but it'd still be nice to know what show-stopper problems you saw with using it as a base for more work. > 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. That's very interesting. Do you know if there is any statement of support for the OpenVZ kernel <-> userspace API. I know the mainline kernel aims to maintain userspace API compatibility, but are all the custom additions that the OpenVZ fork has maintained in a compatible manner as OpenVZ provides new versions ? eg is there any significant risk that when a new OpenVZ release comes out, kernel changes might break this new driver, or are they careful to maintain compat for the mgmt layer ? Also is there interoperability between this driver and the openvz tools. eg if openvz tools launch a guest, can it be seen and managed by this driver, and vica-verca ? Or are they completely separate views and non-interacting ? > 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). That's nice - care to elaborate on the technical architecture of this ? Presumably when you say 'tty' you mean the VNC is just a frontend to the text-mode console, it isn't providing any kind of virtualized graphical framebuffer. Is this VNC support you have part of the libvirt patches, or a standalone component that just interacts with it ? Basically I'm wondering whether this VNC support is something we can leverage in the LXC driver too ? > 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. As you've probably already figured out, we generally welcome support for new virtualization drivers. The two big questions to me are - Are you able to provide ongoing maintaince and development of this driver for the future ? We're already suffering from a lack of people able to maintain the existing openvz driver and the related parallels isn't too active either. Basically we'd like to see a commitment to be an active maintainer of the code. - What do you see as the long term future of the driver ? I've already asked whether there's any risk from future OpenVZ releases potentially breaking things. Historically the idea with the kernel's namespace support was that the OpenVZ forked kernel would be able to go away. IIUC, the openvz userspace can already run on top of a plain mainline kernel, albeit with reduced features compared to when it runs on openvz kernel fork. If we assume the trend of merging OpenVZ features into mainline continues, we might get to a point where OpenVZ kernel fork no longer exists. At that point I wonder what would be the compelling differences between BossonVZ and the LXC driver ? ie why would we benefit from 2 container drivers for the same kernel functionality. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list