Stefan Hajnoczi <[email protected]> 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. Best wishes, Chris.
