Re: PV-Grub and PXE

Re: PV-Grub and PXE

[Samuel Thibault]

(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

Re: PV-Grub and PXE

[Steven Maresca]

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

Re: PV-Grub and PXE

[Samuel Thibault]

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 choice

Yes, 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