TCP/IP Stack Corruption on VMware Host.

I encountered an issue this week where multiple VMs on a certain ESX host start having corruption of their TCP/IP stack. The 2008 VMs were unable to retain their gateway while the 2003 VMs were unable to retain any IP info whatsoever.  While still researching the cause, there is a solution. To repair the TCP/IP stack, just run this command which comes from this KB from Microsoft.

http://support.microsoft.com/kb/299357

netsh int ip reset c:\resetlog.txt

Here is a VMware Communities post with similar symptoms.

http://communities.vmware.com/message/1336502#1336502

This thread discusses the problem as well but doesn't really mention VMware.

http://social.technet.microsoft.com/Forums/en-US/itprovistasp/thread/27fd86ad-caad-4698-9032-63550695ee3d

Some Thoughts on the New FLARE 29

I recently implemented a new CX4 with the latest version of Navisphere, FLARE 29.  There's been a lot of hype around this release because 29 now gives storage admins the ability to peer into VMware environments and even see which guest VMs exist on which LUNs. ESX hosts icons appear differently and are easy to decipher form other hosts. I really like the integration and setup was straight forward.  Just a quick wizard to run through that requires authentication to your virtual center server and your good to go.  I've only tested the new FLARE in with vsphere so I'm not sure if the interface would give similar results and visibility into a VI3.5 environment. 

Another change in FLARE 29 that appears simple at first but, in my opinion, is quite a great enhancement is an upgrade to the "connectivity status" section of Navisphere.  Host wwn's and iqn's are now grouped together in a tree structure under the hostname.  No more sorting and trying to figure out if all your initiators registered successfully or not!  What a time save if you're implementing several new hosts in an environment. 

CAUTION:  It does appear that there is a bug with FLARE 29 and Site Recovery Manager. If using SRM with MirrorView, hold off until the next version of SRM is released and do the SRM upgrade first.  Hopefully, this will also be the time a vSphere compatible version of SRM is released as well.  For more information about this issue, check out the end of this fine article from Chad Sakac.

http://virtualgeek.typepad.com/virtual_geek/2009/09/a-couple-important-alua-and-srm-notes.html

Guest Memory Utilization with Nehalem, ESX 4 and vSphere

One of the hot things to buy now with a new vSphere implementation are a set of beefy hosts with the new Nehalem processor line. This is great but there is a bug you need to watch out for. Memory usage for guests are showing 80%-90% utilized when actually there will only be 30%-50% consumed within the guest VM. This can really throw you for a loop and after some research, it appears to have something to do with Transparent Page Sharing or TPS and the way it works with MMU enabled.

You can learn more about MMU and VMware here

http://blogs.vmware.com/performance/2009/03/index.html

According to a VMware communities thread I was reading, there should be a patch coming out mid to late September. In the meantime you could disable large page sharing as a workaround, however, this will cause a big loss in performance. Check out this community thread for more info as well.

http://communities.vmware.com/thread/211585;jsessionid=C282B0ADD49F2A96E3CA99A7951DC974?start=0&tstart=0