On Mon, Nov 05, 2007 at 01:17:11PM +0000, Daniel P. Berrange wrote: > 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 ':'. So maybe we can avoid that family selector > > + 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 Agreed > > + 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. okay, makes sense, I'm just old fashionned :-) Let's use prefix then > > I'd add that 'interface' should be in a separate <targe> element for > consistency, and 'type=vserver' is probably redundant. We typically use just unless within a vserver domain other kind of interfaces are possible, then yes that's redundant and can probably be avoided. > 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> okay Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list