Identifying which VMware View replica belongs to which virtual desktop

One of the common issues I’ve come across over the past few months for clients was when I was asked to identify which replicas belonged to which virtual desktops in VMware View environments because a lot of my clients suspected that they had orphaned replicas that were not in use.  When approached with such a request, I usually perform one of the following 3 options:

Option #1 – Use the SviConfig.exe command to find unused replicas

VMware actually provides an official KB that demonstrates how to use the SviConfig.exe command to generate a unused-replica-*.txt file that lists replicas that it is able to identify as being unused.  While I’ve found that this doesn’t always work because I’ve had several occasions where the txt file generated was empty, this is the safest route to take. 

Finding and removing unused replica virtual machines in VMware View (2009844)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2009844

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Option #2 – Identifying replica mappings through the ESXi console

Another VMware KB that is available demonstrates how to generate a txt file that contains all of the replica to virtual desktop mappings which can then be used to identify which replicas are actually in use.  I find that this process can potentially be prone to human errors so steps such as renaming the identified replica folders and leaving them for a week rather than deleting them outright should be taken.  The KB that outlines the steps is the following:

Determining which replica disk is used for a linked clone virtual machine (1031842)
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1031842

As I found that the process can potentially be confusing, I’ve documented one of steps I recently went through so that I can reference it in the future:

Begin by executing the following command to find the replicas in the VMX files:

find /vmfs/volumes/ \( -size -1500c \) -name *.vmdk -exec grep replica {} -H \; | grep 'parentFileNameHint=' > replicalist.txt

Use the following command to format the replica information dumped into replicalist.txt and output it to replicalist2.txt:

sed s/:/'-->>'/ < replicalist.txt >replicalist2.txt

From here, the KB article suggests to use the less replicalist2.txt command to view the information but I found that it’s not easy to copy the information from the putty session so simply use the cp command to copy the replicalist2.txt file into a regular VMFS store then use the VMware vSphere Client to download it:

cp /replicalist2.txt /vmfs/volumes/LUN01-ISO/

Proceed with downloading the replicalist2.txt file onto your desktop or laptop and opening the file which should look similar to the following:

Note that all each virtual desktop is represented by the block of text similar to the following:

/vmfs/volumes/4f6480d0-73e03584-c40c-0025b500000c/VIEW4-011_1/VIEW4-011.vmdk-->>parentFileNameHint="/vmfs/volumes/4f6480d0-73e03584-c40c-0025b500000c/replica-496f01b1-630d-4b04-8872-/replica-496f01b1-630d-4b04-8872-.vmdk"

With the replica information in the text file begin traversing through the list of replicas listed in your vCenter:

… and copy each replica:

replica-006164ad-adfe-4fbb-92e6-e32edc60e24f

What’s important to note is that you will need to remove the last string of characters highlighted in red as shown above so that you only have the following:

replica-006164ad-adfe-4fbb-92e6

With the truncated text shown above, perform a search in the text file:

Pay attention to the results that the find feature returns as you are expected to get a return from all of the results because the replicalist2.txt file contains references to the replicas themselves stored on the VMFS stores.  The key here is to determine whether the replica ID shows up on a line that is linked to a virtual desktop and in the example below, it doesn’t:

With this in mind, what this means is that we should be able to unprotect the replica:

Removing orphaned replicas in VMware View 4.6 with sviconfig.exe
http://terenceluk.blogspot.com/2013/03/removing-orphaned-replicas-in-vmware.html

… rename the folder containing the replica on the VMFS store, and then wait a few days before deleting it.  Make sure you’re just renaming the replica in the VMFS folder and not the actual replica in vCenter in case you need to quickly roll back.  Once you’ve confirmed that the replica is indeed not in use because all the virtual desktops continue to be in good health, proceed by renaming the folder that was renamed and then right clicking on the replica in vCenter then delete.

As the example above showed a replica that is orphaned, the following is a demonstration of one that is being used:

replica-07c8e7df-449e-4372-8701-b4e7519223e0

replica-07c8e7df-449e-4372-8701

Notice how the following find research brings us to a line that is associated with a virtual desktop named VIEW46-001:

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Option #3 – Recompose all desktops with a new snapshot

Another option I’ve found to be the easiest way to clean up old replicas is to perform a recompose of all of the virtual desktop pools with a new snapshot then remove any replicas that are not dated the day of the rollout.  The reason why we can do this is because if all of the desktops are using the new snapshot that was created, the old replicas should get automatically deleted by View and if they are indeed orphaned then you should at least be able to safe rename the folder in the datastore, wait a few days then delete them. 

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Another possible alternative that I thought would have been a good was a post someone mentioned in the VMware forums:

In a small environment you may be able to locate the linked clones by browsing the database tables

From the Composer database:

    1.    In dbo.SVI_SIM_CLONE, get the REPLICA_ID from the row that the linked clone virtual machine is shown under VM_NAME.

    2.    In dbo.SVI_REPLICA, match the REPLICA_ID found in step 1 under the ID column and get the value for that row under REPLICA_MOID.

http://communities.vmware.com/thread/340859?start=0&tstart=0

Unfortunately, the columns referenced in the tables did not appear to show the mappings so while it would have been nice to be able to use SQL queries to identify the orphaned replicas, it does not appear to be possible to do this.