[libvirt] new openvz driver (bossonvz)

[Bosson VZ]

-- 
David Fabian
Cluster Design, s.r.o.

Dne Čt 3. července 2014 23:17:12, Pavel Emelyanov napsal(a):
> On 07/03/2014 03:49 PM, Bosson VZ wrote:
> > Fair enough. We have no problem to adapt to the new process. I don't know how libcontainer is designed
> > internally and how low-level it is but having a thin user-space wrapper around the vzkernel would be wonderful.
> 
> Here's the preliminary version of it will look like: https://github.com/xemul/libct/
> The API would get slightly shuffled to fit more the https://github.com/docker/libcontainer/pull/28
> 
> 
> > I wanted to use libvzctl in bossonvz to abstract the driver away from the low-level stuff but the library
> > is just too much interconnected with the veconf parser.
> 
> Well, the libcontainer API is not going to mess with configs at all. Everything
> will be run-time.
> 
> > The current vz kernel API is not the nicest thing to work with to be honest and a shared user-space library
> > would help both vzctl and bossonvz. If you are interested in my POV on the kernel API, I would say you
> > should leave more work for the user-space. At the moment, when the user-space asks for a new container,
> > the vzkernel magically creates a new environment and sets everything (esp. cgroups) by itself without any 
> > chance for the user-space to set anything. Because libvirt has its own cgroup hierarchy model and any
> > libvirt driver should honor it, bossonvz should, idealy, create cgroups for the container under the libvirt
> > hierarchy but it cannot since the kernel won't let it.
> 
> Yes, this is our 15-years-old API that was kept compatible with tools. Soon after
> we started merging containers upstream we started the process of its deprecation,
> and in the upcoming Rhel7-based kernel we're very close to the goal.
> 
> > As I see it, the driver has to do two separate things to successfully use the kernel API. There are the
> > vz specific syscalls/ioctls (e.g. VZCTL_ENV_CREATE_DATA) and there is a preparatory work done in the
> > user-space (preparing forked sub-processes, pipes, etc.). Is the new SDK going to cover only the low-level
> > code (ioctls) or will I be able to use some sort of a high-level function like spawn_environment() and get
> > PID of the newly created container's init?
> 
> The SDK is going to be quite high-level, and more sophisticated than existing libvzctl.
> The libcontainer is going to be low-level but still more abstract than the kernel API.
> 
> > The amount of vz specific code in the bossonvz driver is not that big. The ioctls is just a single
> > bossonvz_environment.c file. The harder part is the preparatory part which is located in bossonvz_container.c
> > and is quite complex since it closely mimics the code path of vzctl (otherwise the driver would not work).
> 
> It's interesting. Can you point out where you code is?
> And, btw, I think you would be interested in taking part in libcontainer
> design, discussions and development. The link above is the place where we
> try to settle down the new API and you're welcome to join :)
> 
> 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/20140707/7b4a813c/attachment-0001.htm>