qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Intermittent e1000 failure on qemu-kvm 1.0


From: Chris Webb
Subject: Re: [Qemu-devel] Intermittent e1000 failure on qemu-kvm 1.0
Date: Tue, 3 Apr 2012 17:37:59 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Stefan Hajnoczi <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]