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?
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
3) When using the xen kernel to start the VM I get the following error:
xend.err "Boot loader didn't return any data!
4) Are there plans to further expand cobbler to allow you to select the
number of virtual CPU's available?
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
--
Kind regards
Chris Sarginson
Technical Support
UKFast.Net Ltd
(t) 0870 111 8866
(f) 0870 458 4545
"The UK's Best Hosting Provider" ISPA Awards 2007, 2006 and 2005
Dedicated Servers - Managed Hosting - Domain Names- http://www.ukfast.net
UKFast.Net Ltd, City Tower, Piccadilly Plaza, Manchester, M1 4BT
Registered in England. Number 384 5616
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
