| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Deficiencies in guest bootloader design
Ewan Mellor wrote:
On Thu, Apr 13, 2006 at 04:29:23PM +0200, Michael Paesold wrote:
I have tried to use a dynamically activated block device with pygrub
(actually drbd, but could be enbd, nbd, or simply any vbd other than phy:
or file:). That does not work.
The problem is that the bootloader is not called from Xend, after virtual
block devices are setup, but instead it is called directly from xm, i.e. in
xm/create.py.
If I have looked correctly, (1) a bootloader cannot be used for devices
such as nbd: or enbd: devices, and (2) a bootloader cannot be used when
accessing Xend via XML-RPC (or libvirt or similar), because the whole
notion of a "bootloader" at domain creation time is only available in "xm",
but not in Xend.
It should be fixable, since at least on guest *restart*,
xend/XendDomainInfo.py already uses the bootloader to re-extract the kernel
image from the vbd.
Is there anyone working on bootloader improvements? If not, is a change to
move the bootloader stuff from xm to Xend acceptable? In that case I could
try to come up with a patch.
Certainly such a patch would be accepted.
Just as a warning, it's not going to be simple to run something like
pygrub from Xend. The reason it runs from xm now is that it needs to
interact with the user. If it were launched from Xend, it need to find
a way to attach to a PTY that xenconsoled would use so that it can
display the text over the normal console before actually launching the
domain.
It's certainly not impossible but it touches quite a few things.
Regards,
Anthony Liguori
There are some issues though. In XendDomainInfo.initDomain, image.create is
done before self.createDevices. Can this be changed easily?
Off the top of my head, I can't think why this would be too much of a problem.
Why do you ask though? If the bootloader is running inside the guest, then
that is happening after both of those things, because at the point at which we
are doing initDomain, the guest hasn't even started running yet. Why does
ordering here concern you?
Don't forget that VMX domains handle their devices differently to para-virt
domains, and the VMX folks won't appreciate it if you break their code ;-)
Cheers,
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home