[Libvir] [RFC] 0/3 Add Linux Container support to libvirt
The following set of patches add the first batch of linux container support to libvirt. The work is not complete but I wanted to start getting some of this out for comments. This set of patches supports the following: * new switch --with-lxc to enable linux container support (off by default) * virConnectOpen * virConnectClose * virConnectListDomains (of course none are listed since we can't start the containers yet) * virConnectNumOfDomains * virConnectListDefinedDomains * virConnectNumOfDefinedDomains * virDomainLookupByUUID * virDomainLookupByName * virDomainGetInfo * virDomainGetXMLDesc * virDomainDefineXML * virDomainUndefine A sample XML format that can be used to define a linux container domain: <domain type='linuxcontainer'> <name>TestContainer3</name> <container> <filesystem type='mount'> <source dir='/home/user/lxc_files/etc/'/> <target dir='/etc/'/> </filesystem> <filesystem type='mount'> <source dir='/home/user/lxc_files/var/'/> <target dir='/var/'/> </filesystem> <init>/usr/sbin/container_init</init> </container> <memory>65536</memory> <devices> <console tty='/dev/pts/4'/> </devices> </domain> I've left out the network definition as I'll be tackling that a little later on... I'm currently working on starting a container. Any and all questions and comments are welcome. Thanks! -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization
Dave Leskovec <dlesko@linux.vnet.ibm.com> wrote:
The following set of patches add the first batch of linux container support to libvirt. The work is not complete but I wanted to start getting some of this out for comments. This set of patches supports the following:
Hi Dave, Something (your mail client?) seems to have corrupted those patches by removing leading spaces and splitting lines, so most of the parts do not apply: $ patch -p0 < /t/p patching file configure.in patch: **** malformed patch at line 30: [ --with-qemu add QEMU/KVM support (on)],[],[with_qemu=yes]) I know you said this is only preliminary, so here are some mostly-superficial suggestions: * please mark all new diagnostics with _(...), so that translators see them. Since you add a new *Error function, please add its name to the err_func_re definition in Makefile.maint. Then, running "make syntax-check" will inform you of remaining unmarked strings. Also, declare your new log function with the printf __attribute__, so that gcc checks each format string against its arguments. [Go ahead and add your new function for now, but I suspect there should not be a new log function for each new subsystem. These are all nearly-identical clones: qemudReportError virStorageReportError ReportError I hope someone finds the time to factor this out. It's on my medium-term TODO list. ] * check for strdup failure if the resulting pointer may be dereferenced without being checked for NULL. There seem to be two of those: one in lxcParseDomainName, the other in lxcLoadDriverConfig. In each case, it looks like the pointer is later assumed to be non-NULL and dereferenced (probable segfault). * Something to think about: People should be able to install libvirt using e.g., --prefix=/foo, which would ideally make your code use "/foo/etc/libvirt/lxc", rather than the currently-hard-coded "/etc/libvirt/lxc". Or maybe that file name should be even more configurable... Note that openvz_conf.c has a similar problem, though at least it does work with --prefix=/usr/local. * please use virBufferAddLit when there is no % directive: $ grep -E 'virBufferVSprintf *\([^,]+, *"[^%]+"\)' /t/p + if (virBufferVSprintf(buf, " <container>\n") < 0) { + if (virBufferVSprintf(buf, " </filesystem>\n") < 0) { + if (virBufferVSprintf(buf, " </container>\n") < 0) { + if (virBufferVSprintf(buf, " <devices>\n") < 0) { Jim
On Thu, Feb 21, 2008 at 11:11:40AM +0100, Jim Meyering wrote:
Dave Leskovec <dlesko@linux.vnet.ibm.com> wrote:
The following set of patches add the first batch of linux container support to libvirt. The work is not complete but I wanted to start getting some of this out for comments. This set of patches supports the following:
Hi Dave,
Something (your mail client?) seems to have corrupted those patches by removing leading spaces and splitting lines, so most of the parts do not apply:
Which is one of the reason I usually prefer patch being sent as attachment. It also has the good property of giving them a name. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi Jim, Thanks for the comments. I'll go back to attaching patches rather than putting them inline and make the other suggested changes. -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization
On Wed, Feb 20, 2008 at 10:24:18PM -0800, Dave Leskovec wrote:
The following set of patches add the first batch of linux container support to libvirt. The work is not complete but I wanted to start getting some of this out for comments. This set of patches supports the following:
* new switch --with-lxc to enable linux container support (off by default) * virConnectOpen * virConnectClose * virConnectListDomains (of course none are listed since we can't start the containers yet) * virConnectNumOfDomains * virConnectListDefinedDomains * virConnectNumOfDefinedDomains * virDomainLookupByUUID * virDomainLookupByName * virDomainGetInfo * virDomainGetXMLDesc * virDomainDefineXML * virDomainUndefine
A sample XML format that can be used to define a linux container domain: <domain type='linuxcontainer'> <name>TestContainer3</name> <container> <filesystem type='mount'> <source dir='/home/user/lxc_files/etc/'/> <target dir='/etc/'/> </filesystem> <filesystem type='mount'> <source dir='/home/user/lxc_files/var/'/> <target dir='/var/'/> </filesystem> <init>/usr/sbin/container_init</init> </container> <memory>65536</memory> <devices> <console tty='/dev/pts/4'/> </devices> </domain>
Having thought about this all since our previous round of discussions on the matter I'm of the opinion we should /not/ use the <container> block for filesystem setup - it should be part of the <devices> block. This will simplify impl for apps which already have support for dealing with devices and hot add/remove (virDomainAttachDevice/virDomainDetachDevice). The <init> element can stay in <container> or perhap go inside an <os> block since that's where we describe booting for non-container virt. WRT to OpenVZ driver already using <container> we can change it to follow the new style - if we need compat we can let it continue to parse the old style too. 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 -=|
Daniel P. Berrange wrote:
On Wed, Feb 20, 2008 at 10:24:18PM -0800, Dave Leskovec wrote:
A sample XML format that can be used to define a linux container domain: <domain type='linuxcontainer'> <name>TestContainer3</name> <container> <filesystem type='mount'> <source dir='/home/user/lxc_files/etc/'/> <target dir='/etc/'/> </filesystem> <filesystem type='mount'> <source dir='/home/user/lxc_files/var/'/> <target dir='/var/'/> </filesystem> <init>/usr/sbin/container_init</init> </container> <memory>65536</memory> <devices> <console tty='/dev/pts/4'/> </devices> </domain>
Having thought about this all since our previous round of discussions on the matter I'm of the opinion we should /not/ use the <container> block for filesystem setup - it should be part of the <devices> block. This will simplify impl for apps which already have support for dealing with devices and hot add/remove (virDomainAttachDevice/virDomainDetachDevice). The <init> element can stay in <container> or perhap go inside an <os> block since that's where we describe booting for non-container virt.
That makes sense to me. I guess I'd lean towards leaving <init> in the container block since a container isn't really starting a new os image. Perhaps Dan Smith has some comments on this... -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization
DL> That makes sense to me. I guess I'd lean towards leaving <init> DL> in the container block since a container isn't really starting a DL> new os image. Perhaps Dan Smith has some comments on this... Oh I *always* have some comments... :) From the above example, <init> would be the only member of <container>, right? That seems broken to me, unless there are other things planned to be in <container>. In the context of a container, the value of <init> seems suited for the <os> block. From the view of a component that consumes the libvirt XML interface, I think I'd prefer avoiding more domain-level nodes, and would rather the relevant information be packed into existing areas (such as <os> and <devices>) instead of adding a new one (<containers>). -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
DL> That makes sense to me. I guess I'd lean towards leaving <init> DL> in the container block since a container isn't really starting a DL> new os image. Perhaps Dan Smith has some comments on this...
Oh I *always* have some comments... :)
From the above example, <init> would be the only member of <container>, right? That seems broken to me, unless there are other things planned to be in <container>.
Right. For a container, <init> would be the only member of <os> as well right? At the moment, I don't know of anything else that we will be adding to <container>.
In the context of a container, the value of <init> seems suited for the <os> block. From the view of a component that consumes the libvirt XML interface, I think I'd prefer avoiding more domain-level nodes, and would rather the relevant information be packed into existing areas (such as <os> and <devices>) instead of adding a new one (<containers>).
I guess my only hangup there is the case where the value of <init> specifies something that is not an init like application. In that case, at least to me, it seems less suited there. Of course, I don't know how likely or feasible such a use would be. I can definitely agree with your comments from a consumers perspective. I don't have a big problem with moving <init> to the <os> block. -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization
DL> Right. For a container, <init> would be the only member of <os> DL> as well right? At the moment, I don't know of anything else that DL> we will be adding to <container>. No, <os> contains lots of stuff, just none of it applies to a container :) From the perspective of a consumer of the interface, there is only one block that needs to be examined. If you put <init> in <container>, then I have to look at <container> (maybe) in addition to <os> (maybe). DL> I guess my only hangup there is the case where the value of <init> DL> specifies something that is not an init like application. In that DL> case, at least to me, it seems less suited there. But from libvirt's perspective, it's still a virtual machine(-like) entity, regardless of what is really running inside. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
On Thu, Feb 21, 2008 at 02:04:31PM -0800, Dan Smith wrote:
DL> Right. For a container, <init> would be the only member of <os> DL> as well right? At the moment, I don't know of anything else that DL> we will be adding to <container>.
No, <os> contains lots of stuff, just none of it applies to a container :) From the perspective of a consumer of the interface, there is only one block that needs to be examined. If you put <init> in <container>, then I have to look at <container> (maybe) in addition to <os> (maybe).
I always think of '<os>' as providing data about the way your start the virtual machine. eg, the kernel / initrd for paravirt, the BIOS boot device for fullvirt, and thus..... the 'init' process for containers. Oh, pretend you didn't see the '<bootloader>' tag outside the <os> block. A historical mistake :-( 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 -=|
participants (5)
-
Dan Smith -
Daniel P. Berrange -
Daniel Veillard -
Dave Leskovec -
Jim Meyering