As promised on Friday here is the patch for the pypxeboot bootloader. It would be great if someone could try it out and give me some feedback. 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, At 11:13 +0000 on 05 Feb (1170673998), Stephen Childs wrote:> As promised on Friday here is the patch for the pypxeboot bootloader. It > would be great if someone could try it out and give me some feedback.First impressions: this looks really useful but has a few rough edges that need to be knocked off. (I haven''t had a chance to try this on a real machine yet.)> +for line in udhcplines: > + s = line.strip() > + f = s.split() > + > + if s[0]==''{'' and s[-1]==''}'': > + dhcpinfo=eval(s, {"__builtins__" : {}}) > + for k in dhcpinfo: > + dhcpinfo[k]=dhcpinfo[k].strip()Executing the results of programs scares me. Could you just parse it?> +ipaddr=dhcpinfo[''ip''] > +ipaddrlist=ipaddr.split(''.'') > +hexip=commands.getstatusoutput("/usr/bin/gethostip -x "+ipaddr)[1]This requires syslinux to be installed on the Xen host, and isn''t hard to do by hand: "%2.2x%2.2x%2.2x%2.2x" % tuple(map (int, ipaddrlist)) (I''m sure more heavyweight python hackers can correct my style.)> +tmpdir="/var/lib/xen/" > + > +os.chdir(tmpdir) > +commandstr="tftp -c get "+servaddr+":pxelinux.cfg/"+hexip > +#print "running command "+commandstr > +getpxeres=commands.getstatusoutput(commandstr)You''ll need to be more careful with temporary file names -- here at least the filename is unique to the guest (we hope!) but for the kernel etc., two boots could clash. Also, you don''t seem to remove the downloaded config files. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Feb 05, 2007 at 05:36:12PM +0000, Tim Deegan wrote:> Hi, > > At 11:13 +0000 on 05 Feb (1170673998), Stephen Childs wrote: > > As promised on Friday here is the patch for the pypxeboot bootloader. It > > would be great if someone could try it out and give me some feedback. > > First impressions: this looks really useful but has a few rough edges > that need to be knocked off. (I haven''t had a chance to try this on a > real machine yet.) > > > +for line in udhcplines: > > + s = line.strip() > > + f = s.split() > > + > > + if s[0]==''{'' and s[-1]==''}'': > > + dhcpinfo=eval(s, {"__builtins__" : {}}) > > + for k in dhcpinfo: > > + dhcpinfo[k]=dhcpinfo[k].strip() > > Executing the results of programs scares me. Could you just parse it? > > > +ipaddr=dhcpinfo[''ip''] > > +ipaddrlist=ipaddr.split(''.'') > > +hexip=commands.getstatusoutput("/usr/bin/gethostip -x "+ipaddr)[1] > > This requires syslinux to be installed on the Xen host, and isn''t > hard to do by hand: "%2.2x%2.2x%2.2x%2.2x" % tuple(map (int, ipaddrlist)) > (I''m sure more heavyweight python hackers can correct my style.)(4 * "%2.2x") % tuple(map (int, ipaddrlist)) or "".join(["%2.2x" % int(i) for i in ipaddrlist]) Both are pleasingly arcane... Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan wrote:> First impressions: this looks really useful but has a few rough edges > that need to be knocked off. (I haven''t had a chance to try this on a > real machine yet.)I absolutely agree, this was the first working version and I was aware there were nasties in it.>> +for line in udhcplines: >> + s = line.strip() >> + f = s.split() >> + >> + if s[0]==''{'' and s[-1]==''}'': >> + dhcpinfo=eval(s, {"__builtins__" : {}}) >> + for k in dhcpinfo: >> + dhcpinfo[k]=dhcpinfo[k].strip() > > Executing the results of programs scares me. Could you just parse it?Yes quite. Sorry that was cut-and-paste code so I didn''t think about it enough. Will rewrite.>> +ipaddr=dhcpinfo[''ip''] >> +ipaddrlist=ipaddr.split(''.'') >> +hexip=commands.getstatusoutput("/usr/bin/gethostip -x "+ipaddr)[1] > This requires syslinux to be installed on the Xen host, and isn''t > hard to do by hand: "%2.2x%2.2x%2.2x%2.2x" % tuple(map (int, ipaddrlist)) > (I''m sure more heavyweight python hackers can correct my style.)Yes of course I''ll change that.>> +tmpdir="/var/lib/xen/" >> + >> +os.chdir(tmpdir) >> +commandstr="tftp -c get "+servaddr+":pxelinux.cfg/"+hexip >> +#print "running command "+commandstr >> +getpxeres=commands.getstatusoutput(commandstr) > > You''ll need to be more careful with temporary file names -- here at > least the filename is unique to the guest (we hope!) but for the kernel > etc., two boots could clash. Also, you don''t seem to remove the > downloaded config files.Yes that all needs tidying up. Unfortunately the version of tftp I was using didn''t actually support "get <remote-file> <local-file>" as advertised which I was initially going to use. I''ll have to download to the filename supplied by the server then move to a tmpfile. On the subject of removing files yes of course I''ll remove the config files. Comparing with pygrub, that seems to leave kernels and initrds clogging up /var/lib/xen, and I suppose I''ll end up doing the same. I suppose you could set up tmpwatch to clean it up, but it still seems a bit messy. Expect a new patch soon ... 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Yes that all needs tidying up. Unfortunately the version of tftp I was > using didn''t actually support "get <remote-file> <local-file>" as > advertised which I was initially going to use. I''ll have to downloadto> the filename supplied by the server then move to a tmpfile.tftp-hpa as supplied with FC3 seems to work: "tftp tftp-serv -c get foo /tmp/bar" Incidentally, what do you do if the guest vif is not going to be on the same bridge that dom0 eth0 is on? In practice this likely matters more for the dhcp request than the tftp transfer. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, At 14:27 +0000 on 08 Feb (1170944860), Stephen Childs wrote:> Yes that all needs tidying up. Unfortunately the version of tftp I was > using didn''t actually support "get <remote-file> <local-file>" as > advertised which I was initially going to use.:(> I''ll have to download to > the filename supplied by the server then move to a tmpfile.How about a wrapper function that mkdirs a new randomly named directory, does the tftp in there, and then moves the file to the destination path and rmdirs the temp dir?> On the subject of removing files yes of course I''ll remove the config > files. Comparing with pygrub, that seems to leave kernels and initrds > clogging up /var/lib/xen, and I suppose I''ll end up doing the same. I > suppose you could set up tmpwatch to clean it up, but it still seems a bit > messy.The kernel and initrd files are actually deleted by Xend after it has used them to boot the domain. Somewhere way out on my todo/wish-list is plumbing the kernel/initrd through pipes and buffers, or open fds on unlinked files or some such...> Expect a new patch soon ...Great; thanks for that. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:> tftp-hpa as supplied with FC3 seems to work: "tftp tftp-serv -c get foo > /tmp/bar"Yes and tftp version 0.43 from http://www.kernel.org/pub/software/network/tftp/ works too. I was using a much older one before so everything should be OK as long as people use a recent version. I''ve put it in the README. I''ve attached a fresh patch that addresses this and the other issues you raised, Tim.> Incidentally, what do you do if the guest vif is not going to be on the > same bridge that dom0 eth0 is on? In practice this likely matters more > for the dhcp request than the tftp transfer.Could you explain what the problem would be? Do you mean that the DHCP server might not be set up to serve requests from the dom0''s subnet? To be honest I hadn''t thought that much about more complex setups -- as it is there are embedded assumptions about the way pxelinux is set up. 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Incidentally, what do you do if the guest vif is not going to be onthe> > same bridge that dom0 eth0 is on? In practice this likely mattersmore> > for the dhcp request than the tftp transfer. > > Could you explain what the problem would be? Do you mean that the DHCP > server might not be set up to serve requests from the dom0''s subnet?To be> honest I hadn''t thought that much about more complex setups -- as itis> there are embedded assumptions about the way pxelinux is set up.I think we should at least try and send the dhcp request out on the bridge that the guest''s first VIF is going to attach to -- it might be on an entirely different VLAN or even physical network from dom0. Possibly it will work just to set the bridge as the interface that the raw socket is bound to when sending the dhcp request. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 16:36 +0000 on 08 Feb (1170952573), Stephen Childs wrote:> I''ve attached a fresh patch that addresses this and the other issues you > raised, Tim.Thanks. That looks much better -- I think we should use mkstemp for the config files too, if possible. Is udhcp still actively maintained? I wonder if we can get the mac-address patch in upstream; otherwise we might have to bring the client source into our tree. The other option (and it may end up being necesary to address Ian''s point about physical NICs) would be to steal the guest''s vif for the dhcp''ing, since we know the guest won''t be using it yet. I haven''t looked in detail at the plumbing of that, though. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan wrote:> At 16:36 +0000 on 08 Feb (1170952573), Stephen Childs wrote: >> I''ve attached a fresh patch that addresses this and the other issues you >> raised, Tim. > > Thanks. That looks much better -- I think we should use mkstemp for the > config files too, if possible.OK I will try and have a look at that (or you''re welcome to!)> Is udhcp still actively maintained? I wonder if we can get the > mac-address patch in upstream; otherwise we might have to bring the > client source into our tree.I''ve had no response to a patch I submitted and the last release was in 2002 so maybe we will have to do that for now.> The other option (and it may end up being necesary to address Ian''s > point about physical NICs) would be to steal the guest''s vif for the > dhcp''ing, since we know the guest won''t be using it yet. I haven''t > looked in detail at the plumbing of that, though.That sounds like a better solution in the long-term. Hopefully the existing approach already provides enough functionality to be useful to people in the short-term though. 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 change. 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. Anyone up for making these modifications? I''d really like to see this patch in mainline Xen. Best, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel