[et-mgmt-tools] Cobbler query (and now Xen too)

[Michael DeHaan]

Chris Sarginson wrote:
> Hi Michael,
>
> I forgot about the sub profiles being able to override things like 
> that, so thats a (good) alternate way of doing things, thanks.
>
> I have a couple of other queries:
>
> 1) When using the xen kernel to do the installation, I assume that is 
> not doing hardware virtualisation at all?

Currently yes, as I understand it the virtinst library will have PXE 
support in a release soon (at least in F7/F8?), and at that point we can 
do fullvirt.   Right now, since fullvirt installs require a disk image 
for provisioning (they can't just be fed a kernel+initrd), we can only 
do paravirt Xen.   However, KVM does allow this currently, so there
we are doing hardware.     We should have something for Xen soon.  
> 2) When not using the xen kernel to do the installation (which I can 
> do if I create the VM manually) I get the following error:
>
> xend.err "Error creating domain: (2, 'Invalid kernel', 
> 'xc_dom_find_loader: no loader found
>
Right... for paravirt Xen you have to use a kernel with "xen" in it.
> 3) When using the xen kernel to start the VM I get the following error:
>
> xend.err "Boot loader didn't return any data!

I'm not sure what that is, actually.   We'd need the logs from 
/var/log/xen/xend.log to see for sure.     There may also be some 
relevant logs in ~/.koan

>
> 4) Are there plans to further expand cobbler to allow you to select 
> the number of virtual CPU's available?
>
That's easy to do, and there was a patch for it at some point -- which I 
believe got lost in the shuffle.   I'll add it.

RFE filled so I don't forget:  
https://hosted.fedoraproject.org/projects/cobbler/ticket/27 :)

> Chris
>
> Michael DeHaan wrote:
>
>> The idea is that a profile should represent what the system does and 
>> is... the kickstart file, the RAM requirements, the disk 
>> requirements, and so forth -- to keep all of those things together to 
>> make a configuration like "virtual-webserver" completely reproducible 
>> and consistant.     In the end, that might even make there be less to 
>> configure, as you wouldn't need to create the per-system records.  An 
>> example of this is a development or test environment -- that profile 
>> might be rolled out an arbitrary number of times, and you wouldn't 
>> neccessarily want to require a cobbler record for every instance of 
>> that environment.  You'd just use koan with "--virt" and 
>> "--profile=development-environ".  Now, in an environment where you 
>> need DHCP reservations, then yes, you'd want the per-system records.  
>> How many profiles is insane, by the way?  :)  One thing that we have 
>> in Cobbler that is intended to help make this more manageable are the 
>> concept of inherited profiles.
>>
>> The idea is that you could do:
>>    cobbler profile add  --name=webserver-base ....  --distro=blah
>>    cobbler profile add --name=webserver-base-moreram --virt-ram=1024 
>> --inherit=webserver-base
>>
>> So, if you want to modify the profile "webserver-base" it would make 
>> changes to all of the subprofiles for you.   That may help.
>>
>> koan does offer some local overrides, --virt-name, --virt-disk, 
>> --virt-bridge ... though we try to keep those minimal since it's 
>> supposed to be a central management way
>> of doing things.    Those are there for those folks who want to take 
>> advantage of a cobbler server outside of their normal working 
>> environment -- for instance, a standalone
>> box outside of a datacenter needs to install a cobbler profile, but 
>> the default image location does not suit the environment, etc.
>>
>> Anyhow, let me know if the inherited profiles might work for you ... 
>> if not, we can think about whether per-system overrides of everything 
>> in the profile object
>> is a good idea or not.   I'm willing to remove those restrictions if 
>> enough folks find them valuable, though I still think profiles (and 
>> sub-profiles) are a very meaningful
>> abstraction.   For Web UI uses, we may even leave those overrides 
>> under an "advanced" tab or something of the like, to still encourage 
>> creation of task-specific
>> profiles.
>>
>> Thoughts?
>>
>> --Michael
>>
>>
>>
>> _______________________________________________
>> et-mgmt-tools mailing list
>> et-mgmt-tools at redhat.com
>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>