Client machine sends but does not receive any packets. When tcpcap monitors eth0, it is evident that the host machine is receiving packets from the client machine, but does not respond. All rules in iptables have been removed and/or set to ALLOW ALL (manually for debugging purposes), and thus should not interfere. In addition, precautions were taken to eliminate any sort of interference from software firewalls, and iptables was disabled on the xen kernel level. The MAC address of the host machine seems to be mirrored on the client machine as well. The IP address however, may not be set properly; and it is speculated that it is not 'trickling' across the bridges and virtual interfaces properly. This has been an issue in the past with particular builds, and may have presented itself again. Our only current solution was to roll back to app-emulation/xen-3.1.2 Reproducible: Always Steps to Reproduce: 1. Install and configure a working version of app-emulation/xen-3.1.2 2. Unmask/Allow the installation of app-emulation/xen-3.2.0 and app-emulation/xen-tools-3.2.0 3. Emerge the latest build 4. Restart the machine and attempt to run create a new virtual machine from a working configuration file 5. Attempt to ping global addresses from within the virual machine 6. Run tcpcap on eth0 or other primary interface 7. Attempt to ping the host machine from within the virtual machine Actual Results: The virual machine cannot access any external IP's, and does not receive pings from local IP's (such as the host machine). Tcpcap shows that eth0 or other primary adapter is receiving pings from the virtual machine, but does not successfully send a response. Expected Results: There should be no difficulty in migrating from app-emulation/xen-3.1.2 to app-emulation/xen-3.2.0. All bridging functionality has been broken with the default configurations. The only known solution at this point is to unmerge app-emulation/xen-3.2.0 and app-emulation/xen-tools-3.1.2 and then re-install the 3.1.2 counterparts.
I saw the same problem.
Could it because xen-3.2.0 starts to use eth0 instead of xenbr0 as bridging interface?
What do you suppose would be an appropriate solution then? I've noticed that when running 'route' on a machine with xm started, all eth0 devices appear as xenbr0. Having read through several papers regarding similar problems with previous releases, I came across what may be a proper explanation: the physical interface device is supposed to be configured as a slave to the bridge. With this in mind, what sort of conventions are coming into play if eth0 is now by default treated as the primary interface device? This is the link that suggested the above-mentioned relationship between the physical device (eth0 in this case) and the bridge xenbr0: http://etbe.coker.com.au/2007/07/24/xen-and-bridging/
I had a similar issue. It really seams that in xen 3.2 the bridge in the dom0 is now eth0 and not xenbr0. so i had to change to things: 1. the iptables referenced to xenbr0 and i had to change it to eth0 2. the domU-config-file i had the line: vif = [ 'mac=0A:23:45:AB:CD:02, bridge=xenbr0' ] also change xenbr0 to eth0 and networking now works for me. btw: anyone noticed problems with the domU consoles with the latest 2.6.18-r9 xen-kernel, i had to add console=hvc to the boot options and change the inittab file to get a working console with the domUs?
(In reply to comment #4) > I had a similar issue. It really seams that in xen 3.2 the bridge in the dom0 > is now eth0 and not xenbr0. > > so i had to change to things: > 1. the iptables referenced to xenbr0 and i had to change it to eth0 > 2. the domU-config-file i had the line: > vif = [ 'mac=0A:23:45:AB:CD:02, bridge=xenbr0' ] > also change xenbr0 to eth0 > and networking now works for me. I can confirm this is indeed the change made to 3.2.0. I remember I read some posts to xen dev list. The reply was bridge interface changed from xenbr to eth. Also Fedora Core 7 or 8 has already made the switch.
Xen 4.1 in tree. Please test with it and reopen if it doesnt work
