@pschaff: hmm... My first message may not reflect it, but I've been on this problem for 3 months now (not had time to focus on it full time however) and did not post anything. When in the end I had no other choice, I posted my message and explained all the manipulations I did and ideas I tried (or at least, the ones I remembered). The point of my message was to call for new ideas. When I saw my post was far away in the pages with no replies, I felt a bump would let other people read it and maybe propose ideas. I'm not really the kind of person who waits for solution to fall from above on their own... I know this is your job to make people read and respect the rules, but that one was a bit harsh.
Sorry, I didn't see this one until now.
What works for me is to leave everything as default and edit /etc/xen/xend-config.sxp and find the line about network-script and change it to
- Code: Select all
That invokes the xen provided network script that handles bonding and just worked for me. I didn't have to make any other changes at all so I would back out anything else that you already tried.
Yeah, this is what I meant when I said "If I do use the scripts". I should have been clearer.
In fact, I pretty much tried all the scripts except the NAT ones. With no success.
But I have a great news. I finally got it working, by hand. Will check how to make it work correctly with the scripts now.
Here is what I did. First, I was in a mixed setup, as I said before, receiving packets to dom0 through the bridge: awful and disgusting.
My 3 NICs were bonded together into pbond0. I may not have mention it before, but there are 2 different types of NICs: 2 Intel 82576 10/100/1000 and 1 Intel 82574L 10/100/1000.
1. Turned off the bridge (bond0 in my case), the vifs, the veths and pbond0 but not the ethX
2. Deleted all my VLANs.
3. Set the MAC address of veth0 with the "real" MAC address of one of the ethX (bonding causes the 3 NICs enslaved to use the same MAC address).
4. Deleted the bridge.
5. Recreated the bridge (named bond0 hereafter).
6. Set the MAC address of pbond0, the bridge and vif0.0 to FE:FF:FF:FF:FF:FF.
This also sets the MAC address of the ethX.
7. Added pbond0 (the bond) and vif0.0 to the bridge (bond0).
8. Set my desired IP addresses on veth0.
9. Turned on the bridge (bond0), pbond0 (the bond), vif0.0 and veth0.
10. Added my VLANs to veth0.
Then, as I'm doing firewalling, I flushed my iptables rules and modified according to my new configuration. In particular, I allowed all traffic through the bridge using physdev. here is what you have to do (taken from the Xen networking Wiki):
- Code: Select all
iptables -t filter -A INPUT -m physdev --physdev-is-in -j ACCEPT
iptables -t filter -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
iptables -t filter -A OUTPUT -m physdev --physdev-is-out -j ACCEPT
Finally, I updated some config files and restarted the needing services (dhcpd, samba, named etc...).
Then, with (vif-script vif-bridge), any new virtual machine created is correctly added to the bridge and works flawlessly.
I guess the problem came from incorrect MAC addresses. More preciseley, I think the FE:FF... address was not correctly forwarded to the ethX interfaces. But that's just my opinion.
Hope this will be handful for some people.