From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Childs Subject: RE: [PATCH] pypxeboot bootloader Date: Thu, 31 May 2007 11:10:33 +0100 Message-ID: <465E9F19.2050606@cs.tcd.ie> References: Reply-To: Stephen.Childs@cs.tcd.ie Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: daniel.t.miles@hp.com List-Id: xen-devel@lists.xenproject.org > From: "Ian Pratt" > Subject: RE: [Xen-devel] [PATCH] pypxeboot bootloader > To: "Daniel Miles" , >> 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? Does pygrub work? This will show you whether the problem is in the generic bootloader set up. If you get as far as executing pypxeboot, tcpdump should help you work out what's going on. > Not sure why its not working, but it would be good to get this patch > dusted off and made a bit more general. Sorry, I haven't looked at it in a while due to other distractions. I haven't tested it with the latest release, so I can't comment on this breakage. I'm having another look at it now, but some help from people who understand the domain startup plumbing would speed the process up considerably. > 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 > change. Yes, it would have been nice if it was that easy. However, it looks like the bootloader is called earlier than that (at least an ifconfig run from within the bootloader shows that nothing has been done at that stage). What is the sequence of events? Is it documented anywhere? (If not, it might be good to stick it on the wiki.) Any suggestions > 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 0.0.0.0. Yes this should all be manageable if we can sort out the sequencing of network/bootloader setup. > Anyone up for making these modifications? I'd really like to see this > patch in mainline Xen. If some domain startup gurus can point me in the right direction I will try and make these fixes. However, I don't have the spare time to do the digging around myself unfortunately. Stephen -- Dr. Stephen Childs, Research Fellow, EGEE Project, phone: +353-1-8961797 Computer Architecture Group, email: Stephen.Childs @ cs.tcd.ie Trinity College Dublin, Ireland web: http://www.cs.tcd.ie/Stephen.Childs