• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

"stuck" VMs - looking for help, please

Eulogy

2[H]4U
2FA
Joined
Nov 9, 2005
Messages
3,518
Have an odd dilemma, and I'm trying to find the root cause of this instead of band-aid'ing it.
Recently, my trusty C6100 died. After much troubleshooting, I decided to just buy a new, similar system off eBay. I found one, bought it, and received it yesterday.
Of note, the C6005 I bought was damaged in transit. I notified the seller, and he's giving me the weekend to play/test it to try to make sure it's OK. Old system was dual Intel L5560s, 48GB DDR3 ECCs / node. New system is dual AMD 2419 EEs, 48 GB DDR3 ECC. So definitely some architecture change.
Regardless, I setup the system in a near identical way as my old one was. My evaluation licenses only had a couple of weeks left, so I just re-installed new everything. Each node has it's own 4GB USB drive, running 5.5 1331820.

I spun up a vCetner VM and got it configured. Within vCenter, I created a new data center, and a cluster underneath that containing all three of the "new" nodes. Initially, I had HA and DRS enabled on the cluster. In troubleshooting, I disabled HA. Outside of the cluster, I have one standalone host that's running 5.1.0 1157734.

Within the cluster I have 15 VMs, 12 of which run 24x7. The majority of these are Server 2012 R2, but there is also a CentOS machine, plus various VMWare appliances.

Of the 12 that are running, it seems that any one of them will periodically (random interval from an hour to 3 hours it seems) get "stuck". Meaning, I cannot RDP to it, and when I try to connect to the console, sending Ctrl+Alt+Del has no effect (I do not get taken to the windows login prompt). On the login screen, the time is visibility "stuck" as well - no longer incrementing as it should (right now on the console of the ones that are "stuck" they show 1:20pm, it is 1:32pm). Interestingly enough, the machines still reply to PINGs.

The vmware.log file doesn't show a thing out of the ordinary for these stuck VMs. Here's the log entries around one of the VMs that got "stuck" at 1:20:
Code:
2014-07-19T18:59:20.399Z| vmx| I120: TOOLS received request in VMX to set option 'synctime' -> '0'
2014-07-19T18:59:20.465Z| vmx| I120: VMXVmdb_SetCfgState: cfgReqPath=/vm/#_VMX/vmx/cfgState/req/#4/, remDevPath=/vm/#_VMX/vmx/vigor/setCfgStateReq/#82/in/
2014-07-19T20:16:25.450Z| mks| I120: SOCKET 3 (122) Creating VNC remote connection.
2014-07-19T20:27:19.348Z| mks| I120: SSL: syscall error 104: Connection reset by peer
2014-07-19T20:27:19.349Z| mks| I120: SOCKET 3 (122) recv error 104: Connection reset by peer
2014-07-19T20:27:19.349Z| mks| I120: SOCKET 3 (122) VNC Remote Disconnect.
2014-07-19T20:27:28.982Z| mks| I120: SOCKET 4 (122) Creating VNC remote connection.
2014-07-19T20:29:56.127Z| mks| I120: SSL: syscall error 104: Connection reset by peer
2014-07-19T20:29:56.127Z| mks| I120: SOCKET 4 (122) recv error 104: Connection reset by peer
2014-07-19T20:29:56.127Z| mks| I120: SOCKET 4 (122) VNC Remote Disconnect.
I've left the stuck VM just sit for a couple of hours to see if it ever comes back. They do not seem to. Also interesting, it seems that sometimes, performing a vmotion brings the VM back. But not always.
I SSH'd into one of the hosts (note: VMs on all three hosts on the C6005 seem to do this) and ran esxtop. I flipped over to the disk screen, and GAVG is 0.00. Everything else on the memory and cpu screens is normal - higher than I'd ever like to see in a production type environment, but suitable for a home lab.

Anyway, I'm racking my brain here looking for something else to look after. I haven't ruled out network, storage or the hosts at this point - I'm hesitant to point to network or storage, as both have proven fine for the years I've had this lab.

Full setup:
Dell C6005 nodes' two NICS (one is for management/vMotion, other is for VM traffic)-> DLink 24 port managed switch -> Synology DS1513+
ESX Whitebox two NICS (one for management/vMotion, other for VM traffic)-> DLink 24 port managed switch -> Synolog DS1513+

The Synology is setup is an LACP bond, all 4 ports. I'm seeing no issues from the synology dashboard. I'm also seeing no errors on the switch side of things. I'm debating taking out the LACP setup, running just one NIC.
I also have a big spool of cat6 sitting here, so I was thinking of changing my cat5e cables to cat6 - I want to get that done anyway, so maybe at the same time I can rule out any potential cabling issues.

Sorry for the long post. I tried to put all the information I can think of into it. I can grab and post logs if wanted! Thank you for any ideas or help! I'm mostly interested in finding out if the host is actually damaged and I need to return it, or if I'm simply having a network/storage/configuration issue somewhere that I messed up with the new host.
 
Just noticed this in one of the vmware.logs:
Code:
2014-07-19T22:23:02.843Z| mks| I120: SOCKET 2 (117) Creating VNC remote connection.
2014-07-19T22:23:08.677Z| vcpu-0| I120: VMMouse: CMD Read ID
2014-07-19T22:23:19.168Z| vmx| I120: GuestRpcSendTimedOut: message to toolbox timed out.
2014-07-19T22:23:34.167Z| vmx| I120: GuestRpcSendTimedOut: message to toolbox timed out.
2014-07-19T22:23:34.167Z| vmx| I120: GuestRpc: app toolbox's second ping timeout; assuming app is down
2014-07-19T22:23:34.185Z| vmx| I120: GuestRpc: Reinitializing Channel 0(toolbox)
2014-07-19T22:23:34.185Z| vmx| I120: GuestMsg: Channel 0, Cannot unpost because the previous post is already completed
2014-07-19T22:23:34.198Z| vmx| I120: GuestRpc: Channel 0 reinitialized.
2014-07-19T22:23:34.198Z| vmx| I120: GuestRpc: Channel 0 reinitialized.
2014-07-19T22:23:57.126Z| vcpu-0| I120: GuestMsg: Channel 0, Protocol error, state: 0
2014-07-19T22:23:57.127Z| vcpu-0| I120: GuestMsg: Cannot close channel 0: it is not opened
2014-07-19T22:23:58.126Z| vcpu-0| I120: Guest: toolbox: Version: build-1280544
2014-07-19T22:23:58.126Z| vcpu-0| I120: GuestRpc: Channel 0, guest application toolbox.
2014-07-19T22:23:58.161Z| vcpu-0| I120: TOOLS autoupgrade protocol version 2
2014-07-19T22:23:58.162Z| vcpu-0| I120: Vix: [254630 mainDispatch.c:3884]: VMAutomationReportPowerStateChange: Reporting power state change (opcode=2, err=0).
2014-07-19T22:23:58.170Z| vcpu-0| I120: TOOLS Received tools.set.version rpc call, version = 9344.
2014-07-19T22:23:58.170Z| vcpu-0| I120: ToolsSetVersionWork did nothing; new tools version (9344) matches old Tools version
2014-07-19T22:24:59.228Z| svga| W110: MKS-SWB: Can't map source
2014-07-19T22:24:59.253Z| svga| W110: MKS-SWB: Can't map source
2014-07-19T22:24:59.285Z| svga| W110: MKS-SWB: Can't map source
2014-07-19T22:25:34.798Z| mks| I120: SSL: syscall error 104: Connection reset by peer
2014-07-19T22:25:34.798Z| mks| I120: SOCKET 2 (117) recv error 104: Connection reset by peer
2014-07-19T22:25:34.798Z| mks| I120: SOCKET 2 (117) VNC Remote Disconnect.
Sounds more like networking maybe?
 
I was going to suggest a storage issue.
I've seen many VMs stay up and "work" for a long time after the storage layer is ripped out (ADP etc) If the network stack within the OS is still working, all of that could be running in memory. A vmotion would "reset" the storage stack for the VM.

Without host logs, I couldn't say for sure what's up.

A quick test is to setup some type of share on the VM and try to do some remote storage calls. You said Ping still works but rdp fails, see if you can attempt any storage actions.
If its windows see if you can setup a share.
If its a Linux OS, setup a cron job that runs every few minutes to do a file copy. Example, make a 1KB file and have the cron job "copy" that file and name the copy with the system time. Then you can see when things explode.

Let us know if you find out the issue.
Nicholas Farmer
http://pcli.me
 
I just setup shares on a handful of my windows VMs. Hopefully one of them freezes soon and I'll have an answer on that part.
Would it be more helpful for me to pull host logs and post a link to them here?
 
Ok, well, I went onto https://hostname/host and grabbed a few of the log files there, zipped them up, and put them on one of my web servers:
http://resting-blade.com/VM_issues.zip

I'd very much appreciate it if someone much smarter than me can take a look at these! I tried to look through them and I see errors, but I don't know the significance of them. On top of looking through and pointing out to me what is wrong, I'd appreciate any input on how to parse these so I can actually learn from this issue, not just be pointed towards fixes. Thank you!

Edit to add: I'm trying to keep a log of which VMs continually get stuck, starting late yesterday afternoon. So far, I'm noticing three that seem to, so I guess it could just be something with those three. All three of them are windows VMs, but one is the PDC, so I don't want to rebuild if I don't have to.

2nd Edit: to answer nicholasfarmer above - I cannot connect to the shares on the VMs when they "freeze". I have two that are frozen right now... they're non-critical, so I'll leave them like that for troubleshooting / ideas that are presented here :)
 
Last edited:
How are you presenting your data stores? Are they NFS? There was a nasty bug in 5.5/5.1 a while back and vmware's approach was hey don't upgrade yet we don't have a fix for this yet.
 
Yeah, they're NFS right now. I was going to put my Synology in as iSCSI but decided to do NFS instead :|. Is there a KB on the bug, or a way that I can verify that is what I'm actually running into?
The only reason I'm hesitant to point directly towards storage is because the old host that was replaced, and the stand alone whitebox, are using the same storage without any issues (all of those are 5.1).
One thing I'm thinking about doing is moving a handful more VMs back to the whitebox and run there to rule out the storage part of things. I want to leave these as "frozen" for now though so we can troubleshoot while the issue is present :)
 
How are you presenting your data stores? Are they NFS? There was a nasty bug in 5.5/5.1 a while back and vmware's approach was hey don't upgrade yet we don't have a fix for this yet.

the bug was nfs datastores going APD randomly. there has been a fix for awhile now...
 
Going to bump this up, hoping to get some more eyes on it. It still is happening, and I'm not sure where to go / what to look for at this point. I've now:
Put the synology on 1x1Gb link instead of an LACP setup to help rule out network. Closely monitoring the network useage and it's always low.
Replaced all cabling and the switch between the C6005 and the Synology. The new switch was a small, unmanaged switch. No change, so I put my big managed switch back in place.
I dug through the host logs I posted above and still can't quite make sense of the errors. I've googled some, but didn't get much in the way of help there.

One thing I did happen to notice is that on the ESXTOP network screen, the hosts seem to have 100% packet drop on transmit - obviously that's bad, but only seems to happen for a few moments, and then drops back to 0%. That makes me start thinking that potentially, the NICs are bad? Seems odd that 3 NICs would all die at nearly the same time, but stranger things have happened.
 
Going to bump this up, hoping to get some more eyes on it. It still is happening, and I'm not sure where to go / what to look for at this point. I've now:
Put the synology on 1x1Gb link instead of an LACP setup to help rule out network. Closely monitoring the network useage and it's always low.
Replaced all cabling and the switch between the C6005 and the Synology. The new switch was a small, unmanaged switch. No change, so I put my big managed switch back in place.
I dug through the host logs I posted above and still can't quite make sense of the errors. I've googled some, but didn't get much in the way of help there.

One thing I did happen to notice is that on the ESXTOP network screen, the hosts seem to have 100% packet drop on transmit - obviously that's bad, but only seems to happen for a few moments, and then drops back to 0%. That makes me start thinking that potentially, the NICs are bad? Seems odd that 3 NICs would all die at nearly the same time, but stranger things have happened.


We saw this with a network config issue, where we had a combination o f circular and asymmetrical routing going on, maybe someone suggested it but I would validate your New esxi configs
 
First patch up past the NFS bug.
Depending on your network adapters, try to install an older vib or it's it's really behind, update it. I use Intel x540-T2 10gb adapters and they only work with a very old Driver/VIB.
Also,
I remember seeing something weird about "pause frames" but I forget the context.

If you have a single VM that locks up and its small enough to thin provision and place it on local storage, instead of the NFS share, try that and see if it helps at all.

Extremely worse case. Stand up a ninja esx server using some desktop hardware and migrate a suspected VM to it. If the problem follows the VM then you can start working on OS level testing instead of hitting the virtual layer.

Nicholas Farmer
 
Thanks for the additional input fellas. Here's what I did this morning / this evening:
1) Upgraded vib for my NIC (Intel 82576s) from the latest I found on vmware's site
VIBs Installed: Intel_bootbank_net-igb_4.2.16.8-1OEM.550.0.0.1198611
VIBs Removed: VMware_bootbank_net-igb_5.0.5.1.1-1vmw.550.1.15.1623387
(It looks like I went "backwards" with this?)
2) Moved a few "repeat offenders" back to my whitebox ESX 5.1 box
3) Ran update manager and applied all applicable "Critical" and "Non-Critical" patches - the hosts now show 5.5.0 1892794 (I didn't see a patch regarding the APD/NFS issue specifically, but I did not go to the associated KB for every patch. There was 30 in total).

I'm going to be vmotion'ing my VMs around here shortly to reboot the hosts with the new VIBs, and will then simply monitor for a bit. I think I should have an answer on if the guests get stuck on the whitebox by tomorrow morning, as the best uptime I've seen them maintain was about 8 hours or so.

I did notice something when I rebooted for the 30 patches - the ESX hosts booted fine, however had no connectivity on either NIC. Went to the rack and logged onto the console, it showed both NICs as "disconnected". I unplugged and plugged the cables back in and suddenly they came back up. Opened some brand new cables (just in case) and re-cabled it. Verified on the console that they showed connected (they did), went back to my laptop and vCenter was showing it as connected. :|
 
Oh, I also downloaded a tool called PingPlotter. I'm running it against my C6005 nodes, my whitebox and my NAS to see if any have at least ICMP dropping or having high latency. It's not definitive by any means, but will be another data point for me. I may swap in my small unmanaged switch again later this week just to be certain. Bad thing is, it's only 5 ports, and I need at least 8 for NAS/Hosts/homerun to router.
 
Well, the VIB update and applying those 30 patches didn't help at all. The ones I moved to my whitebox never got "stuck" at all (still running from the same datastore on the Synology). I moved all of them back and two got stuck within an hour :|.
PingPlotter never showed a single dropped packet to the NAS or any of the C6005 nodes management IPs. Saw some interesting latency spikes, though.
I went ahead and dropped a spare Intel PRO/1000PT dual port into one of the nodes off of a riser. Disabled the onboard NIC and moved everything over to it... I then vMotion'd all VMs to that single host (it's pretty packed house now!). We just hit hour 6 without a single one getting "stuck". At this point, I'm 99% sure this is my issue. Unless something else comes up, I'll not be updating this thread much more.
Thank you again everyone for your troubleshooting ideas and suggestions!
 
Great to hear you found the problem. Sucks that its a hardware issue. We all hate throwing more money at servers.

Nicholas Farmer
 
Back
Top