Bochet.net repost : VMware View 5.0 VDI vHardware 8 vMotion Error

Thanks to Jason for this post, as I had this happen this morning:

I had this message.

I twittered this, @rogerlund: error when I vmotion aaron’s pc between two ESXi 5 hosts. lockerz.com/s/140661269

Jason, responded, @jasonboche: Read my blost post from last night RT @rogerlund: error when I vmotion aaron’s pc between two ESXi 5 hosts. http://lockerz.com/s/140661269

I found the following on his blog.

VMware View 5.0 VDI vHardware 8 vMotion Error

“

General awareness/heads up blog post here on something I stumbled on with VMware View 5.0.  A few weeks ago while working with View 5.0 BETA in the lab, I ran into an issue where a Windows 7 virtual machine would not vMotion from one ESXi 5.0 host to another.  The resulting error in the vSphere Client was:

A general system error occurred: Failed to flush checkpoint data

I did a little searching and found similar symptoms in VMware KB 1011971 which speaks to an issue that can arise  when Video RAM (VRAM) is greater than 30MB for a virtual machine. In my case it was greater than 30MB but I could not adjust it due to the fact that it was being managed by the View Connection Server.  At the same time, a VMware source on Twitter volunteered his assistance and quickly came up with some inside information on the issue.  He had me try adding the following line to /etc/vmware/config on the ESXi 5.0 hosts (no reboot required):

migrate.baseCptCacheSize = “16777216″

The fix worked and I was able to vMotion the Windows 7 VM back and forth between hosts.  The information was taken back to Engineering for a KB to be released.  That KB is now available: VMware KB 2005741 vMotion of a virtual machine fails with the error: A general system error occurred: Failed to flush checkpoint data! The new KB article lists the following background information and several workarounds:

Cause

Due to new features with Hardware Version 8 for the WDDM driver, the vMotion display graphics memory requirement has increased. The default pre-allocated buffer may be too small for certain virtual machines with higher resolutions. The buffer size is not automatically increased to account for the requirements of those new features if mks.enable3d is set to FALSE (the default).

Resolution

To work around this issue, perform one of these options:

• Change the resolution to a single screen of 1280×1024 or smaller before the vMotion.
• Do not upgrade to Virtual Machine Hardware version 8.
• Increase the base checkpoint cache size. Doubling it from its default 8MB to 16MB (16777216 byte) should be enough for every single display resolution. If you are using two displays at 1600×1200 each, increase the setting to 20MB (20971520 byte).To increase thebase checkpoint cache size:
  1. Power off the virtual machine.
  2. Click the virtual machine in the Inventory.
  3. On the Summary tab for that virtual machine, click Edit Settings.
  4. In the virtual machine Properties dialog box, click the Options tab.
  5. Under Advanced, select General and click Configuration Parameters.
  6. Click Add Row.
  7. In the new row, add migrate. baseCptCacheSize to the name column and add 16777216 to the value column.
  8. Click OK to save the change.

  Note: If you don’t want to power off your virtual machine to change the resolution, you can also add the parameter to the /etc/vmware/config file on the target host. This adds the option to every VMX process that is spawning on this host, which happens when vMotion is starting a virtual machine on the server.

• Set mks.enable3d = TRUE for the virtual machine:
• 1. Power off the virtual machine.
  2. Click the virtual machine in the Inventory.
  3. On the Summary tab for that virtual machine, click Edit Settings.
  4. In the virtual machine Properties dialog box, click the Options tab.
  5. Under Advanced, select General and click Configuration Parameters.
  6. Click Add Row.
  7. In the new row, add mks.enable3d to the name column and add True to the value column.
  8. Click OK to save the change.

Caution: This workaround increases the overhead memory reservation by 256MB. As such, it may have a negative impact on HA Clusters with strict Admission Control. However, this memory is only used if the 3d application is active. If, for example, Aero Basic and not Aero Glass is used as a window theme, most of the reservation is not used and the memory could be kept available for the ESX host. The reservation still affects HA Admission Control if large multi-monitor setups are used for the virtual machine and if the CPU is older than a Nehalem processor and does not have the SSE 4.1 instruction set. In this case, using 3d is not recommended. The maximum recommended resolution for using 3d, regardless of CPU type and SSE 4.1 support, is 1920×1200 with dual screens.

The permanent fix for this issue did not make it into the recent View 5.0 GA release but I expect it will be included in a future release or patch.”

I quoted the whole blog, as I thought it was a great post, Thanks Jason!

Roger L