VMware vSphere

Has anyone seen this message before? This happened on a machine which I have 3 snapshots of the machine and went to power off the VM. or connecting: VMX connection handshake failed for mks of /vmfs/volumes/4542ba37-e49f5844-7060-00163581980d/TestPatch01/TestPatch01.vmx

Do you want to try again? Yes or No

I clicked on Yes and the message went away.

Yep also experienced this before. Strange stuff since it disappeared after retrying. Maybe it some kind of timing problem.

I have the same problem in my test-environment.

I can shutdown my "Windows Server 2003 Enterprise Edition" Virtual Machine for 3 or 4 times and nothing happens. But somtimes this message appeares. I don't know the reason.

I'v tried to set the ESX server's time exactly to the time of our VirtualCenter server or disconnected every possible adapter or drive except of the os-vmdk. I also reinstalled our ESX server and created new Virtual Machines but it did't work. It seems to be a hardware problem!? No it shouldn't! With my SuSE Linux VMs there are no problems.

Maybe it's the configuration of the VMs. My Windows-VM has 4vCPUs but my Linux-VM has only one...

In our vpx log I found these lines:

\[2006-11-23 17:12:36.091 'Locale' 316 warning] Default resource used for 'role.Server-Admin.label' expected in module 'auth'.

\[2006-11-23 17:12:36.091 'Locale' 316 warning] Default resource used for 'role.VMware-Admin.label' expected in module 'auth'.

\[2006-11-23 17:12:36.091 'Locale' 316 warning] Default resource used for 'role.VMware-Admin.label' expected in module 'auth'.

\[2006-11-23 17:12:36.278 'App' 380 info] \[VpxLRO] -- BEGIN task-internal-1346 -- vm-950 -- vim.VirtualMachine.acquireMksTicket

\[2006-11-23 17:12:36.481 'App' 380 info] \[VpxLRO] -- FINISH task-internal-1346 -- vm-950 -- vim.VirtualMachine.acquireMksTicket

\[2006-11-23 17:12:37.403 'App' 872 info] \[VpxLRO] -- BEGIN task-internal-1347 -- vm-950 -- vim.VirtualMachine.acquireMksTicket

\[2006-11-23 17:12:37.575 'App' 872 warning] ============BEGIN FAILED METHOD CALL DUMP============

\[2006-11-23 17:12:37.575 'App' 872 warning] Invoking \[acquireMksTicket] on \[vim.VirtualMachine:vm-3]

\[2006-11-23 17:12:37.575 'App' 872 warning] Fault Msg: "The operation is not allowed in the current state."

\[2006-11-23 17:12:37.575 'App' 872 warning] ============END FAILED METHOD CALL DUMP============

\[2006-11-23 17:12:37.575 'App' 872 info] \[VpxLRO] -- FINISH task-internal-1347 -- vm-950 -- vim.VirtualMachine.acquireMksTicket

\[2006-11-23 17:12:40.763 'App' 3620 info] \[VpxLRO] -- BEGIN task-internal-1348 -- vm-950 -- vim.VirtualMachine.acquireMksTicket

\[2006-11-23 17:12:40.966 'App' 3620 warning] ============BEGIN FAILED METHOD CALL DUMP============

\[2006-11-23 17:12:40.966 'App' 3620 warning] Invoking \[acquireMksTicket] on \[vim.VirtualMachine:vm-3]

\[2006-11-23 17:12:40.966 'App' 3620 warning] Fault Msg: "The operation is not allowed in the current state."

\[2006-11-23 17:12:40.966 'App' 3620 warning] ============END FAILED METHOD CALL DUMP============

\[2006-11-23 17:12:40.966 'App' 3620 info] \[VpxLRO] -- FINISH task-internal-1348 -- vm-950 -- vim.VirtualMachine.acquireMksTicket

\[2006-11-23 17:12:44.075 'App' 3324 info] \[VpxLRO] -- BEGIN task-internal-1349 -- host-941 -- VpxdInvtHostSyncHostLRO.Synchronize

Couldn't have anything to do with the 4 CPU-VM cause I experienced it on a 1 CPU-VM aswell.

Seeing the log file is must have something to do with timing and VC not getting the right information at that specific moment.

I've seen the "The operation is not allowed in the current state" messages before, when pressing F5 it was able... so timing is my conclusion.

My belief is that "mks" does mean: mouse, keyboard, screen.

Therefor I tried to let the mouse inside the console screen when shutting down the VM - nothing happened. I retried this a few times and no error appeared. Then I tried this with the mouse cursor outside from the console screen and this error appeared sometimes.

Has anybody had the same experience?

Not really, I still believe that is has something to do with timing

What do you mean with timing? Timing of what?

Timing of something undefined. whenever I go really fast through the VC then sometimes the MKS error occurs. When I relax and don't want to do to many things in a time it doesn't occur.

It sounds strange though..

I have the same issue with one of my VMs.

Moreover I cannot reboot nor power off this VM via VC.

ESX 3.0 & VC 2.0

/var/log/vmware/vpx/vpxa.log

\[2006-12-05 12:24:07.978 'App' 9137072 warning] ============BEGIN FAILED METHOD CALL DUMP============

\[2006-12-05 12:24:07.978 'App' 9137072 warning] Invoking \[powerOff] on \[vim.VirtualMachine:400]

\[2006-12-05 12:24:07.978 'App' 9137072 warning] Fault Msg: "The attempted operation cannot be performed in the current state (Powered On)"

\[2006-12-05 12:24:07.978 'App' 9137072 warning] ============END FAILED METHOD CALL DUMP============

Message was edited by:

look1976

Try restarting the VC services: service mgmt-service restart[/i]

As a workaround you can try and power off the VM via the COS using vmware-cmd

Wow it worked :smileyhappy:

Thanks !

btw. vmware-vmkauthd also needed a restart.

VMware has a fix/patch for this?

Thanks

I also was wondering if there was a patch for this. I have it happening on one of VI3 servers and it happens at random times and about 8 machines lose connection.

After looking through the dump logs I found that every machine that was having an issue errored out trying to access the CD drive. I disconnected the CD drive from all of the machines except 3 of them. Evertime that this issue has happened about 8 boxes went down at the same time, always the same 8 boxes. Two of the boxes that I didn't change the setting on where 2 boxes that would go down with the issue. On Monday the issue happened again but this time only the 2 boxes went down. I have changed the settings on those boxes and will monitor to see if the issue happens again.

What CDROM errors did you get?

Under Master Vliegenmepper's clues, I looked into Windows Time Service and http://kb.vmware.com/vmtnkb/search.do?cmd=displayKC&docType=kc&externalId=1318&sliceId=SAL_Public. Synced time with VC2, ESX3 & VM, disconnected CDROM from VM, and have not seen the symptom since then (knock on wood). I’ll re-connect the CDROM and see if I can duplicate the same issue.

Errors in my VM’s log:

vmware.log:Feb 23 03:08:05.036: mks| SSL: Unknown SSL Error

vmware.log:Feb 23 03:08:05.037: mks| SSL Error: error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure

Wonder if anyone generate a request with VMware. It would be grand to have root cause of this issue.

Hey

It was a bad sector on the cd ( The vm CD-rom was mapped to esx host's cd-rom; NOT A GOOD PRACTICE). I tested the cd on my pc and found out that my windows explorer was hanging. I removed the cd from the ESX host (should have mount to my nfs iso data store instead) and it resolved the issue. Now I have over 30 vm running and none of them has any CD-ROM drive, I just use file share for my windows vms. And it works like a charm.

The error is "vmx| DISK: DISK/CDROM timeout" mot really an explicit error, however, it would just keep reoccurring over and over again and it was only on the machines that went down and it always started directly before they crashed.

I have a ticket open with VMWare but I'm not holding out to much for help they haven't really told me anything besides send them the logs when it happens again.

Hy there,

does anyone have an answer for the problems yet? I am depairing!

First i get the error "Connecting error - the connection to the server has been lost. The application will now exit." And when i try to relogon to the Virtual Infrastructure Client it says "Cannot conect to host... the Target Server refused the connection". After a pair of minutes i can log on, but in time I have to restart the hole ESX cause some VM´s are giving out the handshake-failure.

Hello? This system might go productiv next month???

Puuuuh - never had such problems with ESX 2.5.x - I´m loosing my trust in this ESX 3.0.1 System....

Heeeelp, Thomas

Hi,

Check the Virtual Center service, it has to run.

We have discovered that we can make this error happen reliably if we do the following:

1. Virtualize Citrix Presentation Server 4.5

2. Connect to said virtual machine.

3. Launch the VI Client

4. Click on the console tab of the Citrix vm you are currently connected to via a Citrix ICA connection.

This reliably hoses that server for a while. It eventually comes back if you hit OK to a message from another console connection.

David

I got a similar error for a VMX connection handshake and it was due to a VMFS partition running out of space - another admin was also trying to use that disk resizing feature in the GUI (new for 3.5 and I dont know how it works or what it does) so that may have had a hand in it as well.

Brian

Guys,

HELP ME,

At this point I am really really upset,

My Infrastructure:

SAN: IBM DS4300 (FastT600)

Fabric Switch: Brocade 200E

Path: Active/Passive

Path Failover: MRU

ESX: 3.0.1

System: IBM 365

CPU: 2 x Intel(R) Xeon(R) CPU 5140 @ 2.33GHZ ( Dual CORE)

Memory: 9.0 GB

I was running smooth for 2 weeks, today i added 75 Gb to one of my VM (server 2003 ent sp2), from the guest os added the drive as dynamic disk.

I am getting ": Error connecting: VMX connection handshake failed for mks of..." EVERY TIME I AM TRYING TO COPY 4PPMB FILE FROM CD TO LOCAL HD (DYNAMIC). IT ALREADY HAPPENED 3 TIMES, CURRENTLY I AM ON THE PHONE WITH vmWARE SUPPORT, LET'S HOPE FOR THE BEST.

Hi together,

are there any news regarding this issue?

Sebastian

i had the same problem, and i found out that the VMWare tools was out of date, reinstall it, it was ok.

The CDROM thing was the issue for me. I put a Windows CD in my ESX server yesterday afternoon to load IIS and SNMP on a Windows VM. Then today, only about an hour ago, 2 of my 10 hosts on that ESX server went offline with the "VMX connection handshake failed..." message. I powered them off and back on - same thing. I started researching - about the time calls and email started coming in - and saw this post. I remembered the CD I put in and ran into the server room and ejected it. Then I changed the settings for both VMs to NOT connect the CDROM at power on. Powered them back and and they are fine.

I have had this problem a few times and it seems that each time it happened, the VM had a resource LIMIT on the CPU of zero. Not usre how that happened becasue it has only happened rarely, but changing that setting, of cource, cleared the issue for me.

Also got this at 2 different customers in the last weeks when uppgrading their ESXs. The first time I didn't find any solution for it other than to create a new VM with the same diskfiles, and then it worked.

Yesterday I happened to look under Resource Allocation in the cluster and saw the same thing as Reggie Smith, the machine was limited to 0 MHz. Changed it, and then the VM started as usual.

Notices that a couple of other machines had some strange values in the limit-field, that the customer havn't entered. Maybe a bug in the 3.5 u3.

In both cases I have upgraded to 3.5U3 and enabled Enhanced VMotion in the cluster.

I was recently working with a customer with this same issue on a VM that wouldnt power up. Customer recently did a colo-move and this VM had come up as orphaned. Customer had to remove from inventory and re-add the VM, but customer had not set the Guest OS selection properly. OS was Win2k8 64 bit, but the VM settings had win2k8 32 bit selected. Changed the Guest OS type to win2k8 64 bit and the VM came up with no errors.