more on current pull

more on current pull

[ron minnich]

xm is really nice, I have to say. Easy to use and debug

I am occasionally seeing my network just go away. For example, I did this:
xend start
xm create vmid=1
telnet 127.1 9601
   (wait a while, admire output stuff, see that it fails to nfsroot since 
   I didn't set one up) 
xm destroy 1
   (dom 1 goes away)
at that point, I've got no eth0. 

Should I be using some other eth for the dom0->domN networking?  Is there
something else I'm doing wrong?

thanks

ron
p.s. are you using your own s-expression library for parsing or ... I'm 
curious because all our cluster tools here use s-expressions for internal 
comms.



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: more on current pull

[Ian Pratt]

> 
> xm is really nice, I have to say. Easy to use and debug
> 
> I am occasionally seeing my network just go away. For example, I did this:
> xend start
> xm create vmid=1
> telnet 127.1 9601
>    (wait a while, admire output stuff, see that it fails to nfsroot since 
>    I didn't set one up) 
> xm destroy 1
>    (dom 1 goes away)
> at that point, I've got no eth0. 
> 
> Should I be using some other eth for the dom0->domN networking?  Is there
> something else I'm doing wrong?

When you run "xend start", you should see a bridge device being
created (xen-br0), and the IP address and routes that previously
were set up for eth0 being transferred to xen-br0. Doing the
transfer is necessary because of an oddity in the Linux bridge
code.

Killing a domain certainly shouldn't cause you to loose
networking in dom0. "/etc/xen/vif-bridge down" doesn't do very
much, so I'm surprised its causing you problems.

You might want to try commenting out all the iptables lines below
the 'brctl' line.

> p.s. are you using your own s-expression library for parsing or ... I'm 
> curious because all our cluster tools here use s-expressions for internal 
> comms.

Mike Wray's the s-expression champion. I believe he rolled his own.

Ian




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: more on current pull

[Mike Wray]

ron minnich wrote:

> xm is really nice, I have to say. Easy to use and debug
> 
> I am occasionally seeing my network just go away. For example, I did this:
> xend start
> xm create vmid=1
> telnet 127.1 9601
>    (wait a while, admire output stuff, see that it fails to nfsroot since 
>    I didn't set one up) 
> xm destroy 1
>    (dom 1 goes away)
> at that point, I've got no eth0. 
> 
> Should I be using some other eth for the dom0->domN networking?  Is there
> something else I'm doing wrong?
> 
> thanks
> 
> ron
> p.s. are you using your own s-expression library for parsing or ... I'm 
> curious because all our cluster tools here use s-expressions for internal 
> comms.
> 

We're using our own stuff. I wrote s-exp parsers for Python and C that work
with input fed to them in chunks, because we're using asynch i/o.
There's also a Python prettyprinter.

Good to hear someone else uses s-exps.

Mike


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

RE: more on current pull

[James Harper]

> When you run "xend start", you should see a bridge device being
> created (xen-br0), and the IP address and routes that previously
> were set up for eth0 being transferred to xen-br0. Doing the
> transfer is necessary because of an oddity in the Linux bridge
> code.

How can I stop this behaviour? I set up my own bridges in
/etc/network/interfaces eg:

auto br0
iface br0 inet static
  address 192.168.200.210
  netmask 255.255.255.0
  gateway 192.168.200.203
  bridge_ports eth0
  up sleep 10 && ifconfig eth0 promisc

(that last line is because of a bug in the tlan network driver re:
promisc mode - I've sent a patch to the lkml but it's so far just been
ignored).

And i'd much rather xend not create the bridge for me. Imho, it is not
xend's place to create the bridge, just to add vif's to bridges, and it
would muck up firewall rules that rely on interface specifications if on
boot the interface is eth0 then later on xen-br0.

Other things that might break on changing interfaces midstream are:
DHCP
samba
static routes

I understand that xend doing this means that it 'just works' for anyone
trying out xen with a reasonably standard config, but it's just a pain
for me.

Any ideas?

thanks

James



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com

Re: more on current pull

[Ian Pratt]

> > When you run "xend start", you should see a bridge device being
> > created (xen-br0), and the IP address and routes that previously
> > were set up for eth0 being transferred to xen-br0. Doing the
> > transfer is necessary because of an oddity in the Linux bridge
> > code.
> 
> How can I stop this behaviour? I set up my own bridges in
> /etc/network/interfaces eg:
>
> And i'd much rather xend not create the bridge for me. Imho, it is not
> xend's place to create the bridge, just to add vif's to bridges, and it
> would muck up firewall rules that rely on interface specifications if on
> boot the interface is eth0 then later on xen-br0.

Yep, if you've got a complicated setup you certainly don't want
xend messing with it.

If you've already got everything setup how you want before xend
starts, then just edit /etc/xen/xend-config.sxp to set:
 (network-script /bin/true)  

Thus, it won't execute /etc/xen/network at all.

You might find some of the stuff in /etc/xen/network useful, in
which case rename it and edit it to suit.

/etc/xen/network is just there to help out the majority of people
who have one physical interface and a single bridge and want
things working straight out of the box.

Best,
Ian






-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: more on current pull

[Mark Williamson]

Take a look at /etc/xen/{vifctl,vif-bridge,network} - comments in them 
describe what they do.

Also take a look in /etc/xen/xend-config.sxp (also commented).  You could 
write some new scripts, based on the old ones and point xend-config.sxp to 
them.  This will allow you to get xend to add vifs to your custom bridges.

The move to shell scripts for this is a fairly recent addition to make it 
easier to accomodate advanced setups.

Cheers,
Mark



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

RE: more on current pull

[James Harper]

> If you've already got everything setup how you want before xend
> starts, then just edit /etc/xen/xend-config.sxp to set:
>  (network-script /bin/true)

Perfect. Thanks.

James


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com