[Libvir] [RFC] 0 of 4 Linux Container support
Greetings, Following are the patches adding linux container support. The first three patches are updated versions of the original three I posted. They've been updated for the feedback I've received so far and to include some other recent libvirt changes. The last patch adds support for starting a container. Still working on shutdown and destroy but wanted to get the start code out for comments. The XML format has been updated to this: <domain type='linuxcontainer'> <name>TestContainer1</name> <os> <init>/home/dlesko/src/dev/lxc/lxc_rcinit</init> </os> <memory>65536</memory> <devices> <filesystem type='mount'> <source dir='/home/dlesko/lxc_files/tmp/'/> <target dir='/tmp/'/> </filesystem> <console tty='/dev/ptmx'/> </devices> </domain> All comments and questions are welcome. -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization
On Wed, Mar 19, 2008 at 11:13:44PM -0700, Dave Leskovec wrote:
Greetings,
Hello,
Following are the patches adding linux container support. The first three
Great ! The container/ldom support and the Java bindings are really the two next things I really want to see integrated in the next libvirt releases,
patches are updated versions of the original three I posted. They've been updated for the feedback I've received so far and to include some other recent libvirt changes. The last patch adds support for starting a container. Still working on shutdown and destroy but wanted to get the start code out for comments.
Hum, I would rather avoid the N review passes that we had with the storage and see things commited early in even if they are not complete or working perfectly. It then makes the review of cleanups, fixes and extensions way easier and we don't end up with a huge commit of a lot of stuff. If the code is not in a fully usable shape, just deactivate the configure option by default.
The XML format has been updated to this: <domain type='linuxcontainer'>
I would rather keep the type attribute value small, and if possible the same as the one used for the connection URIs, 'lxr' would be just fine IMHO
<name>TestContainer1</name> <os> <init>/home/dlesko/src/dev/lxc/lxc_rcinit</init> </os> <memory>65536</memory> <devices> <filesystem type='mount'> <source dir='/home/dlesko/lxc_files/tmp/'/> <target dir='/tmp/'/> </filesystem> <console tty='/dev/ptmx'/> </devices> </domain>
All comments and questions are welcome.
What do you think of the idea of commiting parts 1/2/3 once we are done with their second review ? 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/
Daniel Veillard wrote:
On Wed, Mar 19, 2008 at 11:13:44PM -0700, Dave Leskovec wrote:
Greetings,
Hello,
Following are the patches adding linux container support. The first three
Great ! The container/ldom support and the Java bindings are really the two next things I really want to see integrated in the next libvirt releases,
patches are updated versions of the original three I posted. They've been updated for the feedback I've received so far and to include some other recent libvirt changes. The last patch adds support for starting a container. Still working on shutdown and destroy but wanted to get the start code out for comments.
Hum, I would rather avoid the N review passes that we had with the storage and see things commited early in even if they are not complete or working perfectly. It then makes the review of cleanups, fixes and extensions way easier and we don't end up with a huge commit of a lot of stuff. If the code is not in a fully usable shape, just deactivate the configure option by default.
I have it deactivated by default right now because the compile will fail on an older kernel where sched.h does not contain the new namespace clone flags.
The XML format has been updated to this: <domain type='linuxcontainer'>
I would rather keep the type attribute value small, and if possible the same as the one used for the connection URIs, 'lxr' would be just fine IMHO
I'll second Vivek's suggestion for 'lxc' for consistency.
<name>TestContainer1</name> <os> <init>/home/dlesko/src/dev/lxc/lxc_rcinit</init> </os> <memory>65536</memory> <devices> <filesystem type='mount'> <source dir='/home/dlesko/lxc_files/tmp/'/> <target dir='/tmp/'/> </filesystem> <console tty='/dev/ptmx'/> </devices> </domain>
All comments and questions are welcome.
What do you think of the idea of commiting parts 1/2/3 once we are done with their second review ?
I think that'd be great.
Daniel
-- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization
On Thu, Mar 20, 2008 at 10:20:22AM -0700, Dave Leskovec wrote:
Daniel Veillard wrote:
I would rather keep the type attribute value small, and if possible the same as the one used for the connection URIs, 'lxr' would be just fine IMHO
I'll second Vivek's suggestion for 'lxc' for consistency.
Of course !
What do you think of the idea of commiting parts 1/2/3 once we are done with their second review ?
I think that'd be great.
okay, let's try to do this over the next few days, I think I commented on the 3 modules, it can mostly go as is, I would just revamp the configuration parsing as indicated earlier. 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/
On Thu, Mar 20, 2008 at 01:25:05PM -0400, Daniel Veillard wrote:
On Thu, Mar 20, 2008 at 10:20:22AM -0700, Dave Leskovec wrote:
Daniel Veillard wrote:
I would rather keep the type attribute value small, and if possible the same as the one used for the connection URIs, 'lxr' would be just fine IMHO
I'll second Vivek's suggestion for 'lxc' for consistency.
Of course !
What do you think of the idea of commiting parts 1/2/3 once we are done with their second review ?
I think that'd be great.
okay, let's try to do this over the next few days, I think I commented on the 3 modules, it can mostly go as is, I would just revamp the configuration parsing as indicated earlier.
Okay, I did just that, I applied th 3 first patches to CVS and commited after changing the type to 'lxc' and growing the XML buffer size to 16K Let's use patches based on CVS from now on :-) I will look now at cleaning up the parsing code as explained in my review, that I can do easilly, 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/
Daniel Veillard wrote:
On Thu, Mar 20, 2008 at 01:25:05PM -0400, Daniel Veillard wrote:
On Thu, Mar 20, 2008 at 10:20:22AM -0700, Dave Leskovec wrote:
Daniel Veillard wrote:
I would rather keep the type attribute value small, and if possible the same as the one used for the connection URIs, 'lxr' would be just fine IMHO I'll second Vivek's suggestion for 'lxc' for consistency. Of course !
What do you think of the idea of commiting parts 1/2/3 once we are done with their second review ? I think that'd be great. okay, let's try to do this over the next few days, I think I commented on the 3 modules, it can mostly go as is, I would just revamp the configuration parsing as indicated earlier.
Okay, I did just that, I applied th 3 first patches to CVS and commited after changing the type to 'lxc' and growing the XML buffer size to 16K Let's use patches based on CVS from now on :-)
I will look now at cleaning up the parsing code as explained in my review, that I can do easilly,
Daniel
Excellent. Thanks! -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization
On Fri, Mar 21, 2008 at 10:17:35AM -0700, Dave Leskovec wrote:
Daniel Veillard wrote:
I will look now at cleaning up the parsing code as explained in my review, that I can do easilly,
Excellent. Thanks!
No problem, BTW I'm having a bit of troubles with lxcLoadConfig() it loads fine an example xml based on the original from your mail, but then it does: virUUIDFormat(containerDef->uuid, uuidstr); if (!virFileMatchesNameSuffix(file, uuidstr, ".xml")) { which fails, what's the semantic ? The uuid field seems uninitialized, and then the match doesn't work. Are you generating the uuid based on the filename ? Maybe a random one would be fine, but why that check ? Another small issue is that I have the clone flags defined in <linux/sched.h> but not in <sched.h> so I had to add that include to get the module to compile, lxcCheckContainerSupport() check then passes on my Fedora-8 2.6.24 kernel. 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/
On Fri, Mar 21, 2008 at 01:29:07PM -0400, Daniel Veillard wrote:
On Fri, Mar 21, 2008 at 10:17:35AM -0700, Dave Leskovec wrote:
Daniel Veillard wrote:
I will look now at cleaning up the parsing code as explained in my review, that I can do easilly,
Excellent. Thanks!
No problem, BTW I'm having a bit of troubles with lxcLoadConfig() it loads fine an example xml based on the original from your mail, but then it does:
virUUIDFormat(containerDef->uuid, uuidstr); if (!virFileMatchesNameSuffix(file, uuidstr, ".xml")) {
which fails, what's the semantic ? The uuid field seems uninitialized, and then the match doesn't work. Are you generating the uuid based on the filename ? Maybe a random one would be fine, but why that check ?
Another small issue is that I have the clone flags defined in <linux/sched.h> but not in <sched.h> so I had to add that include to get the module to compile, lxcCheckContainerSupport() check then passes on my Fedora-8 2.6.24 kernel.
I filed https://bugzilla.redhat.com/show_bug.cgi?id=438542 to request the flags are added to sched.h too, but we should just #define them in the driver as we do for Xen hypervisor constants. This avoids a hard dependancy between the kernel used for compile, vs running. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Mar 21, 2008 at 05:39:51PM +0000, Daniel P. Berrange wrote:
On Fri, Mar 21, 2008 at 01:29:07PM -0400, Daniel Veillard wrote:
Another small issue is that I have the clone flags defined in <linux/sched.h> but not in <sched.h> so I had to add that include to get the module to compile, lxcCheckContainerSupport() check then passes on my Fedora-8 2.6.24 kernel.
I filed
https://bugzilla.redhat.com/show_bug.cgi?id=438542
to request the flags are added to sched.h too, but we should just #define them in the driver as we do for Xen hypervisor constants. This avoids a hard dependancy between the kernel used for compile, vs running.
Is that really better than #include <linux/sched.h> ? That code is linux specific after all .. 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/
On Fri, Mar 21, 2008 at 04:35:34PM -0400, Daniel Veillard wrote:
On Fri, Mar 21, 2008 at 05:39:51PM +0000, Daniel P. Berrange wrote:
On Fri, Mar 21, 2008 at 01:29:07PM -0400, Daniel Veillard wrote:
Another small issue is that I have the clone flags defined in <linux/sched.h> but not in <sched.h> so I had to add that include to get the module to compile, lxcCheckContainerSupport() check then passes on my Fedora-8 2.6.24 kernel.
I filed
https://bugzilla.redhat.com/show_bug.cgi?id=438542
to request the flags are added to sched.h too, but we should just #define them in the driver as we do for Xen hypervisor constants. This avoids a hard dependancy between the kernel used for compile, vs running.
Is that really better than #include <linux/sched.h> ? That code is linux specific after all ..
Yes it is questionable, but GLibC already contains all the other CLONE_XXX flags which are Linux specific, so I figured we might as well see if they want to include the new ones too. In any case I figure we should #ifdef & #define the new constants in lxc_driver.c, because many people's kernel headers lag behind the kernel they're compiling for. It is only recent Fedora practice to actually have the kernel headers synced to real kernel tree. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
snip...
The XML format has been updated to this: <domain type='linuxcontainer'>
I would rather keep the type attribute value small, and if possible the same as the one used for the connection URIs, 'lxr' would be just fine IMHO
I suggest 'lxc' since that is what we are using for containers anyway (see lxc.sf.net). thanks, Vivek
<name>TestContainer1</name> <os> <init>/home/dlesko/src/dev/lxc/lxc_rcinit</init> </os> <memory>65536</memory> <devices> <filesystem type='mount'> <source dir='/home/dlesko/lxc_files/tmp/'/> <target dir='/tmp/'/> </filesystem> <console tty='/dev/ptmx'/> </devices> </domain>
All comments and questions are welcome.
What do you think of the idea of commiting parts 1/2/3 once we are done with their second review ?
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/
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
__ Vivek Kashyap Linux Technology Center, IBM
On Thu, Mar 20, 2008 at 09:46:05AM -0700, Vivek Kashyap wrote:
snip...
The XML format has been updated to this: <domain type='linuxcontainer'>
I would rather keep the type attribute value small, and if possible the same as the one used for the connection URIs, 'lxr' would be just fine IMHO
I suggest 'lxc' since that is what we are using for containers anyway (see lxc.sf.net).
yes, of course :-) 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/
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Dave Leskovec -
Vivek Kashyap