Dave Leskovec wrote:
Thanks again for the feedback. I've made the following
additional
recommended changes:
* Changed filesystem tag for consistency
* Changed network spec to match most recent OpenVZ format. The latest
OpenVZ format I could find was here:
https://www.redhat.com/archives/libvir-list/2007-August/msg00209.html
Shuveb - does this line up with what OpenVZ is now using?
* Removed cpushare and memory tuning parameters
Memory is fine, it's only CPU tuning that's not in the XML.
Updated format:
<domain type='linuxcontainer'>
<name>Container123</name>
<uuid>8dfd44b31e76d8d335150a2d98211ea0</uuid>
<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>
<application>/usr/sbin/container_init</application>
Could we call this init instead? Or boot?
<network>
<ipaddress>192.168.1.110</ipaddress>
<hostname>browndog</hostname>
<gateway>192.168.1.1</gateway>
<nameserver>192.168.1.1</nameserver>
<netmask>255.255.255.0</netmask>
</network>
</container>
<devices>
<console tty='/dev/pts/4'/>
</devices>
</domain>
As always, all comments and questions are welcome.
Daniel P. Berrange wrote:
> On Tue, Jan 15, 2008 at 12:26:43AM -0800, Dave Leskovec wrote:
>
>> Greetings,
>>
>> Following up on the XML format for the Linux Container support I
>> proposed... I've made the following recommended changes:
>> * Changed mount tags
>> * Changed nameserver tag to be consistent with gateway
>> * Moved cpushare and memory tags outside container tag
>>
>> This is the updated format:
>> <domain type='linuxcontainer'>
>> <name>Container123</name>
>> <uuid>8dfd44b31e76d8d335150a2d98211ea0</uuid>
>> <container>
>> <filesystem>
>> <mount>
>> <source dir="/home/user/lxc_files/etc/"/>
>> <target dir="/etc/"/>
>> </mount>
>> <mount>
>> <source dir="/home/user/lxc_files/var/"/>
>> <target dir="/var/"/>
>> </mount>
>> </filesystem>
>>
>
> Comparing this to the Linux-VServer XML that Daniel posted, you're both
> pretty much representing the same concepts so we need to make a decision
> about which format to use for filesystem mounts.
>
> OpenVZ also provides a /domain/container/filesystem tag, though it
> uses a concept of filesystem templates auto-cloned per container
> rather than explicit mounts. I think I'd like to see
>
> <filesystem type="mount">
> <source dir="/home/user/lxc_files/etc/"/>
> <target dir="/etc/"/>
> </filesystem>
>
> For the existing OpenVZ XML, we can augment their <filesystem> tag with
> an attribute type="template".
>
>
>> <application>/usr/sbin/container_init</application>
>> <network hostname='browndog'>
>> <ip address="192.168.1.110"
netmask="255.255.255.0"/>
>> <gateway address="192.168.1.1"/>
>> <nameserver address="192.168.1.1"/nameserver>
>> </ip>
>> </network>
>>
>
> Again this is pretty similar to needs of VServer / OpenVZ. In the
> existing
> OpenVZ XML, the gateway and nameserver tags are immediately within the
> <network> tag, rather than nested inside the <ip> tag. Aside from that
> it
> looks to be a consistent set of information.
>
>
>> </container>
>> <cpushare>40</cpushare>
>>
>
> As Daniel points out, we've thus far explicitly excluded tuning info
> from
> the XML. Not that I have any suggestion on where else to put it at this
> time. This is a minor thing though, easily implemented once we come to a
> decision.
>
>
>> <memory>65536</memory>
>> <devices>
>> <console tty='/dev/pts/4'/>
>> </devices>
>> </domain>
>>
>> Does this look ok now? All comments and questions are welcome.
>>
>
> Pretty close.
>
> Dan.
>
--
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization
--
Daniel Hokka Zakrisson