VDM 2.1 error – Pool control for desktop is unable to create the new VM
November 23rd, 2008 | 
Author: Look for a new VMware KB article in the near future for this VMware VDM error.
I helped implement a VDI solution for a customer that ended up revealing an issue with VMware Desktop Manager (VDM) 2.1 and the resource pools of an ESX Cluster. The explanation of the problem to me was that the VDI desktops auto-deployed via persistent VDM pools were out of sync with the ESX resource pools they were members of, and therefore new VDI desktops could not be cloned by VDM. That’s a little confusing I know, so I’ll try to explain it better by providing the sequence of implementation steps that resulted in the issue.
Here’s how it happened.
- Configured the ESX Cluster that would host the virtual desktops
- Built the internal VDM server to be the connection broker as a VM
- Built the DMZ VDM server to be the security server as a physical server
- Created 4 desktop pools on the connection broker and auto deployed new VMs
- Created ESX Cluster resource pools and moved the auto deployed desktop VMs and VDM server VM into them.
- Due to Active Directory issues, deleted VDM desktop pool number 1 and recreated it with new, auto-deployed VMs as members of the ESX Cluster resource pools.
Later when the customer increased the number of VMs in a few of the desktop pools only the pool number 1 auto-deployed new desktops. New VM clones in the other pools failed with:
“Pool control for desktop [pool name] is unable to create the new VM [vm name] - Cannot clone VM. Invalid folder or resource pool or datastore specified.”
The problem, according to VMware Support, is that VDM is out of sync with the resource pool for the desktop pool. The pool points to the default root resource pool but really should reflect the new ESX resource pool. This can happen when a change occurs such as a resource pool being deleted, renamed, or created. The resource pool information can’t be changed once the desktop pool is created. There was also a mention of some inconsistencies in the ADAM database.
The resolution was to delete the originally created desktop pools and recreate them. When the recreated desktop VMs were cloned they were placed in the now existing ESX Cluster resources pools.
Pool number 1 did not have the issue because it had already been re-created when we experienced AD issues, and although unknowing to us at the time, we actually already fixed the problem via this same process.
As I mentioned at the top of the post, VMware support told my customer they would write up a new KB article for this, and that it would probably be fixed in a future release of VDM. Bottom line is that until a new release with a fix, create your ESX resource pools before you create desktop pools and start cloning VMs. Be sure your resource pool design is final or you will have to delete and recreate the desktop pools and their VMs if you make any changes.
Related Posts
Posted in 
Tags: -
Vladan
