vCenter guest console will not release mouse and keyboard when <window> <L> combo is used to lock management station

[sysxperts]

Unlike all the other keyboard and mouse issues I've found in the communities I believe I've found a bug directly related to RHEL 5 guests on ESX 4 and a Windows 7 Enterprise management station connecting to console of guest through vCenter.

I've reproduced the same condition on multiple management stations running Windows 7 against multiple RHEL 5 guests.

This behavior has also only been reproduced on multiple guests running RHEL 5 in init 3 runlevel. Have not tried on init 5 for RHEL, but did note that SuSE 11 guests in init 3 do not produce the same bug.

Also note that we are running ESX 4 with update 1 and all Tools are reporting as OK in the affected guests.

After opening the console of any RHEL 5 guest and changing the focus of my mouse by clicking in the console window, and then locking the management workstation with the combo which reboots the guest and gives back the keyboard and mouse (obviously not good for a prod guest), or power cycling my win7 workstation. Both equally effective at giving the mouse back but neither is optimal for obvious reasons.

[Texiwill]

Hello,

If you have not already, I would suggest you open a case with VMware.

Also, as an alternative, you can use PuTTY, Tunnelier, xrdp, vnc, and other avenues to access your consoles without actually using the vSphere Client. Since this has a limited number of available sessions it is sometimes best to use one of these other mechanisms.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]

Also available 'VMWare ESX Server in the Enterprise'[/url]

Blogging: The Virtualization Practice[/url]|Blue Gears[/url]|TechTarget[/url]|Network World[/url]

Podcast: Virtualization Security Round Table Podcast[/url]|Twitter: Texiwll[/url]

[sysxperts]

Yes, I completely agree that alternate access such as putty should be used, and it typically is. I discovered this oddity while creating an updated template for RHEL 5 and decided to test it against some other existing RHEL 5 guests and from an alternate workstation to confirm. However, there are cases where troubleshooting requires console access so I thought it would be nice to make other users aware that this could happen to them, and let folks know what they should do as a workaround until this bug can be resolved.

[sysxperts]

Update, here is response to SR

Thank you for your Support Request.

To follow up to our conversation, I've been able to reproduce this issue in the lab so I've filed a bug with our engineering team (#536855). This issue appears to stem from the fact that Windows 7 recognizes the WindowsL key combination regardless of where the focus is. I've found that if this occurs, you can hit the Windows key (and release), then CtrlAlt, and your cursor will be freed.

As we discussed I'll close out this case, and if you run into any further issues give us a call and we'll be happy to help.

Thank you for using VMware Support,