[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Xen 3.0.3 and VLAN



On Sun, 2006-11-05 at 21:21 +0100, Bruno.Voigt@ic3s.de wrote:
> Hi Tim,
> 
> the missing comma after the bridge specification in the vif declaration of 
> the domU cfg's
> seemed to have caused the problems I encountered.
> 

Excellent.

> Now I'm using the xen network-dummy script
> and have succesfully in dom0 put up 3 bridges belonging to different 
> VLAN's
> and can assign these bridges to some domU's
> so that their eth0 belongs to that specific VLAN.
> 
> So I reached the goal I wanted. Thanks again!
> 

Glad you got it working :)

> But I wonder if there is a way to enhance it.
> Now dom0 uses xenbr94 directly as it's standard interface to the world.
> 

You'll need to toss in another nic (just for dom-0) and use it as a
regular eth device.

> The default xen network-bridge magic does it somehow different:
> it renames eth0 to peth0 and creates a new eth0 which is then added to the 
> xenbr0
> - which is then used by dom0 for communication instead of using a xenbr 
> directly.
> 
> I could not figure out yet how to create such a new interface (using 
> somehow the netloop driver?)
> and have the dom0 use that instead. Googling for netloop etc brought no 
> enlightment..
> Do you know how to do that / by what commands? How is xen creating the 
> similar vifX.Y interfaces ?
> 

Probably a question best sent to the xen lists,
http://lists.xensource.com .. kind of offtopic for the debian lists. 

If you look at the vif-bridge script, you'll see how the 'magic' is
happening , its just like adding helpers like you would (typically
pre-up.d style)

> Perhaps you can help me with that..
> 
> BTW: I'm also using the ocfs2 filesystem with two nodes and playing around 
> with live migration.
> Is there a way to speed up to make the cisco switches in our network learn 
> faster that a domU IP is now reachable
> on another node's mac ? Either via configuration on the switches or in the 
> nodes bridge configuration?
> 

Really depends on your routing. If you are specifying a mac for each
bridge (which I don't think you are) it should be a non issue. The
default bridge mac is ff:ff:ff:ff:ff:ff , so that's why you're hitting
the ~9 minute lag at the cisco to re-arp the new IP to the right bridge.

Since all bridges are the same at the mac layer, every IP change is as
if the ip is being broadcast from a new mac, even though it isn't. This
is also going to cause AoE to bleed through all of the bridges
regardless of what eth device you specified to vblade...  another
undesirable side effect depending on how well you know those who own
root on the guests.

Reagrdless of the mac the dom-u is broadcasting, if all bridges have the
same mac, its going to be a problem.

Once you have unique macs for each bridge, the problem should go away. I
use ocfs2 / aoe as well for the same purpose, and ran into the same
exact issue. 

> WR,
> Bruno
> 

Glad to see you up and running with Xen :) Shoot the question over to
the xen lists, if you can't get what you need from just looking at the
stuff in /etc/xen/scripts

Best,
-Tim




Reply to: