[libvirt] new openvz driver (bossonvz)

[Pavel Emelyanov]

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