grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xen vs. GRUB


From: Ian C. Blenke
Subject: Re: Xen vs. GRUB
Date: Mon, 08 Jan 2007 13:56:32 -0500
User-agent: Debian Thunderbird 1.0.6 (X11/20050914)

Samuel Thibault wrote:

Thomas Schwinge, le Wed 03 Jan 2007 13:09:25 +0100, a écrit :
Is there a consensus that GRUB (or rather GRUB2) should be ported to
allow them to run in a Xen environment?

I'm not sure grub on Xen would be so useful, since people usually choose
their operating system and parameters directly from Xen configuration
files.  And I actually already contacted Xen people, and they agree that
adding a multiboot-like module abstraction to Xen won't be hard and
would be useful.

Xen PV domUs can boot from "pygrub". This is the method used by JailTime and rPath to encapsulate kernels and initrd inside the disk images.

So there is already such a "port". Just specify a bootloader in your xen config:

   bootloader="/usr/lib/xen/bin/pygrub"

and it's easy enough to override the config file with your own boot entry:

   bootentry="hda1:/boot/vmlinuz-xen,/boot/initrd-xen"

Which does seem a bit silly when you can specify the same thing with root=, ramdisk=, and anything else with extra=. Alternatively, there are libvirt and xen-tools and other xen config abstrations outside of xm.

Xen HVM domUs, on the other hand, bootstrap whatever MBR is installed on the virtual disk. No changes needed here at all.

The next step is HVM with paravirt_ops/VMI, which might actually show up some day for Xen (not there yet). Guests would still run in an HVM jail but are aware of the hypervisor and don't need to interact with the QEMU provided virtual hardware (think PV drivers).

Also, kvm has paravirt_ops now, as of a couple of days ago (thanks to Ingo). With l-hype and kvm, xen is quickly becoming moot anyway.

How does this affect grub and other bootstrapping? We very well might be talking about paravirt_ops/VMI and/or PV drivers at some point in addition to vanilla int13 real mode devices (though the virtual BIOSes will likely take care of this anyway).

- Ian C. Blenke <address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]