Balbir,
I'd appreciate any links...
How will this configuration be persisted across reboots? Specifically,
once a configuration is set up for a container, who is responsible for
storing this configuration? Will a libvirt driver need to store it
somewhere in it's configuration file(s) or will it be stored somewhere
else by a resource management facility such that it can associated it
with a container after a reboot?
Balbir Singh wrote:
* 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
>
--
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization