--

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@redhat.com

> https://www.redhat.com/mailman/listinfo/libvir-list