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

Re: [Xen-devel] Deficiencies in guest bootloader design



Ewan Mellor wrote:

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.

I already read Anthony's reply -- so I see some obstacles now :-)

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.

I am going to do that now.

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?

Well, with pygrub at least, the bootloader is not really executed in the guest, but in dom0. It extracts kernel and initrd into temporary files which are than booted as if they were directly specified in the guest config. So to extract the kernel, we would have to first setup the vbds.

I am going to check the archives now.

Best Regards,
Michael Paesold


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.