Matthias Saou wrote:
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.
It is, it's just not being displayed :)
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.
That works too. Specify two LVM volumes
It was too early for my brain to notice the "/dev" in your path,
apparently :)
Names in LVM volumes are carved out based on the name of the virtual
machine.
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.
Kind of, yes. I'm trying to enforce the idiom of mapping systems to what
they do.
It's an important abstraction if you want to avoid managing a very large
pool of systems
with nothing in common, and especially important when you start scaling
up into a very
large number of systems (say, thousands). It makes things both
predictable and repeatable.
Inherited profiles are really there so that you can manage batches of
profiles with some
things in common (for instance, all db servers), but you might want to
inherit from that
profile to set settings that are site specific, or specific to a certain
type of needy hardware.
This makes interchanging hardware repeatable, because you contain that
information
in the profile, not in the individual (and non-reusable) system object.
It does seem like the WebUI doesn't currently know of inherited
profiles, though.
You are too observant :)
This will likely come in a later release, when we figure out how to show
those relationships best. Not a ton of people use them and I didn't want
to add the complexity early on.
Thanks for all your help :-)
No problem. Thanks for all the good feedback and info on your
environment. It's useful
to hear from folks about this kind of thing.
Matthias
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
