hama007
Contributor
Contributor

Desktop composer fault: virtual machine with input specifications already exists

how can i delete the replica and source from my infrastructure?

my problem is, the view manager has not delete the replica and source and now i have the message by enable pool and provisioning

Desktop composer fault: virtual machine with input specifications already exists

0 Kudos
19 Replies
jp-H
Enthusiast
Enthusiast

Hi,

I think you can do it with VCenter server if you have a admin account.

Then you'd better have a look in all VCS admin screens to see if there is still a reference to the old desktops. If there is, you'll have to delete them.

After that I think, you'll be able to create your new pool.

0 Kudos
admin
Immortal
Immortal

If you really need to unprotect the entities: http://www.thatsmyview.net/2009/04/16/how-to-delete-orphaned-entries-in-the-vcenter/

Regards,

Christoph

Don't forget to award the points if this answer was helpful for you.

Blog:

http://communities.vmware.com/blogs/dommermuth |

0 Kudos
koawmfot
Contributor
Contributor

i am getting the same error as the title of this post. there are some other errors as well.

Desktop Composer Error:VMware.Sim.Fault.InvalidParameterFaultParam: cSpec Detail: AlreadyExist; Error Type:com.vmware.SviService.InvalidParameterFault;Error FaultActor:null; Error code:Client; Error details:[Lorg.w3c.dom.Element;@1b6fedeInvalid parameter:cSpec

So lets just say the error messages in VMview are terrible.

Anyway, I sat and went through the datastores and determined which source/replica vm's had been orphaned and ran the SVICONFIG command line to unprotect them, then delted them in vCenter. I still cannot provision this system and am getting the same error. Does anyone have any suggestion as to where i can look and how to delete the outdated reference from virtual center?

thanks...

0 Kudos
arjanhs
Enthusiast
Enthusiast

I'm having the same problems, when a vm from a particular pool is deployed i receive:

Desktop Composer Fault: Virtual Machine with input specifications already exists

I have removed all the orphaned files, but seems to be an existing vm in the database, is it possible to remove this one?

I have just checked the composer database, and the VM names exist in the table SVI_VM_NAME, is it safe to remove these entries cause the don't exist within the View Manager?

Message was edited by: arjanhs

0 Kudos
koawmfot
Contributor
Contributor

I have just checked the composer database, and the VM names exist in the table SVI_VM_NAME, is it safe to remove these entries cause the don't exist within the View Manager?

hey what tool did you use to look at the database and how do you connect into it?

0 Kudos
arjanhs
Enthusiast
Enthusiast

I'm running SQL Server 2005 on the VC server and i'm using Microsoft SQL Server Management Studio for it, connection is made with the localhost with the currently used credentials.

0 Kudos
arjanhs
Enthusiast
Enthusiast

I'm currently unable to deploy new virtual machines within this specific pool, is there a way to cleanup the database so i can deploy VMs within this pool again?

0 Kudos
koawmfot
Contributor
Contributor

thanks for the pointer. i finally managed to get into the database with sql management studio and deleted name that shouldn't have been in there. it was in a few tables; you'll need to check them all. after that they depolyed ok.

0 Kudos
arjanhs
Enthusiast
Enthusiast

VMware Support told me to use the following steps:

Delete the object from the View Composer Database:

1. Use SQL Manager to open the View Composer database.

2. Locate and open the dbo.SVI_Computer_Name table.

3. Delete the row for the virtual machine in question.

4. Delete and re-deploy the desktop pool or remove the virtual machines with provisioning errors in the View Administrator pool to have the pool automatically re-provision.

But it didn't worked for me, can you tell me in which tables you have removed the records?

Arjan

0 Kudos
hama007
Contributor
Contributor

Bitte an Herrn Faas oder Herrn Leitz wenden

Verlag C.H.Beck oHG München

Amtsgericht München

HRA 48045

0 Kudos
koawmfot
Contributor
Contributor

But it didn't worked for me, can you tell me in which tables you have removed the records?

Arjan

sorry but i can't remember the exact tables. i went through each one individually and just searched for the computer name.

0 Kudos
arjanhs
Enthusiast
Enthusiast

So you searched through all of the tables for the particular machine name, deleted the record and the problem was solved?

0 Kudos
koawmfot
Contributor
Contributor

yes that was pretty much it. i cleared all the tables first and then deployed it so i can't really say which one was the one that fixed it.

if this becomes a more frequent problem i'd probably look into writing a scrip that would do that and you just have to pass the comp name to it.

0 Kudos
jkatz71
Enthusiast
Enthusiast

I had a host disconnect during a VMs provisioning and I got the same error when the host came back and I re-enabled provisioning on the clone pool.

I manually deleted the VM from vCenter.

Then I deleted the folder on the datastore for the VM.

Then I deleted the rows from the following tables: (DB=VMware Linked Clone)

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. But first you will need to delete 2 other rows that 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

Then I re-enabled provisioning and it went along its merry way...

-jonathan

-jonathan
0 Kudos
arjanhs
Enthusiast
Enthusiast

I have solved the problem with using the following query:

#delete VM from VM_NAME and BASE_DISK key

delete from SVI_SC_BASE_DISK_KEYS

where PARENT_ID = (SELECT ID FROM SVI_SIM_CLONE

WHERE (VM_NAME = ‘<VM-NAME>’))

delete FROM SVI_SIM_CLONE

WHERE (VM_NAME = ‘<VM-NAME>’)

Arjan

0 Kudos
koawmfot
Contributor
Contributor

nice. thanks for the script.

0 Kudos
AaronP201110141
Contributor
Contributor

Your solution worked for me, but one change...

"SVI_VM_COMPUTER_NAME where NAME is the deployed VM name"

didn't have the "VM_" in my Composer database

so change it to

SVI_COMPUTER_NAME where NAME is the deployed VM name

Aaron

0 Kudos
foodandbikes
Enthusiast
Enthusiast

After digging through this thread and having to deleted failed deployments all the time, I've created this script. Just change the FAILED_VM_NAME to the name of the VM it was trying to deploy, and execute it.

Hope it helps someone.

DECLARE @vmdelete varchar(20);

set @vmdelete = 'FAILED_VM_NAME';

delete from SVI_VM_NAME where NAME = @vmdelete

delete from SVI_COMPUTER_NAME where NAME = @vmdelete

delete from SVI_TASK_STATE where SIM_CLONE_ID = (SELECT ID FROM SVI_SIM_CLONE WHERE (VM_NAME = @vmdelete))

delete from SVI_SC_BASE_DISK_KEYS where PARENT_ID = (SELECT ID FROM SVI_SIM_CLONE WHERE (VM_NAME = @vmdelete))

delete from SVI_SC_PDISK_INFO where PARENT_ID = (SELECT ID FROM SVI_SIM_CLONE WHERE (VM_NAME = @vmdelete))

delete FROM SVI_SIM_CLONE WHERE (VM_NAME = @vmdelete)

0 Kudos
dgrinnell
Enthusiast
Enthusiast

Hey Guys,

I encountered this as well, the solution for me was to clear out all the VM's in the Pool and enable provisioning again. I let the VM's build out then i was able to do composer functions again.

Thanks

0 Kudos