I'm using the latest version of VMware Workstation (11.1.0) on Windows 7 x64 and I want to be able to do a keystroke of "Ctrl + 1" to go to VM #1, "Ctrl + 2" to go to VM #2, and "Ctrl + 3" to go to VM #3.

Sounds simple right? It isn't.

On Mac OS X, achieving this functionality is trivial with VMware Fusion in combination with Spaces / Mission Control - you can simply put each VM on a separate space and then define whatever space hotkeys you want. I'm migrating from OS X and want this same functionality.

For reference, here are some potential solutions that I've tried and can verify that they don't work:

1) AutoHotkey

AutoHotkey can be used to make hotkeys like so:

^1::WinActivate, Win7(1) - VMware Workstation ^2::WinActivate, Win7(2) - VMware Workstation ^3::WinActivate, Win7(3) - VMware Workstation

These work to enter the VMs, but not to exit; Workstation will feed the "Ctrl + 1" to the VM and AutoHotkey does not take precedence, even if AutoHotkey is run as an administrator.

2) Suspend/Unsuspend with AutoHotkey

This promising post suggests that suspending and that unsuspending AutoHotkey while the VMware window is active will fix the problem:

https://superuser.com/questions/232762/autohotkey-script-to-exit-vmware-window

However, even after copying the exact code and making the necessary string modifications, I can't get it to work with Workstation.

3) Remote Desktop and/or VNC

One possible solution, if all 3 of the VMs in question were running Windows, would be to use Microsoft's Remote Desktop feature. However, one or more of the VMs that I intend to use will be running Linux.

On Linux, it is possible to just use VNC. However, VNC has considerable drawbacks when compared to the native VMware Workstation console window: there is no sound, the resolution won't automatically scale, the performance will be bad, and so forth.

Lastly, the VMs will be on 1) networks that won't be connected to the host via a bridged NIC (with the NIC disabled on the host) and 2) using a VPN without any split tunnel. So there will be no connectivity for either remote desktop or VNC in the first place.

3) A Windows Keyboard Hook

Liuk explains how to use a Windows hook to intercept keystrokes using C++:

http://polytimenerd.blogspot.com/2011/02/intercepting-keystrokes-in-any.html

However, after testing with the demo program, it seems that this method does not intercept keystrokes sent to VMware Workstation.

4) FullScreenSwitch.directKey

It seems that in VMware Workstation used to have this kind of functionality built in, as documented in this SuperUser thread:

https://superuser.com/questions/71901/vmware-workstation-keyboard-shortcut

However, VMware's documentations states that this is for VMware Workstation 5.0. I tried adding these strings to my VMX file and they had no effect, so the functionality must have been depreciated somewhere along the lines between Workstation 5 and 11.

5) PSExec

Wade Hatler mentions that he accomplishes this using PSExec to activate the appropriate AutoHotkey script on the host machine:

http://www.autohotkey.com/board/topic/64359-sending-keystrokes-to-vmware-player/

This solution is questionable in that you have to keep the password of your host machine in plaintext in order to pass it to PSExec.

Regardless, this solution will not work for the reasons also described in #2 above: the VMs in question will be on 1) networks that won't be connected to the host via a bridged NIC (with the NIC disabled on the host) and 2) using a VPN without any split tunnel. So there will not be guaranteed connectivity between the host and the guest.

6) Execute a "Host" keystroke between every "Ctrl + #" keystroke

This is problematic in that it doubles the amount of keystrokes involved and makes it impossible to "flip" through all of my VMs by holding down control and hitting 1 + 2 + 3 + 4 + 5, and so forth.

7) Use the "Host + Left/Right Arrow" hotkey and/or VMware-KVM.exe for cycling functionality

This is problematic in that when I have 10 or more VMs open at a time, rotating through all of them becomes incredibly cumbersome and inefficient.