Hi,
Rumor has it that on Fri, Jan 20, 2006 at 03:36:33PM -0500 Stephen Tweedie said:
> Hi,
>
> On Thu, Jan 19, 2006 at 12:19:53PM -0500, Jeremy Katz wrote:
>
> > Unfortunately, I am completely convinced that the right thing is to have
> > the kernel for domU inside the domU's filesystem because anything else
> > is just fundamentally not manageable.
>
> I tend to agree. The real trouble starts when the storage needed to
> boot that domU isn't even visible to the dom0, though --- perhaps
> because we've got a virtual HBA (say an iSCSI initiator, or virtual FC
> HBA), connected to a SAN which is filtering by initiator so that only
> the domU can see the LUN's contents.
>
> Bootstrapping that sort of environment is nasty.
>
Indeed. I agree with the domU filesystem approach as well.
How does one boot off of software iSCSI on a physical machine now?
There's clearly no boot ROM. I'm guessing people use PXE. Then
it's up to the initrd or initramfs to have the iSCSI smarts.
In that case the domU pre-boot would need to support vbd, v-nics and
have a PXE client.
Someone would have to serve the PXE requests and handle the images
for that of course. But I think treating it more like a BIOS on
a physical machine rather than something that boots in ways that
a physical machine doesn't. The more like real machines the VMs look
the better.
Of course, that would mean support for root on iSCSI in the installer
and mkinitrd code.
Anyway, my 2 cents...
Cheers,
Phil
> > So, perhaps we do have to just
> > suck it up and go the path of what's essentially mini-OS as a domU
> > "bios"
>
> If the domU pre-boot is going to have to have enough smarts to run a
> full iSCSI initiator then we might be better off just biting the
> bullet and running a proper kernel there with either kexec, or some
> manner of domU respawn, to boot the correct kernel/initrd once the
> pre-boot one has downloaded them. Either that, or we basically need
> to have special cases for /boot to make sure that those files, plus
> the grub.conf-type kernel args, are registered elsewhere (directory?)
> for the dom0 to get them from.
>
> --Stephen
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
--
Philip R. Auld, Ph.D. Egenera, Inc.
Software Architect 165 Forest St.
(508) 858-2628 Marlboro, MA 01752
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home