[Libvir] [RFC] Linux-VServer support

[Daniel Hokka Zakrisson]

Daniel Veillard wrote:
> On Thu, Nov 01, 2007 at 03:09:00AM +0100, Daniel Hokka Zakrisson wrote:
>> Daniel Veillard wrote:
>>> On Wed, Oct 31, 2007 at 02:39:05PM +0100, Daniel Hokka Zakrisson wrote:
>>>> Daniel Veillard wrote:
>>>>> I looked at the code, that seems clean but I have a concern about the
>>>>> overall XML format. Could you paste a couple of examples. Also I think
>>>>> Linux-VServer and OpenVZ kind of configuration may end up with the same
>>>>> kind of limitations or differences, so I would like to try to harmonize
>>>>> both format when possible.
>>>> Currently, the XML format is really limited. Are there any docs on what 
>>>> should be there, or should I just look at the other drivers? As far as 
>>>> harmonizing with the OpenVZ driver, I'm fine with that, but it seems to 
>>>> be pretty limited and, to some degree at least, ugly.
>>>  Harmonizing the XML formats shouldn't be that hard ...
>>> We discussed the OpenVZ format there
>>>  http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html
>>> and around there earlier:
>>>  http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html
>>> For network settings
>>>  http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
>>>
>>> <snip>
>> After looking at the various drivers, this is what I propose:
>>
>> <domain type='vserver' id='2000'>
>>   <name>testvm</name>
>>   <memory>500000</memory>
>>   <scheduler fill_rate1='100' interval1='1000'>
>>     <cpu id='0' fill_rate1='0'/>
>>     <cpu id='1' fill_rate1='250' interval1='1000' idle_time='1' 
>> fill_rate2='250' interval2='1000'/>
>>   </scheduler>
>>   <container>
>>     <uts hostname='testvm' machine='i586'/>
>>     <distribution method='debootstrap' release='etch'/>
>>   </container>
>>   <devices>
>>     <disk type='path' device='path'>
>>       <source path='/vservers/testvm'/>
>>       <target path='/'/>
>>     </disk>
>>     <disk type='block' device='path'>
>>       <source dev='/dev/hda4'/>
>>       <target path='/var'/>
>>     </disk>
>>     <disk type='path' device='path'>
>>       <source path='/home/testvm'/>
>>       <target path='/home'/>
>>     </disk>
>>     <interface type='vserver'>
>>       <ip family='IPv4' address='1.2.3.4' prefix='24' interface='eth0'/>
>>     </interface>
>>     <interface type='vserver'>
>>       <ip family='IPv4' address='4.3.2.1' address2='4.3.2.200' 
>> prefix='24' type='range'/>
>>     </interface>
>>     <interface type='vserver'>
>>       <ip family='IPv6' address='dead:beef:dead:beef::1' prefix='64' 
>> interface='eth0'/>
>>     </interface>
>>   </devices>
>> </domain>
> 
>   That looks mostly fine to me except a few doubts about:
>      - <scheduler> this is tuning and we need a global discussion about this
>        we allowed something similar for OpenVZ but this need to be discussed
>        more globally.

Okay.

>      - what are the ranges for the values of <container> elements and attributes

I don't understand what this question means.

>        <uts> seems to be OS metadata, we already have an <os> element in
>        existing configs why not reuse that.

Ah, yes, I missed that. How about:
   <os>
     <type machine='i586'>vserver</type>
     <hostname>testvm</hostname>
     <release>2.6.12</release>
     <distribution method='debootstrap'>etch</distribution>
   </os>

>      - some of the <ip> args are new, i.e. have no equivalent in existing 
>        config file uses:
>         + family: that looks okay to me, is that mandatory ? Could that
> 	  be guessed from one of the addresses given ?

Yes.

> 	+ address2: what does that mean ? I understand one IP address being
> 	  served but since there is not really a notion of physical interface
> 	  why attach 2 address instead of defining 2 <interface> ?

This is only valid for the type='range' IPs, meaning all addresses in 
the range address-address2 are assigned to the guest.

> 	+ prefix: could you explain what this means ? if it's a netmask
> 	  let's use something like netmask="255.255.255.0" instead of 
> 	  prefix="24"
> 
> 
>> I realize this is not at all similar to what the OpenVZ driver does, but 
>> if necessary I could update that to use a similar scheme (though limited 
>> in testing).
> 
>   
> 


-- 
Daniel Hokka Zakrisson