WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] question about PXE

To: Tim Freeman <tfreeman@xxxxxxxxxxx>
Subject: Re: [Xen-devel] question about PXE
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Sat, 25 Sep 2004 09:47:25 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Sat, 25 Sep 2004 09:52:19 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Fri, 24 Sep 2004 21:59:01 CDT." <20040924215901.2c676d53@prana-bindu>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
 
> > It creates a bridge and then attempts to transfer the original
> > network setup over to the bridge. Positing the output of
> > "ip link show" and "ip route show" before and after should help
> > figure out what's going wrong.
> 
> Adding bash -x didn't produce any output but having the console back let
> me see the problem: NFS was hanging, problem solved.  Sorry, I should
> have connected the dots, there was a message before about this...

Adding '-x' should have generated more log output to
/var/log/xend

It's rather unfortunate that we need to move all the addresses
and routes to the bridge. We should probably try convincing the
linux bridge maintainers that the current behaviour isn't helpful.

> They are.  As an experiment, I wiped the /lib/modules/2.4.27-xen0
> directory and redid 'make world' and 'make install' (after I recompiled
> to fix the serial IRQ 4 issue) and still the same error.  Before I did
> not include this message from the kernel ring buffer: 
> 
> "Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
> tun: Can't register misc device 200"
> (/dev/net/tun created by "mknod /dev/net/tun c 10 200")

Damn. Guess what we major/minor got picked for the Xen's evtchn
driver: 10,200 :-(   

Moving this shouldn't be too bad, as it's only xend that talks to
evtchn, so we could modify xend to re-mknod our evtchn device. 

The question is, what major,minor would be best to go for? Pretty
much all the numbers in the misc range have already gone.
At the very least, stealing something like the atarimouse would
have been smarter than tun.

> The objective is to start VMs on remote grid nodes and L2 bridge all of
> their network traffic to another network.  There, they are used as a
> backend for a grid node, i.e., a completely portable and custom
> environment to run jobs in.

When it's ready for release, you might find that Mike Wray's vnet
driver is actually a more convenient way of doing this.

> The VMs themselves have no hand in the bridging (by design).  I make a
> tap interface on the host resource for each VM and bridge the VM
> directly to each tap interface (this tap interface is one end of the L2

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel