See replies inline.
Regards,
Gábor
-----Original Message-----
From: M.A. Williamson [mailto:maw48@xxxxxxxxxxxxxxxx] On Behalf Of Mark
Williamson
Sent: dinsdag 27 november 2007 23:42
To: xen-users@xxxxxxxxxxxxxxxxxxx
Cc: Henning Sprang; Nyers, Gabor; Emre Erenoglu
Subject: Re: [Xen-users] Running OS instances within domU or on physical device
I'm cc-ing Emre because he's trying to run domUs on baremetal too and some of
this will be relevant to him.
I think this ought to work, so I'm glad that it worked for you ;-)
The only problem with this sort of thing is where device names etc change
(e.g. some newer XenLinux kernels use hvc0 for the console, others use xvc0
for the console, older ones may use ttyS0 - makes it difficult to configure
for). However, given modern distros identify filesystems by their label
rather than their device, the devsice naming should be less of a problem.
You'll probably need to specify different commandline options to the kernel
depending on whether it's a native one or not (e.g. different console= value,
any Xen-specific or native-specific options).
[G.Nyers> ] That's exactly what happened in my case. Filesystems were
referenced by labels, and xvc0 was already added in /etc/inittab and
/etc/securetty. So after booting on physical hw, I was immediately able to log
in through ssh. (I haven't tried the console, but /etc/inittab contains getty
entries for tty devices, so that shouldn't be a problem)
You also need to add the Xen console device to /etc/securetty(s) and the
native serial console device also, if you use one.
The main gripe with dual booting between native and Xenified is possibly going
to be that the hardware detection routines of your distros will get confused
by (virtual or real) hardware coming and going depending on how you booted.
[G.Nyers> ] Well, I'm not sure "confused" is the right expression, the HW
detection went fine, and the OS configured the HW to its best abilities.
However, because of the OS can't possible know it is used in this peculiar way,
there will be some unintended side effects, depending on e.g. distro etc...:
- Network devices: some distros (eg. SLES or OpenSuSE) like to configure
network devices based on MAC address. That configuration will not be
transparent when booting on physical hw or domU. Nothing a little udev tweaking
couldn't solve though... Btw. in case of RHEL it worked by chance.
- Multipathing: As I mentioned, filesystems have worked, but when the OS was
booted on physical machine, all filesystems on the SAN LUN were accessed
through a single path.
I'm not quite sure how they handle this, or how much of a problem it'd be in
practice. This is also likely to be an issue for HVM/PV dual booting.
Unfortunately, different niggles are also likely to come up depending on which
XenLinux you use. :-(
[G.Nyers> ] Can you give some specific examples?
Cheers,
Mrak
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|