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