* Daniel P. Berrange <berrange@xxxxxxxxxx> [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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list