[Libvir] [RFC] Add Container support to libvirt

[Daniel P. Berrange]

On Fri, Dec 28, 2007 at 12:34:14AM -0800, Dave Leskovec wrote:
> I'd like to extend libvirt to support Containers.  As libvirt already 
> supports Xen, KVM, QEMU and OpenVZ, I think it would be valuable to be 
> able to utilize existing utilities to manage containers.

When you say 'Containers' are you meaning that in the general sense of
the word, or specifically referring to the container support that is 
being incrementally added to the upstream Linux ?

> I've spent some time looking through the libvirt api and how this 
> Container support will fit.  Based on the XML format section of the 
> libvirt website and some list discussions I put together the following 
> proposed XML format:
> 
> <domain type='linuxcontainer'>
>    <name>Container123</name>
>    <uuid>8dfd44b31e76d8d335150a2d98211ea0</uuid>
>    <container>
>        <filesystem>
>            <mount>/etc = /home/user/lxc_files/etc</mount>
>            <mount>/var = /home/user/lxc_files/var</mount>
>        </filesystem>

You have structured data in the CDATA section there which is bad practice.
A couple of possible alternatives ...

   <mount node="/etc/">/home/user/lxc_files/etc</mount>

Or

   <mount>
     <source dir="/home/usr/lxc_files/etc"/>
     <target dir="/etc"/>
   </mount>


>        <application>dbserver</application>

Not sure what this is for - could you elaborate a little ?

>        <network hostname='browndog'>
>            <ip address="192.168.1.110" netmask="255.255.255.0"/>
>                <gateway address="192.168.1.1"/>
>                <nameserver>192.168.1.1</nameserver>

For consistency with the <gateway> tag that would be better off
as being  <nameserver address="192.168.1.1"/>

>            </ip>
>        </network>
>        <cpushare>40</cpushare>
>        <memory>65536</memory>

This can be in the top level - ie outside the '<container>' tag
since the <memory> tag is already there for non-container based
virtualization and there's no neeed to differ here.

>    </container>
>    <devices>
>        <console tty='/dev/pts/4' />
>    </devices>
> </domain>
> 
> The clone() function is used with the CLONE_NEWPID and CLONE_NEWNS flags 
> to start a new process within it's own process name space. The only 
> processes visible to it will be itself and any processes that it 
> spawns.  The process that clone creates will start out preparing the 
> container environment.  This involves setting up any network interface, 
> setting up the file system by performing any requested mounts, mounting 
> /proc, setting up a tty device, populating /dev as necessary, and 
> performing any other necessary initializations.  It will then start the 
> application(s) requested by the user.  The executables started within 
> the container could be an application or script or possibly /sbin/init.  

Rather than trying to define a syntax for libvirt to start multiple apps
within the container, I reckon just having libvirt call a single /sbin/init
script would be best - that way admins can use whatever they like for startup
inside the container, whether it be a simple shell script, SysV init, or 
something else entirely.

> The mounts that the user specifies will need to be populated with the 
> appropriate contents for whatever applications they are going to run 
> within the container.  cgroup will be used for isolation and association 
> with controllers for cpu and memory resources.
> 
> I'm planning to start in on defining a container.  All comments and 
> questions are welcome.

Ok, it definitely sounds like you're talking specifically about the Linux
based container impl now.

Aside from the existing OpenVZ driver, there was also a proof of concept
for the Linux-VServer based containers posted a short while back which
may be a useful reference:

  https://www.redhat.com/archives/libvir-list/2007-October/msg00273.html

I can see that all of the OpenVZ, VServer and Container concepts match up
pretty nicely, so we ought to be able to get a good XML representation
that works with all of them.

One major area we've never successfully tackled yet, even for non-container
based virtualization is the topic of resource controls / tuning info. I'd
say that should be one of our priorities to sort out now we've got all the
NUMA stuff integrated.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|