This means that the Unidesk backup snapshot for a desktop (Desktop3 in this example) has been damaged by the ESX reboot or storage failure, and it also means that the CP was in the middle of rebuilding the desktop when it failed. Because Unidesk was in the middle of rebuilding this desktop, the User Layer was connected to the CP, and now the CP will not boot because an attached disk is invalid.

To solve this, simply Edit Settings on the CP VM in vSphere and remove any disks that are in the UnideskLayers folder.  A CP actually owns only four disks, all stored in the CP's own VM directory: CPName.vmdk is the boot disk, and CPName_1 through CPName_3.vmdk are 1MB stub disks which exist to keep the extra SCSI controllers present in the configuration. Any other disks beyond those four can be safely removed (do not delete them, of course).  Remove them all and then the CP will be allowed to boot. Watch the console in case the failure has also damaged the boot disk and Linux requests an fsck.

Normally, when a CP reboots in the middle of a rebuild with disks still attached, the first thing the CP does is remove the disks from its configuration so it can nstart the rebuilds over. So all you're doing is helping the CP by removing the extra disks before it boots.

Note that your offending desktop (Desktop3 in this example) may stil be damaged, so you may need to manually delete its snapshot or Repair it to an older backup within Unidesk.