VMware Player makes my USB KVM switch machines randomly

[corkypa]

I have a Trendnet TK-409 4 port USB KVM attached to several computers, one of which has VMWare Player 1.0.3 on Windows XP. When I am running the player, and only when I am running the player, the kvm, at seemingly random times, suddenly switches to the next machine. It is as if I hit scroll-lock twice to go to the next machine, but I didn't.

It seems to happen more frequently when the cursor is near the edge of the VWware player window. If fact, I had a frustrating experience where I tried to close the player because the kvm was switching machines too often, but when the cursor neared the close box, the kvm switched, thwarting my efforts.

Any suggestions?

[alelievre]

try to uncheck the option "Automatically connect new usb devices to this VM when it has the focus" in the hardware options of your VM.

[corkypa]

VMWare player doesn't have this option, so I checked the vmx file. I see that usb.generic.autoconnect is already false for this vm. Is there something else I could should set?

By the way, I tried this VM in VMware server and had the same behavior. At least it is consistent.

[ddoc961]

I have this same problem with a tripp-lite usb kvm. It seems to happen when the mouse leaves the VM window areas.

[mojoandy]

I get the same thing with my Trendnet TK-207K. So unbelievably irritating.

[GBromage]

This is just a theory on my part, but: When I'm using player and I set a num or caps lock status inside a VM and then leave the VM, my Num or Caps goes of and then goes on again when I enter the VM.

So, obviously something is happening when the VM enters the virtual machine to set the Num and Caps lock, and I'd assume, the Scroll lock status too. If this is done by VMplayer manipulating the keyboard buffer it might literally be "as if you hit scroll lock twice"

Is it possible to reconfigure the KVM to use a different hot key, and see if it's still happening?

[stefanou0]

Same thing .... with Tendnet Tk-209K... 2 ports

Does someone have a solution ?

[braynor]

I confirm this on a TrendNet TK-207 as well running Workstation 6.

And my VM does not have any USB hardware, so no way to tell it not to automatically connect new USB devices when it has focus.

Any way around this??

This is REALLY annoying...

[_Fish___David_B]

PROBLEM DESCRIPTION

Greg Bromage (GBromage) is right: it DOES have to do with VMware monitoring and buffering keystrokes made within your virtual machine and attempting to restore the keyboard state whenever VMware tools detects you've moved the mouse into your virtual machine window. I noticed the same thing he did regarding the state of the NumLock key a long time ago.

And I too have been experiencing this VERY ANNOYING behavior as well. It doesn't happen all the time but it does sometimes occur, and whenever it does it's extremely annoying and frustrating. Scares you too! There you are minding your own business and the next thing you know your USB KVM switch clicks and your screen blanks and you're switched to another physical system! GRRRR!!

I THINK it has something to do with KVM-switching (using the two-quick-key-presses of the ScrollLock key technique that most KVM switches I know of use) whenever the mouse happens to already be within the virtual machine's window. VMware apparently detects/buffers the first keystroke but before it can detect the second, the physical KVM switch itself switches you to the other system (since you DID after all press the ScrollLock key twice!).

BUT... If you then switch BACK to the original system (that 30 seconds before you just switched away from! (by pressing the ScrollLock key twice)), then, as soon as you move the mouse OUT of the virtual machine's window, BOOM! You're immediately switched back to the other system again! VERY frustrating (and annoying!)

TEMPORARY WORKAROUND

I have managed to figure out a viable temporary workaround however (i.e. a way to "fix" the problem whenever it does happen to occur): move the mouse to be OUTSIDE the virtual machine's window so that it is no longer within the virtual machine's window, but is instead somewhere within the HOST's desktop area (or task bar, etc -- basically any place OTHER THAN the VMware-controlled virtual machine's window itself). Your KVM switch will, as described, immediately switch you to another system (sigh), but don't let that bother you. Just switch BACK to the original system you were so rudely switched away from, taking comfort in the fact that:

