Lag When Dragging a Window Between Monitors in VMware View

Multi-Monitor VMware ViewI’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.

This issue is limited to this configuration:

  • Windows 7 View virtual machines (both 32bit and 64bit)
  • Virtual machine hardware version 7 or 8
  • View Agent 5.0
  • Client desktop utilizing multiple displays

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.

mks.poll.headlessRates CPU Graph

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, http://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, http://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.

Clearpath Solutions Group Logo

Comments

  1. Shaun Gee says:

    Ive seen this since view 5.0 however Ive never had the issue using v7 hardware only v8, have you personally seen the issue with v7 hardware?

  2. Eric Lee says:

    We’ve only seen this on V8 hardware as well. We had this issue on all of ours and had to back them off to V7 to get them working properly. Planning to test this in the next day or so.

    • Eric Lee says:

      Tested and working. Overall performance seems a tad laggy now as compared to before but moving anything between screens no longer “catches” or slows way down. Thanks again for finding the KB and posting it.

  3. Hello Joshua Townsend,

    We’ve only seen this on V8 components as well. We had this problem on all of ours and had to returning them off to V7 to get them functional. Preparing to analyze this in the next day or so.

  4. Eder Pires says:

    Thanks for an excellent article, you’ve saved me lots of research time.
    Regards

  5. Why can’t you simply update your template with the mks settings and recompose? I shutdown one of my linked clones and the setting was clearly there after making the change on my template and recomposing. Perhaps I missed something. Good article!

    • Chris – you are correct. Making the change on your template is the preferred way to go – I had that as a recommendation in the article, but it was buried by my blogging babble ;-). I’ve made it bold to help future folks find it. My script was intended for persistent desktops or linked clones that were running but had some time before a refresh/recompose/rebalance (and users with pitchforks complaining that things were slow, and I didn’t have this problem on my old desktop…).

Trackbacks

  1. […] Note: these aren’t the only multi-monitor issues in View – I covered another one here: Lag When Dragging a Window Between Monitors in VMware View. […]

  2. […] dragging Windows’ windows between physical monitors. I detailed the fix for this problem here: Lag When Dragging a Window Between Monitors in VMware View. No downtime is required to […]

Drop a comment below:

%d bloggers like this: