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

[Xen-devel] Re: PV-Grub and PXE


  • To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Steven Maresca <steve.maresca@xxxxxxxxx>
  • From: Steven Maresca <steve.maresca@xxxxxxxxx>
  • Date: Wed, 15 Jul 2009 21:52:40 -0400
  • Cc:
  • Delivery-date: Wed, 15 Jul 2009 18:53:10 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=wa1sbsjLSsolhugolNKUaDA87qUWoXgjwP09nLDenu27CQfIbGRN96JmAKcsznqwjP TuwjCp4husk1sRJV3YP/Gr2ZSxzJo/gbWJ7AmdPFhb8z4hHhoFBtMSuYGi/YKMRPgnV+ 4h59CV6WTqb1v9hwys3lOS8Psg/MX9Xtg/New=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Samuel,

On Wed, Jul 15, 2009 at 6:33 PM, Samuel
Thibault<samuel.thibault@xxxxxxxxxxxx> 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@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®.