[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Deficiencies in guest bootloader design
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. There was a long thread discussing bootloaders recently -- you should dig it out of the archive and see what the conclusions were -- there seem to be a few competing ideas for bootloader support in Xen (pygrub and domUloader being the two prominent ones). If you were going to put some effort into this, it would be appreciated by a number of the Xen users, certainly. > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |