(Sending to xen-devel as it may find volunteers) Steven Maresca, le Wed 15 Jul 2009 14:33:45 -0400, a écrit :> While I would be satisfied with a grub menu.lst pulled via tftp, many > many others would rather rely upon established mechanisms [PXE].Well, that means two things: - using the existing PXE payloads. As I said in my previous private mails, that''d need a PV-bios stubdom for the software interrupt requests from the PXE payload, but now I think about it again, a PXE loader would also have to know how to load a PV kernel. This is quite a blocker actually. Unless porting all the existing PXE payloads, one won''t be able to have them boot PV kernels. Only pv-grub knows at the moment, so it''d be a bit odd to implement a PV-bios stubdom just to load a PXE PV-grub, while we could directly start a PV-grub :) FV kernels is not a problem of course, just boot a FV Xen domain with net boot :) - using the existing PXE configurations. There are several kinds of them, quite often pxelinux config, which is like syslinux config. It may be not be so hard, we''d just need to add e.g. a syslinux parser in pv-grub. Or port syslinux to PV. That''d mean using just the configuration part of the existing PXE infrastructures, not its binary payload. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Samuel, On Wed, Jul 15, 2009 at 6:33 PM, Samuel Thibault<samuel.thibault@ens-lyon.org> wrote:> (Sending to xen-devel as it may find volunteers) > > Steven Maresca, le Wed 15 Jul 2009 14:33:45 -0400, a écrit : >> While I would be satisfied with a grub menu.lst pulled via tftp, many >> many others would rather rely upon established mechanisms [PXE]. > > Well, that means two things: > > - using the existing PXE payloads. As I said in my previous private > mails, that''d need a PV-bios stubdom for the software interrupt requests > from the PXE payload, but now I think about it again, a PXE loader would > also have to know how to load a PV kernel. This is quite a blocker > actually. Unless porting all the existing PXE payloads, one won''t be > able to have them boot PV kernels. Only pv-grub knows at the moment, > so it''d be a bit odd to implement a PV-bios stubdom just to load a PXE > PV-grub, while we could directly start a PV-grub :) FV kernels is not a > problem of course, just boot a FV Xen domain with net boot :) > > - using the existing PXE configurations. There are several kinds of > them, quite often pxelinux config, which is like syslinux config. > It may be not be so hard, we''d just need to add e.g. a syslinux > parser in pv-grub. Or port syslinux to PV. That''d mean using just the > configuration part of the existing PXE infrastructures, not its binary > payload. > > Samuel >As you say, in the PV case we certainly cannot utilize native pxe loaders. For full virt: boot=''n'' in the domU config and qemu''s embedded ROM does all of the heavy lifting. Older versions of qemu lacking that ability can certainly boot a gPXE/Etherboot image and move along happily. For PV, we can cheat and skip most of that pain. In my mind - and as you suggested - that means just parsing PXE configurations. For the most basic case, all we need is: 1) access to the network device 2) ability to pull a lease from dhcp (with next-server and filename options set) 3) tftp to $next-server to grab not the pxelinux.0 binary (or its equivalent) but the configuration alone 4) mechanism for presenting the configuration and emulating the (text) menu 5) acting upon the choice Assumption: no more graphical menu is employed. Please note: I''m not necessarily advocating that pv-grub should be bent and twisted to this task, though that was the topic that led us to this discussion. -s _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Steven Maresca, le Wed 15 Jul 2009 21:52:40 -0400, a écrit :> For PV, we can cheat and skip most of that pain. In my mind - and as > you suggested - that means just parsing PXE configurations. > > For the most basic case, all we need is: > 1) access to the network device > 2) ability to pull a lease from dhcp (with next-server and filename options set) > 3) tftp to $next-server to grab not the pxelinux.0 binary (or its > equivalent) but the configuration alone > 4) mechanism for presenting the configuration and emulating the (text) menu > 5) acting upon the choiceYes, that''s the kind of things I was thinking about.> Assumption: no more graphical menu is employed.Not necessarily, grub''s graphical menu is just a graphical rendering of the text menu, it''s basically the same content.> Please note: I''m not necessarily advocating that pv-grub should be > bent and twisted to this task, though that was the topic that led us > to this discussion.I think it could still be done that way: there could be a pxelinux.cfg to menu.lst converter and pv-grub can be fed with it. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel