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.

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.