Cleaning up orphaned replicas in View

If, like me, you have been through all the versions of View Composer and the broker since its introduction, various bugs and broken recompositions will have left you with a large amount of detritus in your VMwareViewComposerReplicaFolder, making it hard to keep an eye on the proper operation of the Composer, and in my case, causing a datastore to run out of space and subsequent operations to fail. Time for a clean up.

This is decently documented here, but how do you know which ones you can delete?

I don’t and have never worked in the Composer team, so corrections and additions welcome on the below especially where I have marked (???), but observation of the tasks shows the process is as follows:

  1. Copy parent VM at certain snapshot to a new VM called temp-<ridiculousGUID> in the same place as the parent VM
  2. Delete that VM (??? Clearly something else is happening, but you watch the tasks)
  3. Copy that VM to each datastore and register as replica-<ridiculousGUID> (???)
  4. Create a linked clone off each replica in the same datastore, and register as source-<ridiculousGUID>
  5. For each VM, copy the source VM to a new directory and link it back to the replica

All well and good until this process breaks down and you’re left with the broken bodies of hapless VMs lying around. So you should have one source and one replica VM for each parent snapshot deployed in each datastore. The formula is

VMs in replica folder = <Num. parent snapshots in active use> x <Num. datastores> x 2

In my environment I have one parent VM snapshot in use by 40 VMs spread across 4 datastores. So:

1 snapshot x 4 datastores x 2 = 8 VMs in replica folder

So I should have 8 in there. What do I actually have?

Where did those two temps come from?

Err, 10. Those two temp- VMs ought to have been deleted by the composer. This is the view after I’d done aload of cleaning up – I originally had all sorts of dead source and replica VMs in there. How do I know which ones are actively in use and which can be deleted? A simple tip is to change the value of the Notes property of the parent VM, and redeploy your clones. Anything the Composer is still properly in charge of and not using will be deleted automatically. Anything else will be very visible. Look at that image again, and you’ll see that the two temp VMs have different date values in the Notes column. They are from a previous snapshot, and can be deleted. Follow the process in the link above to unprotect them, and then right-click and Delete from disk.

I have now deleted about 15 different source, replica and temp VMs in this way, and all operation is still normal.


Be Sociable, Share!


    1. chuckgman says

      Duncan – The question for me is how to easily identify them. We have a thousand desktops and dozens of templates…

    2. says

      You’re right – my simple tip only works if you can recompose all the desktops. I guess it’s really something to remember for the future. If the orphans aren’t causing you any immediate issues, then there’s no pressing reason to delete them. Just remember next time you recompose the desktops to also change the Notes, and eventually you’ll have got through them all and be able to spot them. How long it would take depends on how often you update. Personally I like to update every couple of weeks for Windows updates, and to keep everyone on their toes…

      I did start wading through the SVI DB to see if I could work it out that way, but I quickly ran out of enthusiasm. It can probably be done.