This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [PATCH] pypxeboot bootloader

To: "Daniel Miles" <daniel.t.miles@xxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] pypxeboot bootloader
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
Date: Mon, 7 May 2007 18:21:21 +0100
Delivery-date: Mon, 07 May 2007 10:20:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <45C7114E.10207@xxxxxxxxx><8A87A9A84C201449A0C56B728ACF491E04F4CA@xxxxxxxxxxxxxxxxxxxxxxxxxxx><45CB517D.2010809@xxxxxxxxx> <200705071033.21901.daniel.t.miles@xxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceQxcb9GtrXXQUkQEOpFiWuQPgIRQABLTlQ
Thread-topic: [Xen-devel] [PATCH] pypxeboot bootloader
> First off, thanks for all the work, Stephen. This is a useful feature.
> I'm trying to test it, without much success. I've followed the
> instructions on
> https://www.cs.tcd.ie/Stephen.Childs/pypxeboot/ but when I xm create
> the
> machine, it just hangs on: Using config file "/etc/xen/testU1.cfg".
> I don't even get any output if I put in frivolous print statements in
> pypxeboot before anything else happens.
> How does xm actually invoke bootloaders? What might be happening here?

Not sure why its not working, but it would be good to get this patch
dusted off and made a bit more general.

The biggest problem with it is that it assumes that dom0's eth0
interface is on the same bridged network as where the guest's virtual
NIC will end up. This often won't be the case.

We could fix this quite easily, using the '-i' option to udhcp to point
to the backend vif. 

NB: Stephen: at one point does pypxeboot run? After the vifX.Y is
created and put on the right bridge? If so, this should be a trivial

The other problem is that we then use dom0's default IP address to do
the tftp. Again, this would best be done using the guest's IP. The best
way of fixing this is probably to assign the backend vif with the
guest's IP returned from udhcp (i.e. actually allow udhcp to configure
an address on the vifX.Y interface). We can the get tftp to bind the
outgoing socket it creates to that local address when doing the
transfer. After completing, we should be sure to set the vif's IP
address back to

Anyone up for making these modifications? I'd really like to see this
patch in mainline Xen.



Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>