Re: [libvirt] new openvz driver (bossonvz)
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