[et-mgmt-tools] Cobbler and Koan for _my_ needs

Matthias Saou thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net
Thu Sep 27 15:47:39 UTC 2007


Michael DeHaan wrote :

> Hmm, this looks like leftover bits from when the name had to be a MAC. 
> Since the MAC
> is a seperate field now, I'll see why it's not being used if it's provided.
> 
> However, even so, you can still add the optional parameter --virt-name 
> to name your guest.
> 
> koan --virt --system=AA:BB:CC:DD:EE:FF --server=cobbler.example.org --virt-name=blinky

Indeed, this is fine as a temporary workaround :-)

FWIW, using koan --display seems to imply that the MAC address isn't
getting sent by Cobbler.

> > I don't want to override anything on the koan command line. I'm more
> > than fine with having everything in Cobbler!
> >
> > But in my case, I'd need my profile to be :
> > - virt_path: /dev/data/$name,/dev/data/swap$name
> >   (I'm not sure if this can be done, I can live with overriding it in
> >    all system configurations, which is what I've done for now)
> > - virt_ram: 512
> >   
> This would put them in two directories, which should be sufficient:
> 
> --virt-path=/dev/data,/dev/data/swap/

I'm actually using unpartitioned LVM volumes for my guests :-) So the
above uses the pre-created /dev/data/test and /dev/data/swaptest LVs.
My tests have shown better performance that with files.

I haven't tried not having the LVs pre-created and using
"virt-path: '/dev/data/$name,/dev/data/swap$name'" with
"virt_file_size: 4,2", but I suspect it won't work :-)

> > Then the default system associated to be :
> > - virt_path: <<inherit>>
> > - virt_ram: <<inherit>>
> > ...where I only change the name, hostname and MAC address.
> >
> > Here I'd like to be able to change virt_ram on a per-system basis, but
> > it doesn't seem possible currently (or maybe I just need to "manually"
> > add it to the system file?).
> >   
> It's not like we couldn't add it, it just seems to go against the design 
> of having profiles
> that define the requirements of what they are running. This is the same 
> reason you
> can't request more virtual disk for a specific system -- the idea is 
> that you would
> use inherited profiles to do this, and then just map the system to the 
> profile that it
> was going to be assigned to.

This will basically add one layer of configuration for very little to
no gain in my case. I can live with that and do understand that the
line must be hard to draw between inherited profiles and systems.

It does seem like the WebUI doesn't currently know of inherited
profiles, though.

Thanks for all your help :-)

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 7 (Moonshine) - Linux kernel 2.6.22.6-81.fc7
Load : 0.31 0.43 0.38




More information about the et-mgmt-tools mailing list