Fixing: Desktop composer fault: virtual machine with input specifications already exists in VMWare View

VMWare View 4, though great when it’s working, is a real pain when it’s not working or something is broken. I am constantly learning new things with it, and sometimes have to take riskier steps than others, especially that VMware support is less than useful most of the times.

Today’s issue is related to creating a pool of machines, where one of the machine exists in vCenter, and in the Composer DB, but for some reason, it does not get listed within the pool. At this point, the pool trying to create that VMs conflicts with the actual VM that exists in vCenter, as well as the database entries that exist in the ComposerDB.

Disclaimer: the following steps involve messing with the VMWare Composer database. I take no responsibility if you end up messing your Composer DB. BACKUP, and proceed at your own risk!

Now that the disclaimer is out of the way. Let’s look at the steps to bring your pool back to life.

1. Delete the VM from the datastore, or from within vCenter, “Delete from Disk”
2. Go to the Active Directory OU where your pool workstations exist, and delete the computer object from there
3. Open up the Composer DB database with SQL Management Studio, and you need to delete some entries related to that VM:
   - SVI_VM_NAME where NAME is the deployed VM name
   - SVI_VM_COMPUTER_NAME where NAME is the deployed VM name
   - SVI_SIM_CLONE where VM_NAME is the deployed VM name.
   Before you perform this last query, there are 3 other rows to delete, as they have constraints on them:
   - SVI_SC_BASE_DISK_KEYS where PARENT_ID is the ID from SVI_SIM_CLONE
   - SVI_TASK_STATE where SIM_CLONE_ID is the ID from SVI_SIM_CLONE
   - SVI_SC_PDISK_INFO where PARENT_ID is the ID from SVI_SIM_CLONE

After you perform the above steps, check out your provisioning, or re-enable it if it had been disabled due to the error, and things should continue along without a problem.

Related posts: