[Libvir] [RFC] Linux-VServer support

Daniel Veillard veillard at redhat.com
Mon Nov 5 10:33:02 UTC 2007


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.
     - what are the ranges for the values of <container> elements and attributes
       <uts> seems to be OS metadata, we already have an <os> element in
       existing configs why not reuse that.
     - 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 ?
	+ 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> ?
	+ 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).

  

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/




More information about the libvir-list mailing list