12:24 a.m.
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
4:11 a.m.
Dave Leskovec <dlesko(a)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
8:34 a.m.
On Thu, Feb 21, 2008 at 11:11:40AM +0100, Jim Meyering wrote:
Dave Leskovec <dlesko(a)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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
12:40 p.m.
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
8:51 a.m.
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 -=|
1:15 p.m.
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
2:34 p.m.
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(a)us.ibm.com
4:01 p.m.
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
4:04 p.m.
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(a)us.ibm.com
4:10 p.m.
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 -=|
6119
days inactive
6119
days old
9 comments
5 participants
participants (5)
-
Dan Smith -
Daniel P. Berrange -
Daniel Veillard -
Dave Leskovec -
Jim Meyering