[Libvir] [RFC] Linux-VServer support

Daniel P. Berrange berrange at redhat.com
Mon Nov 5 13:17:11 UTC 2007


On Mon, Nov 05, 2007 at 05:33:02AM -0500, Daniel Veillard wrote:
> On Thu, Nov 01, 2007 at 03:09:00AM +0100, Daniel Hokka Zakrisson wrote:
> > 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 ?

Trivially - IPv4 is guarenteed to have a '.', and IPv6 is guarentted to have ':'.

> 	+ 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> ?

I'd go for multiple <ip> tags inside the single <interface> tag, because this
works in scenario where ythe 2nd address is a different family, or needs a
different prefix 

> 	+ 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"

Prefix is now preferred nomenculture for what used to be called netmask. The
use of netmask is impratical in IPv6 world. You can trivially convert between
the two in an app if you need the legacy netmask. 

Basically, prefix refers to the number of bits in the address which are
significant. eg, the number of bits set to 1, in the netmask.


I'd add that 'interface' should be in a separate <targe> element for
consistency, and 'type=vserver' is probably redundant. We typically use just
type='ethernet' for a plain interface (ie one not bridged)

      <inteface type='ethernet'>
         <ip address="1.2.3.4" prefix='24'/>
         <target dev='eth0'/>
      </interface>

      <inteface type='ethernet'>
         <ip address="1.2.3.4" prefix='24'/>
         <ip address="dead:beef:dead:beed::1" prefix='48'/>
         <target dev='eth0'/>
      </interface>

Regards,
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  -=| 




More information about the libvir-list mailing list