App Layering: Failed to Reattach Disks to the Desktop that were Temporarily Attached to the CachePoint Appliance

App Layering: Failed to Reattach Disks to the Desktop that were Temporarily Attached to the CachePoint Appliance

book

Article ID: CTX233778

calendar_today

Updated On:

Description

The error appears when rebuilding a desktop.

Resolution

You may get errors in Unidesk saying a task failed, with the final task detail like either of these (click the (i) for the task to get the details):

The CachePoint Appliance could not create the boot image. Error is: Failed to reattach disks to the desktop that were temporarily attached to the CachePoint Appliance; export the logs and notify Technical Support that this error occurred.

The CachePoint Appliance could not create the boot image. Error is: Failed to detach disks from the desktop and reattach to the CachePoint Appliance; export the logs and notify Technical Support that this error occurred.

This is the error we report when we get a failure of a vSphere Reconfigure task.  Unfortunately, the information Unidesk gets back from vSphere is minimal: we literally only get the SCSI ID we were trying to connect, and often just the generic error:

Error received from VMWare while waiting for requested data.
FaultType: GenericVmConfigFault
Message: Failed to add disk scsi0:4. 

Instead, you need to look at the vSphere Tasks history to get more information about why the vSphere task failed. Each one of those errors in the Unidesk task list has a corresponding Reconfigure task in vSphere that failed, for either the desktop VM or the CachePoint.  Look in their respective task histories for a task failure message like this:

Reconfigure virtual machine
fault.GenericVmConfigFault.summary

And then look at the details of the task error in vSphere for something like this:

Failed to add disk scsi0:3.
Failed to power on scsi0:3.
Reason: 0 (Operation not permitted).
Cannot open the disk '/vmfs/volumes/f7f32637-8403c058/SLOUnideskMCP_1/UnideskLayers/OS/Windows 7 SP1/P1440708100000018.B0.R1.V0.vmdk' or one of the snapshot disks it depends on.

And pay attention to the Reason. You can see reasons like "Operation Not Permitted", "File Not Found", ""I/O Error", "Too many users", "Failed to Lock the File" or "Task In Progress". And probably other errors. We don't have a list of things you should do in each situation, but this is the actual cause of the Reconfigure failure. This is the only information you're going to get, and it will help us considerably in trying to diagnose and fix the error.

Here are the messages where we have a good idea what they mean:

  • "Operation not permitted": this may be telling you that one of your ESX hosts is offline and VMware is trying to route the command through it, and it's failing.  Bring your ESX host back on-line and out of maintenance mode.
  • "Too many users": this may be telling you that you have too many ESX hosts attached to the datastore and trying to use this disk. VMware limits the number of simultaneous ESX hosts attached to a single VMDK to 8. If you have a single CP with desktops spread across more than 8 hosts (via clustering), they will hit this error.  You should limit your custer size to no more than 8 ESX hosts.
  • "Failed to lock the file": First, check to make sure you're not selecting a layer as a prequisite of itself when adding a version. That can definitely create this error. Also, check to see if the specific VMDK file referenced is currently attached to another powered-on VM.  It has been reported once that restarting vCenter fixed this problem. Otherwise, we don't have a solid answer for this, but this VMware KB article may apply: http://kb.vmware.com/kb/10051. In one case, creating and deleting a vSphere snapshot on the desktop VM cleared the problem.  Once we saw a boot disk attached to a desktop twice, and removed the second instance. In other cases, using the Repair function to move the desktop to another CP has helped.
  • "File Not Found": Check to see if the VMDK actually exists. If it exists, there might be a problem with the CP talking to vSphere.  Try restarting the CP.
  • "Input/Output Error": We don't actually have any idea what this means, but rebooting the ESX host solved the problem the one time we've seen this in the field.
  • "Hot-add of digest enabled disk not supported": This means you have enabled "View Storage Accelerator", also called "Host Caching".  This is not supported in Unidesk, and must be turned off.  See this article.
  • "Task In Progress": this is usually a timing issue where another service, like VMware View, attempted to perform a Reconfigure or Power On task just as we were trying to send our own Reconfigure.  We lost, and the task failed.  In Unidesk, restart the desktop to get the task to try again.  Also, if there is a pending vSphere question (for instance, asking if you moved or copied your VM, or if you want to retry after running out of disk space), you must answer the question in vSphere before any other tasks can proceed.