[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] multiple vif's/bridges
Hi Andrew! andrew mathes wrote: > i'm confused what the "mac" paramater on vif's in the startup > configuration file for a domain does. > > i have this in my configuration file: > vif = [ 'mac=aa:00:00:1a:%d:11' % (vmid), 'bridge=xen-br0'] > vif = [ 'mac=aa:00:00:1a:%d:12' % (vmid), 'bridge=xen-br1'] > > and while my REAL question is why this doesn't bind the second vif to > bridge1, The first time I used xen, I thought all this would happen automagically. Butwhen I figured out (like you) that this is not true, so I started to configure everything outside of xen's startup scripts in advance of creating domains: 1. Create all the bridge devices that are mentioned in xenU configuration files; since xen-br0 is already there, in your case only xen-br1 has to be created: brctl addbr xen-br1 brctl stp xen-br1 off brctl setfd xen-br1 0 ip link set xen-br1 up I disable spanning tree since normally it causes more problems than it solves and it unnecessarily delays the initial forwarding. When the domUs boot, their eth0, eth1 etc. are added to the bridges as specified by your xen config file and get the MAC addresses as specified there with the mac=... parameter. 2. If you want to do networking between xen0 and xenU, configure the bridge device with an IP address, i. e. ifconfig xen-br1 10.1.2.3 netmask 255.255.255.0 broadcast 10.2.3.255 the bridge xen-br1 has the MAC address fe:ff:ff:ff:ff:ff. This is ok and poses no problem, because this is a valid (local scope individual) MAC address. 3. If you want to do external networking, you have to add one of dom0's physical networking devices to the bridge, i. e. brctl addif xen-br1 eth1 The bridge will get the MAC address of the physical NIC eth1. And as above, dom0 communicates via xen-br1, not via eth1, so leave eth1 unconfigured. You can also use VLAN devices instead of physical NICs here, they are equivalent to physical NICs in this context (at least as long /proc/sys/net/bridge/bridge-nf-filter-vlan-tagged is 1). 4. Since VLAN devs carry their own MAC address (by default the same as their physical base device), you could add a VLAN to a bridge to change the bridges MAC address, i.e. if you would like to give xen-br1 the MAC address 00:00:01:02:03, you could use ip link set eth0 up vconfig add eth0 815 ip link set addr eth0.815 00:00:00:01:02:03 brctl addif xen-br1 eth0.815 Of course you could also change the MAC of a physical NIC instead of using a VLAN device but I prefer using VLANs. > my first concern is that what's happening is the second line's > MAC is being given to eth0 on my VM, and eth1 is getting something > fairly random looking. My xenU eth's MAC addresses are exactly what I specify in the configuration files. I have no idea where this random MAC stuff that you experience comes from. > is this mac the mac of the bridge being binded to, the mac of the new > vif in the domain? The MAC of xenU's eth0, eth1 etc. The MAC of vifX.Y in dom0 always shows fe:ff:ff:ff:ff. > And if it's the mac of the if in the domain, why > would these two lines not assign those two macs to eth0/1 respectively? That's what they do at least for me. Although I don't use %d etc., I don't think that this makes any difference (I use scripts to generate all xen configuration files, virtual disks, startup configs inside those virtual disks, the bridges etc.). > I'm sure someone out there has bound multiple ethernet cards to > different interfaces ... seems like a very common server setup, any > enlightenment from xen guru's out there? I'm not a guru, but maybe the above can help a bit. > mostly curious about the "vif" paramater in your domain startup > configuration as well as if you used the default "vif-bridge" script. Sorry, I'm doing everything outside the xen autoconfiguration magic, so no vif-bridge script. Mark. _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |