Lag When Dragging a Window Between Monitors in VMware View

I’ve had several customers ask me for help with the VMware View environment recently, as their users were complaining about performance issues when dragging a window between monitors in a multi-monitor VMware View setup.   Performance was otherwise acceptable on the View desktops.  I recommended several troubleshooting and remediation steps to get windows to stop slowing down when dragging between monitors or “catching” on the border between the two screens, including:

1. Review the “Multimonitor PCoIP sessions are not displayed as expected KB article” (1030566) from VMware.
2. Monitor PCoIP statistics (using PerfMon/WMI data, vCenter Operations, the PCoIP Log Viewer utility, or Xangati).  Great data collected, but no problems found.
3. Tweak PCoIP settings with the PCoIP Group Policy and the PCoIP Configuration Utility.  Again, fine tuning done, but no change in the problem.
4. Collecting Diagnostic Information from the View Agent, View Client, and View Connection Server.
5. Review the Symptoms and Resolution steps in VMware KB 1027899: Dual monitors configured using PCoIP does not span both the monitors for VMware View.
6. Increase video RAM for View desktops in the pool.
7. Increase client cache size setting in VMware View PCoIP Group Policy Objects (GPO)
8. Upgrade thin client/zero client firmware.
9. Upgrade to View 5.1 for PCoIP improvements (and all the other great enhancements in 5.1).  This takes a bit of planning, so not reasonable as a quick fix.

These steps either yielded no results or were not easy to do without some planning and change control.

Then I stumbled on VMware KB article 2010359, “Poor performance when moving windows between multiple displays in View 5.x session.”  The article was just updated yesterday (7/25/2012) to include View 5.1 as an affected product.

From the KB article:

This issue occurs due to the way View handles the transition of a window from one display to another. It relies on the MKS poll rate which is optimized for server configurations to reduce CPU cycles.

For those who don’t know, MKS is:

Mouse Keyboard Screen (MKS) process – A process that is responsible for rendering the guest video and handling guest operating system user input.

See VMware KB 1019471 for more on MKS, VMM, and VMX processes, as well as how to interpret error for all of these services.

The fix is to enter an advanced configuration parameter on the affected virtual machine as follows:

1. Power off the virtual machine using the vSphere Client.
2. Right-click the virtual machine and click Edit Settings.
3. Select the Options tab and under Advanced.
4. Click General.
5. Click Configuration Parameters and click Add Row
6. In the Name field enter mks.poll.headlessRates and in the Value field enter 1000 100 2.
7. Click OK.
8. Power on the virtual machine.

When the virtual machine is powered on, it will read the new configuration.

Pretty easy, no?  Not so fast….  The fix requires downtime, for all your View desktops.  And, if you are using VMware View Linked Clones, the change you make to any of the clones will be lost when the VM’s are refreshed at log off, rebalanced, or recomposed.  To get the fix to stick, you need to update the template on which your pool is based on then recompose the pool.  If a recompose is not in your immediate future, you may have to tell your users to wait it out.

If you have a bunch of full desktop pools, dedicated linked clones, or manual pools in View that you want to make this change on, today is your lucky day.  I put together a PowerCLI script to automate the change.  I borrowed from the script from Arne Fokkema to fix the storage vMotion “migration exceeded the maximum switchover time of 100 second(s). ESX has preemptively failed the migration to allow the VM to continue running on the source host” error.

The script should be applied with all target VM’s powered off.  That said, I ran it in the Clearpath lab against a running pool of View Linked Clones and had the .vmx file updated.  The VMware KB clearly states that “When the virtual machine is powered on, it will read the new configuration.”  From my testing, the setting did not seem to take place on the running VM’s until I rebooted them – but your mileage may vary.

Also note (per the VMware KB article 2010359) , there is a risk in making this change to your View desktops – CPU utilization on idle VM’s can increase.  Less idle time means higher CPU usage on your ESXi hosts/cluster and increased CPU Ready in your environment.  I did not see an increase in my environment, but the lab is small.  Test, test, backup, test some more, and backup again before making the change or running my script.

The script is below.  Update the vCenter server variable and the name of the vCenter folder (not the View Administrator folder) that contains your View desktops.

@"
===============================================================================
Title:            Fix-ViewWindowDrag.ps1
Description:    Update mks.poll.headlessRates for improved VMware View
performance    and reduced lag when dragging Windows between
desktops in a multi-monitor PCoIP environment. See VMware
KB 2010359 for more info.
Warning: may increase CPU on View ESXi Hosts!!!
Last Updated:     July 26 2012
Created by:        Josh Townsend, https://vmtoday.com
Usage:            Update variables.  Run .Fix-ViewWindowDrag.ps1 in PowerCLI
===============================================================================
"@
$VMFolder = "View-Desktops"    # Folder where View VMs have been placed - Must be unique in VC
$vCServer = "vcenter.local"    # Name or IP of VMware vCenter Server hosting View Desktops

# Connect to VC
Connect-VIServer -Server $vCServer

# Get all VMs placed in $vmfolder
$vms = Get-VM -Location (Get-Folder $VMFolder)

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

$extra = New-Object VMware.Vim.optionvalue
$extra.Key="mks.poll.headlessRates"
$extra.Value="1000 100 2"

$vmConfigSpec.extraconfig += $extra

foreach($vm in $vms){
$vm.ReconfigVM($vmConfigSpec)
}

# Disconnect from vCenter Server
Disconnect-VIServer -Confirm:$False

Here’s a copy of the PS1 file: Fix-ViewWindowDrag

I also have a copy of the script that will target just a single VM – good for testing or those few full VM pools you might have:

@"
===============================================================================
Title:            Fix-ViewWindowDrag-single.ps1
Description:    Update mks.poll.headlessRates for improved VMware View
performance    and reduced lag when dragging Windows between
desktops in a multi-monitor PCoIP environment. See VMware
KB 2010359 for more info.
Warning: may increase CPU on View ESXi Hosts!!!
Last Updated:     July 26 2012
Created by:        Josh Townsend, https://vmtoday.com
Usage:            Update variables.  Run .Fix-ViewWindowDrag.ps1 in PowerCLI
Note: This fixes a single VM
===============================================================================
"@
$VMFolder = "Windows7"    # Folder where View VMs have been placed - Must be unique in VC
$vCServer = "192.168.1.111"    # Name or IP of VMware vCenter Server hosting View Desktops
$VMName = "MyLaggyViewVM"      #Name of the View desktop that you want to tweak

# Connect to VC
Connect-VIServer -Server $vCServer

# Get all VMs placed in $vmfolder
$vms = Get-View -ViewType VirtualMachine -Filter @{"Name" = "$VMName"}

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

$extra = New-Object VMware.Vim.optionvalue
$extra.Key="mks.poll.headlessRates"
$extra.Value="1000 100 2"

$vmConfigSpec.extraconfig += $extra

foreach($vm in $vms){
$vm.ReconfigVM($vmConfigSpec)
}

# Disconnect from vCenter Server
Disconnect-VIServer -Confirm:$False

And the single VM .ps1 script download: Fix-ViewWindowDrag-single

Leave a commend below if you have questions, problems, or have a better way of implementing this!
This article is cross-posted on the Clearpath Solutions Group blog – follow me and my fellow VMware, EMC, and Cisco experts for news, tips, and tutorials.