|
Thanks for the links. I'll definitely check them out.
The source code can be found at bossonvz.bosson.eu. But have in mind that the bossonvz driver uses only a subset of the vzkernel API. Some vzctl functionality is not implemented as it was not needed. Backwards compatibility with older vz kernels has also been dropped. And a lot of the auxiliary code is hidden in libvirt functions (especially virCommand).
Thanks for the invitation. I believe the bossonvz driver could also leverage from that kind of co-operation.
-- 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list |
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list