left over linked clones

[cdickerson]

I'm noticing that when I recompose my vm's with a new snapshot, that the old linked clone vm's stick around even if I tell it to recompose all the vm's. By linked clones I mean the replica and source vm's in vCenter. Since my vm's are pointing to a new snapshot, why would it keep those old linked clones around? How does this get cleaned up? I'm assumming if I delete the pool that it would delete all the linked clones, but haven't tried. I could see after a year of making changes, adding patches and what not, that you could have a lot of snapshots and thus a lot of linked clones. Or, what happens when you delete (committ) all those snapshots into the parent vm to clean things up? I checked the documentation but maybe I didn't find this explained very well. Thanks

-Craig

[kcampbell]

If you've found an answer to this - please share. I'm dealing with the exact same thing - left over sources and replicas within vCenter. Wondering if there's a way to find out which ones are in use and which ones we can get rid of.

[kamalave]

Hi,

1. To delete the unwanted snapshot.

In VC server, go to snapshot manager >> select the single snapshot >> Delete. Selected snapshot should be deleted.

2. Regarding deletion of replica and source VM.

Connect to ESX box using VI Client, Select the replica or source. Right click >> Delete from Disk. Replica and source will be deleted.

Thanks

[imclaren]

I've just experienced this as well. I've deleted the clones, but now I'm left with them 'orphaned' in VC.

How do I get rid of them???

[kamalave]

Hi,

Remove and add host once in VC Server.

Regards,

Veena

[imclaren]

You mean remove the host? It's part of a DRS/HA cluster, so I'd prefer to avoid that...

The replica- orphan is on one host, and the source- orphan is on another.

Cheers,

Iain

[kamalave]

In that case, select the orphan replica and source. Right click >> select remove from Inventory

Regards,

Veena

[imclaren]

The option's greyed out.

The 'remove host' method is working though, and isn't that hard

Is there a known cause for this behaviour? I'm wondering if it's anything to do with the problem that can sometimes occur when deploying VMs from templates, where the vmdk file points back to the template instead of the new copy... (http://communities.vmware.com//message/1154387)

Cheers,

Iain

[kcampbell]

Thank you very much for your suggestion however, I believe I may have miscommunicated. I know how to delete a virtual machine, it's identifying the replica and source machines (we have 4) that CAN be deleted. We have no way of knowing which ones are currently in use or linked to our View desktop pool.

[cdickerson]

You have to unprotect it in vCenter first. The Inventory path can be a little tricky getting right.

Go to C:\Program Files\VMware Inc\View Composer\

SviConfig.exe -operation=UnprotectEntity -VcUrl=https://<vchostname>/sdk -Username=<VC account name> -Password=<VC account password> -InventoryPath="/<Datacenter name>/vm/<VMWareSviReplicaFolder>/<replica or source>"

Once it's unprotected, you can then delete it. I'm not sure how to identify one either. I would assume looking at the Composer logs on the vCenter server might have some information. Also, their creation date on the ESX server might provide some insight.

-Craig

[kcampbell]

Ahh didn't think of the composer logs and unprotecting -THANKS I'll give this a try!

[imclaren]

Brilliant - that got the litle sod

Have some points!

BTW, the InventoryPath for mine was:

"/Edinburgh/vm/VMwareViewComposerReplicaFolder/source-lc-9c9d92e4-1dcb-4f22-b68a-5f951043b7e9"

"Edinburgh" is my datacenter

" VMwareViewComposerReplicaFolder" is the folder name, as shown under the virtual machines and templates view

"source-lc-9c....." was the name of the orphaned item.

Cheers,

Iain