On Tue, 15 Jan 2008, Paul Dekkers wrote:
virt-install just doesn't seem worth it to me to be honest. I'd rather
write my own configuration and just boot that, editing it for pygrub etc.
after install. Thanks for the confirmation though!
Works too, this saves me some time I guess, (and one command like this is
easily documented ;-))
We have documents too, plus it's a learning experience creating the
configuration files (although we have a template with lots of helpful
comments so there's no mystery!).
Oh, and as for PAE: the kernel is using the 4G in this machine, so I
suppose PAE is working fine too; performance seems OK, never compared it
with a 64-bit environment though.
Yeah, I've just booted my RHEL5.1 installation post kickstart and saw:
(XEN) PAE enabled, limit: 16GB
So that's good (-:
I'm using something similar to (fill in the dots):
virt-install --name=test32 --nographics --paravirt --ram=512
--file=/dev/vg0/test --location=http://.../
--extra-args=ks=http://.../ks.cfg
OK, how does test32 get access to the kickstart file given that that's
where test32's network information is stored? Does virt-install pass
the contents of ks.cfg to test32 somehow during initialisation?
No, the kickstart does DHCP, you can pass an ip-address in the
extra-args among with the kickstart though, if you like (or if there is
no DHCP available),
Ah, right. We don't allow DHCP on the server VLANs for security reasons.
Do you use more --extra-args= arguments for ip= netmask= and subnet=, etc.
or enclose the whole thing in speechmarks and use just the one?
(My kickstart includes a RHN registration using an activation key, and
the ifup-local script, that does a ethtool -K eth0 tx off, as that is
apparently necessary for traffic between domU's.)
Curious. I've never seen anyone do that before. I don't usually
register an installation with RHN until after reboot and first login.
That works too of course, but this saves some work ;-)
and I like to run an up2date at this stage too, so you have an
up-to-date start,
Ah well, we choose to boot the box once first before we do stuff like that.
Our post installation configuration is... hairy to say the least so we like
to make sure the box is stable before we spend time updating it (-:
Plus I put the activation key in the main body of the kickstart with
key xxxx-xxxx-xxxx-xxxx
Ah, ok. Well, you don't need that with RHEL 4, do you?
*blush* Confusion between activation key and installation key (-:
[The thing that doesn't work]
Yes, sad that it's not available yet, but now we have something to look
forward too ;-)
Maybe we'll be able to simply transpose the guests from the 32-bit host to a
64-bit. That would be nice.
No, thanks, lots of good corroborative evidence. If you want to explain
(please) that kickstart file thing off the list, I'd be grateful!
I hope this is what you meant,
Good enough! Thanks.
Ben
--
Unix Support, MISD, University of Cambridge, England
Plugger of wire, typer of keyboard, imparter of Clue
Life Is Short. It's All Good.
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
