On Tue, Apr 3, 2012 at 5:37 PM, Chris Webb <ch...@arachsys.com> wrote: > Stefan Hajnoczi <stefa...@gmail.com> writes: > > >> >> Are you sure no other guest has the same MAC address or IP address? >> >> This weird behavior sounds similar to what happens when you have >> >> multiple devices on a network using the same address - the results are >> >> very confusing :). >> > >> > Yes, I agree! However, in this case there's no other guest with the same >> > MAC >> > or IP address on the network. I've explicitly rechecked this to be sure, >> > and >> > also deliberately varied the MAC address to something I know can't be >> > generated by our scripts. In any case, I'm using the same MAC and IP >> > address >> > for every reboot of this VM, and usually (19 times out of 20) it works >> > fine. >> >> The lack of ARP reply is a host networking problem. Have you checked >> host dmesg(1) output just in case there was a kernel message related >> to this? > > Nothing there I'm afraid. Just the usual > > device tap1 entered promiscuous mode > ADDRCONF(NETDEV_UP): tap1: link is not ready > ADDRCONF(NETDEV_CHANGE): tap1: link becomes ready > br0: port 2(tap1) entering forwarding state > br0: port 2(tap1) entering forwarding state > kvm: 20288: cpu0 unhandled rdmsr: 0xc0010112 > kvm: 20288: cpu0 unhandled rdmsr: 0xc0010048 > tap1: no IPv6 routers present > br0: port 2(tap1) entering forwarding state > br0: port 2(tap1) entering forwarding state > br0: port 2(tap1) entering forwarding state > br0: port 2(tap1) entering forwarding state > br0: port 2(tap1) entering disabled state > > cycle. It looks just the same for a working guest as for a non-working > guest.
Is the "disabled state" because QEMU exited? I'm afraid I don't have any suggestions beyond debugging the bridge->tap code in the kernel since packets are not being forwarded for some reason. Stefan
