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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