1. because the mouse should now no longer be within the virtual machine's window (you moved it outside the window, remember? That's why the sudden/unexpected switch occured just now), the problem shouldn't occur (as long as you don't then move it into the window and out again! ("Doctor! Doctor! It hurts when I do this!", "Well then stop doing it!")),

2. you can now easily FIX the condition causing the problem! (keep reading)

How? Simple. Just move the mouse INTO the virtual machine's window (which should NOT cause a switch; only moving the mouse OUT OF the virtual machine's window does that) and then quickly press the ScrollLock key twice again!

You will then of course be immediately switched to your other system, BUT... the weird "half buffered keystroke state" (WM_KEYDOWN buffered but not WM_KEYUP (or something like that)) that VMware was in will be fixed!

Once you do that, then you SHOULD be able to move the mouse into the virtual machine's window AND OUT OF the virtual machine's window WITHOUT VMware causing an unwanted KVM switch.

TO PREVENT THE PROBLEM FROM HAPPENING IN THE FIRST PLACE (until they can get it fixed (which they should now be able to do now that they should be able to reproduce it themselves now that they know how to)), is to simply make sure your mouse is NOT within a virtual machine window whenever you want to switch to another system. Make sure your mouse is OUTSIDE the virtual machine's window BEFORE pressing the ScrollLock key twice .

OR.. simply stop using the ScrollLock key method to switch to your other system(s), and INSTEAD, always press the physical button on your KVM switch (if your KVM switch has one of course).

ADDITIONAL INFORMATION

Again, the problem ONLY seems to occur on hosts that have both a USB mouse AND a USB keyboard, AND the host is using a pure USB-only KVM switch, AND the ScrollLock key is used to switch to another physical system WHILE THE MOUSE IS WITHIN THE VIRTUAL MACHINE'S WINDOW (i.e. while VMware is "monitoring" (buffering?) the virtual machine's keystrokes). If/when you do that, then the problematic "condition" has been created. The trigger has been cocked. From that point on (as soon as the condition has thus been created), as soon as you move your mouse outside the virtual machine's window, BOOM! The trigger is pulled and the unexpected/annoying KVM switch to another system occurs.

And again, to FIX the problem once it does occur, simply press the ScrollLock key twice again while the mouse is within the same virtual machine window as it was before. (Apparently doing the two-ScrollLock-key-presses-in-quick-succession sequence TWICE, somehow "finishes" whatever halfway keystroke processing that VMware was in the middle of doing (whenever your KVM switch "pulled the rug out from under it") such that things are then back to normal. VMware is able to "finish" its keystroke processes the second time you do it (it completes the two halves of the problematic condition) such that the problematic "half in, half out" condition is no longer active/true)

CLOSING COMMENTS

I hope this helps others to deal with this VERY ANNOYING VMWARE BUG while at the same time helps VMware to locate/fix this bug.

VMware is a great product! Please keep up the good work guys!

And don't let these minor annoyances bother you! Just get them FIXED as soon as you can and move on. We're all behind you and expect minor issues like this to crop up from time to time. This post is NOT a criticism but rather just an attempt to help you guys continue doing the fine job you have been and to help others deal with this "glitch" (bug) in the mean time.

Take care.

--

"Fish" (David B. Trout) - fish(at)infidels.org

Fight Spam! Join CAUCE! <[http://www.cauce.org/]>

(Any HTML email received will be deleted unread)

PGP key fingerprints:

RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52

DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

[SEITech]

I've found that a more useful solution is to disable the "Grab when cursor enters window" setting in the VMWare Workstation preferences pane, as well as disabling "Ungrab when cursor leaves window" from the same settings pane.

I found that in _most cases, if I have the VM grab control of the console when I click inside of the window, and have the VM give-up control when I press 'Ctrl-Alt', it does not trigger this rude behavior in my TK-407 KVM. It doesn't stop the issue 100% of the time, but it helps most of the time. While it may seem a hassle to have to click or use the keyboard commands to enter and leave the VM's console, it still is faster and less jarring than actually switching displays via KVM.

Good luck,

N

[ShawnL]

I have been experiencing this issue with my VMware and TrendNet switch too. I have a solutions that works with every KVM switch I have tested that use Scroll Lock twice to switch computers.

The Problem: As you have seen from reading the posts here. This is caused by VMware setting up your keyboard settings when switching from your computer to your VMware image and back. Most KVM switches have a 30 second keyboard buffer to detect the Scroll Lock key being pressed. When you are switching between your VMware image and your computer, you must wait for the buffer to clear before before switching again. This is very annoying and makes you want to beat the crap out of your computer.

The Fix: This may not work for you, but I have tested this on many brands with no issues. First thing, make sure you have installed the VMware tools in your image. If you use the Num Lock, Caps Lock or Scroll Lock make sure they are both set the same on your computer and your VMware image. Example: If your computer has Num Lock On, Caps Lock Off and Scroll lock Off then make sure your VMware is also set this way. This has been tested on VMware version 6. The reason this works is because VMware sets a flag to not change your keyboard settings if there is no difference. If you have Num Lock On on your computer and your VMware has Num Lock Off, this flag is set to update your keyboard settings. Even though the only difference may be your Num Lock, VMware goes through all three and sets them. During this process the Scroll Lock is pressed behind the scenes. Long story short. Make sure they are the same in both environments and your issue should go away.

[bhirsch]

A very simple and effective solution that I found to this problem, as i am running a trendnet TK-209K and VMWare Server, is to run the VM in full screen mode. Once you're in full screen mode you will never see any switching through the KVM. I hope this helps.

[VicoEsco]

Just to add my 2 cents, I had just bought a Trendnet TK-207k and was dealing with the same problem of auto KVM switching when the mouse cursor leaves the VM window, but I think VMware has already addressed this issue. I run Workstation 6.5.1 and there is an option to take the individual USB connected device (Mine is called 'Uni Class 2 Port KVM') from the host machine to the VM ware machine. This solves the problem of having the KVM automatically switch, because VMware has full control over the KVM, but this also means that the hotkey (Scr-Lock Scr-Lock) will only work when the virtual machine has focus. My scenario only calls for one VM; I'm not sure what would happen if running more than one VM session simultaneously, with both sessions trying to take the KVM switch locally, I will try to test his later and let you know later. Hope this helps

[Reyflores]

Where is the "option to take the individual USB connected device (Mine is called 'Uni Class 2 Port KVM') from the host machine to the VM ware machine"?

I have a TrendNet 407K and it was switching like crazy on Windows 7 Beta (Jan 10 release). However, I found the other workarounds posted a couple posts back solved my problem ( disable the "Grab when cursor enters window" setting in the VMWare Workstation preferences pane, as well as disabling "Ungrab when cursor leaves window" from the same settings pane).

[ddhamiltavecap]

Better yet....if you can use bridged networking and use the address range from your router, then use RDP from your host to connect to the VMs...forget the console!

[KeithBernard]

Except if you need to build machines from scratch.

[pquiring]

I have the same problem with my TrendNet TK-209 and so far none of the tips have helped.

But I found something that does work. Make sure the numlock / scroll lock / caps lock states (the lights on your keyboard) are the same in the host system as in the VM system.

Then moving the cursor in/out of the VM doesn't cause VMWare to quickly change the lock states which was causing the KVM to switch.

Problem Solved!

[pquiring]

Usually it's the numlock that causes the switch. Most people keep it on but Linux ignores the BIOS setting so here is how to force numlock on during boot up.

1) install numlockx using yum or apt-get

2) add "numlockx on" to your setup files (ie: /etc/rc.local or /etc/rc.sysinit -- not sure exactly where, it should be after X11 has done init)

This may help.

You can try to enable numlock in VMWare's BIOS and copy the nvram file to each of your VMs, but like I said Linux and other OSes may ignore this setting.

[zookoo]

Another good explanation and solution is here: http://forums.whirlpool.net.au/forum-replies-archive.cfm/911658.html

[oddiofile]

This was indeed the problem I was experiencing with my Trendnet TK-407.

It was all in the num-lock. Now that i know what is happening, it no longer seems random at all and I can avoid it. thanks for all the other great tips here.