[libvirt] new openvz driver (bossonvz)

Bosson VZ bossonvz at bosson.eu
Wed Jul 2 12:15:37 UTC 2014

Thanks in return for the acknowledgement.

I understand that the long-term plan is to reduce the size of the vzkernel patch and to only use vanilla kernel primitives Daniel was talking about. That would be an ideal situation. The thing is that we simply cannot wait for this merge to happen. We have been using OpenVZ for many years and bossonvz is just a convenient tool for us right now and, at least, in the mid-term future. My question is how is the new libcontainer/PCS SDK library going to influence the existing vz-tools eco-system? 

David Fabian 
Cluster Design, s.r.o.

Dne Út 1. července 2014 19:52:28, Pavel Emelyanov napsal(a):
> On 07/01/2014 07:43 PM, Dmitry Mishin wrote:
> > Pavel and James to CC
> > 
> > On 30/06/14 17:39, "Daniel Veillard" <veillard at redhat.com> wrote:
> > 
> >> On Mon, Jun 30, 2014 at 10:31:26AM +0100, Daniel P. Berrange wrote:
> >>> On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote:
> >> [...]
> >>>  - 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.
> >>
> >>  Good point !
> >>
> >>  My recollection of talking with James Bottomley is indeed that all
> >> the special features are being migrated as part of the commonly agreed
> >> upon set of kernel primitives put in the kernel for containers. So I hope
> >> that this driver will indeed work based on those primitives and not
> >> the Parallels specific extensions, as those may vanish sooner or later.
> First of all -- great Thanks to the Bosson team for this work :)
> Unfortunately, I must say that our plan is to deprecate the OpenVZ kernel API 
> for containers eventually. Current plan is the API for OpenVZ and PCS products 
> would be the PCS SDK (the GPL-compatible version will be announced soon) and
> the libcontainer project.
> Thanks,
> Pavel
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140702/9d7a8348/attachment-0001.htm>

More information about the libvir-list mailing list