[Libvir] [PATCH] Linux-VServer support
This patch implements support for Linux-VServer guests. It is currently missing vcpu and console support, and the necessary virsh code to support it, but is otherwise pretty feature complete. This is an XML dump from one of my guests: <domain type='vserver' id='40010'> <name>lenny</name> <uuid>19e12957-261a-5a06-d6d0-89917d6d439f</uuid> <memory>2048000</memory> <os> <hostname>lenny.test</hostname> <type arch='i686'>vserver</type> </os> <devices> <interface type='ethernet'> <ip prefix='24' interface='dummy0' address='192.168.20.4' /> </interface> <interface type='ethernet'> <ip prefix='24' interface='dummy0' type='range' address='192.168.32.100' address2='192.168.32.200'/> </interface> <disk type='directory' device='directory'> <source directory='/vservers/lenny' type='auto' options='defaults'/> <target directory='/'/> </disk> <disk type='directory' device='directory'> <source directory='/srv' type='ext3' options='bind,ro'/> <target directory='/srv'/> </disk> <disk type='block' device='directory'> <source dev='/dev/mapper/test' type='ext3' options='defaults'/> <target directory='/mnt'/> </disk> </devices> </domain> -- Daniel Hokka Zakrisson
On Wed, Jan 09, 2008 at 10:51:20PM +0100, Daniel Hokka Zakrisson wrote:
This patch implements support for Linux-VServer guests. It is currently missing vcpu and console support, and the necessary virsh code to support it, but is otherwise pretty feature complete.
This is an XML dump from one of my guests: <domain type='vserver' id='40010'> <name>lenny</name> <uuid>19e12957-261a-5a06-d6d0-89917d6d439f</uuid> <memory>2048000</memory> <os> <hostname>lenny.test</hostname> <type arch='i686'>vserver</type> </os> <devices> <interface type='ethernet'> <ip prefix='24' interface='dummy0' address='192.168.20.4' /> </interface>
Minor nitpick - if dummy0 is the device associated with the container in the host's context, then it should be <interface type='ethernet'> <ip prefix='24' address='192.168.20.4' /> <target dev="dummy0"/> </interface>
<interface type='ethernet'> <ip prefix='24' interface='dummy0' type='range' address='192.168.32.100' address2='192.168.32.200'/> </interface> <disk type='directory' device='directory'> <source directory='/vservers/lenny' type='auto' options='defaults'/> <target directory='/'/> </disk>
I think I'd prefer to call these '<filesystem>' elements instead of '<disk>' because they don't really have the same functional properties as disks. Are the sources actual directories too ? Or are the sources block devs / files which are mounted inside ? The example paths suggest the former, but the presence of filesystem type info suggests the latter. 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, Jan 09, 2008 at 10:51:20PM +0100, Daniel Hokka Zakrisson wrote:
This patch implements support for Linux-VServer guests. It is currently missing vcpu and console support, and the necessary virsh code to support it, but is otherwise pretty feature complete.
This is an XML dump from one of my guests: <domain type='vserver' id='40010'> <name>lenny</name> <uuid>19e12957-261a-5a06-d6d0-89917d6d439f</uuid> <memory>2048000</memory> <os> <hostname>lenny.test</hostname> <type arch='i686'>vserver</type> </os> <devices> <interface type='ethernet'> <ip prefix='24' interface='dummy0' address='192.168.20.4' /> </interface>
Minor nitpick - if dummy0 is the device associated with the container in the host's context, then it should be
<interface type='ethernet'> <ip prefix='24' address='192.168.20.4' /> <target dev="dummy0"/> </interface>
<interface type='ethernet'> <ip prefix='24' interface='dummy0' type='range' address='192.168.32.100' address2='192.168.32.200'/> </interface> <disk type='directory' device='directory'> <source directory='/vservers/lenny' type='auto' options='defaults'/> <target directory='/'/> </disk>
I think I'd prefer to call these '<filesystem>' elements instead of '<disk>' because they don't really have the same functional properties as disks.
Overloading <disk> was done mostly to keep in line with the other backends. I'd rather just add some logic to attach-disk than an entirely separate attach-filesystem...
Are the sources actual directories too ? Or are the sources block devs / files which are mounted inside ? The example paths suggest the former, but the presence of filesystem type info suggests the latter.
Either. That's what the <disk type='directory'> specifies, and the point of the second example using type='block'. type='file' is also supported, when used in conjuction with options='defaults,loop'.
Dan.
-- Daniel Hokka Zakrisson
On Tue, Jan 15, 2008 at 03:43:37PM +0000, Daniel P. Berrange wrote:
On Wed, Jan 09, 2008 at 10:51:20PM +0100, Daniel Hokka Zakrisson wrote:
This patch implements support for Linux-VServer guests. It is currently missing vcpu and console support, and the necessary virsh code to support it, but is otherwise pretty feature complete.
This is an XML dump from one of my guests: <domain type='vserver' id='40010'> <name>lenny</name> <uuid>19e12957-261a-5a06-d6d0-89917d6d439f</uuid> <memory>2048000</memory> <os> <hostname>lenny.test</hostname> <type arch='i686'>vserver</type> </os> <devices> <interface type='ethernet'> <ip prefix='24' interface='dummy0' address='192.168.20.4' /> </interface>
Minor nitpick - if dummy0 is the device associated with the container in the host's context, then it should be
<interface type='ethernet'> <ip prefix='24' address='192.168.20.4' /> <target dev="dummy0"/> </interface>
One other question - when inside the container what does 'ifconfig' show - do you actually see a dummy0 interface present - or is this all hidden from admin view inside the container? If there is a device visible, then it makes sense to have the <interface> tag within the <devices> section as you illustrate. If there is no device visible inside the container then we should use the <network> tag within <container> as per OpenVZ XML format.
<disk type='directory' device='directory'> <source directory='/vservers/lenny' type='auto' options='defaults'/> <target directory='/'/> </disk>
I think I'd prefer to call these '<filesystem>' elements instead of '<disk>' because they don't really have the same functional properties as disks.
Are the sources actual directories too ? Or are the sources block devs / files which are mounted inside ? The example paths suggest the former, but the presence of filesystem type info suggests the latter.
Oh, and for consistency with existing OpenBZ driver, I think the <filesystem> tag should be within a <container> element instead of <devices> since its not really a device per-se. 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 Tue, Jan 15, 2008 at 03:43:37PM +0000, Daniel P. Berrange wrote:
On Wed, Jan 09, 2008 at 10:51:20PM +0100, Daniel Hokka Zakrisson wrote:
This patch implements support for Linux-VServer guests. It is currently missing vcpu and console support, and the necessary virsh code to support it, but is otherwise pretty feature complete.
This is an XML dump from one of my guests: <domain type='vserver' id='40010'> <name>lenny</name> <uuid>19e12957-261a-5a06-d6d0-89917d6d439f</uuid> <memory>2048000</memory> <os> <hostname>lenny.test</hostname> <type arch='i686'>vserver</type> </os> <devices> <interface type='ethernet'> <ip prefix='24' interface='dummy0' address='192.168.20.4' /> </interface>
Minor nitpick - if dummy0 is the device associated with the container in the host's context, then it should be
<interface type='ethernet'> <ip prefix='24' address='192.168.20.4' /> <target dev="dummy0"/> </interface>
One other question - when inside the container what does 'ifconfig' show - do you actually see a dummy0 interface present - or is this all hidden from admin view inside the container? If there is a device visible, then it makes sense to have the <interface> tag within the <devices> section as you illustrate. If there is no device visible inside the container then we should use the <network> tag within <container> as per OpenVZ XML format.
dummy0 is visible inside.
<disk type='directory' device='directory'> <source directory='/vservers/lenny' type='auto'
options='defaults'/>
<target directory='/'/> </disk>
I think I'd prefer to call these '<filesystem>' elements instead of '<disk>' because they don't really have the same functional properties as disks.
Are the sources actual directories too ? Or are the sources block devs / files which are mounted inside ? The example paths suggest the former, but the presence of filesystem type info suggests the latter.
Oh, and for consistency with existing OpenBZ driver, I think the <filesystem> tag should be within a <container> element instead of <devices> since its not really a device per-se.
Which would make virDomainAttachDevice rather awkward... But see my other email, I think it belongs in <devices>. Personally, I think that <container> should only be used for things which have no mapping whatsoever in the other backends, e.g. how to start it. For storage and networking on the other hand, consistency is good.
Dan.
-- Daniel Hokka Zakrisson
participants (2)
-
Daniel Hokka Zakrisson -
Daniel P. Berrange