llarava
asked on
ESXi 5.5 1331829 - Guest VMs Losing network connection random
We are running ESXi5.5 1331829 - single cluster 7 hosts and vCenter 5,5 build 1476327. Some guest VMs are Losing network connection randomly. Multiple OS's (Windows 2012 r2, Windows 2008 R2, Windows 2003) and different ESXi hosts (all running the same ESXi version). The connectivity comes back by either rebooting the guest VM or by enabling disabling the network card.
1.) At random VMs experience loss of network connectivity. The symptoms appear to be similar even though the versions are different. This is happening on ESXi 5.1 our production is running 5.5
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2072694
The second issue we have seen is a little different where we have the following issue:
2.) After a reboot of a Windows 2012 R2 the VMs are getting a 169.254.X IP address. This issue seems to be documented in the VMware KB.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2012646
Can anyone provide any advice?
1.) At random VMs experience loss of network connectivity. The symptoms appear to be similar even though the versions are different. This is happening on ESXi 5.1 our production is running 5.5
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2072694
The second issue we have seen is a little different where we have the following issue:
2.) After a reboot of a Windows 2012 R2 the VMs are getting a 169.254.X IP address. This issue seems to be documented in the VMware KB.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2012646
Can anyone provide any advice?
Do you have multiple vCenter servers, even if they are controlling different clusters?
The auto-generated MAC addresses of the vNICs can conflict, if you're running multiple vCenter servers and they have the same Unique ID.
Virtual machine MAC address conflicts or have a duplicate MAC Address when creating a virtual machine (1024025)
The auto-generated MAC addresses of the vNICs can conflict, if you're running multiple vCenter servers and they have the same Unique ID.
Virtual machine MAC address conflicts or have a duplicate MAC Address when creating a virtual machine (1024025)
ASKER
Andrew Hancock - I have the tools installed. So are the E1000 adapter not recommended for 2008R2 and 2012R2? Are there any KB's that describe the issue I am running into with E1000's. I am going to have to change interfaces all the servers which will require a lot of effort and I need to be sure this is the issue. (issue #1)
Have you run into issue # 2 and are you applying the suggested solution? to all the Windows 2012 R2 servers? Or simply using VMXNET3?
After a reboot of a Windows 2012 R2 the VMs are getting a 169.254.X IP address. This issue seems to be documented in the VMware KB.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2012646
Have you run into issue # 2 and are you applying the suggested solution? to all the Windows 2012 R2 servers? Or simply using VMXNET3?
After a reboot of a Windows 2012 R2 the VMs are getting a 169.254.X IP address. This issue seems to be documented in the VMware KB.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2012646
It's always been recommended to use the VMXNET interfaces from when VMware introduced them, many years ago.
The driver is virtualised, rather than the emulated legacy E1000 driver, which should only be used for installation.
We have never gone production with VMware VMs using any other driver than VMXNET3 (latest). It also runs at 10GBe.
The driver is virtualised, rather than the emulated legacy E1000 driver, which should only be used for installation.
We have never gone production with VMware VMs using any other driver than VMXNET3 (latest). It also runs at 10GBe.
Are you using static addresses, or DHCP?
169.254.x.x just means the client was unable to obtain a DHCP address. It could indicate network issues, an exhausted address space, a DHCP server that had not completed a reboot, or human intervention such as removing a static address.
169.254.x.x just means the client was unable to obtain a DHCP address. It could indicate network issues, an exhausted address space, a DHCP server that had not completed a reboot, or human intervention such as removing a static address.
I concur with the recommendation of VMXNET3 vNICs, by the way.
ASKER
That hasn't solved the issue. This is the issue that we are having. Have you run into this before? Any suggestions.
http://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html
http://ballblog.info/2014/12/22/disabling-ip-device-tracking-to-avoid-ip-conflicts/
https://social.technet.microsoft.com/Forums/windows/en-US/82e7b9a6-c58e-4b73-9fac-8e73f3347b91/0000-ip-address-conflicts-on-the-network-vms-lose-network-after-reboot?forum=winserverhyperv
http://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html
http://ballblog.info/2014/12/22/disabling-ip-device-tracking-to-avoid-ip-conflicts/
https://social.technet.microsoft.com/Forums/windows/en-US/82e7b9a6-c58e-4b73-9fac-8e73f3347b91/0000-ip-address-conflicts-on-the-network-vms-lose-network-after-reboot?forum=winserverhyperv
Get it escalated to VMware Support.
ASKER
This is NOT a VMware issue. But a Microsoft/Cisco one. There are no solutions available just workarounds and I just wanted to know if someone ran into this before and what was the option that they decided to go with.
We've not seen this issue before, VMware Support if you have support, will be able to check the logs, and give you a direction, as to where to look.
Do you not have a VMware Support contract ?
If this is truly a combined Microsoft/Cisco issue, you will have to change switch fabric or firmwares.
Do you not have a VMware Support contract ?
If this is truly a combined Microsoft/Cisco issue, you will have to change switch fabric or firmwares.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Can you provide the model and software version of the switch?
ASKER
It's the solution from Cisco TAC
Not the E1000 legacy interface.
Make sure VMware Tools is installed to support this network interface.
Is this true ?