[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] [RFC] Add Container support to libvirt



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]