* Daniel P. Berrange <berrange(a)redhat.com> [2008-01-15 15:52:13]:
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.
At some point, we'll need resource management extensions to libvirt.
vserver and openVZ both use them and it will also be useful for
containers and kvm/qemu as well. I think we'll need a resource
management feature extension to the XML format.
Currently resource management is provided through control groups (I
can send out links if desired). Ideally once configured the control
groups should be persistent (visible across reboots, so we need to
save state).
Thoughts?
> <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.
--
|=- 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 -=|
--
Libvir-list mailing list
Libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL