The other day I was patching the hosts in a cluster which currently hosts our Virtual Desktop environment. I’ve put the first host in the cluster into the maintenance mode and migrated all the Virtual Desktops to the other host in the cluster. Unfortunately I also migrated the VMware View Linked-Clone replica residing on that host. I forgot to un-tick the prompt tick box about “Powered off VMs” which comes up after you initiate maintenance mode for the host. Luckily this didn’t create a major issue as VMware View doesn’t care about which host the replica resides on. It only cares about the datastore the replica and the linked clones are stored on (so it’s best to turn off SDRS for VDI clusters*). But nevertheless, I wanted to migrate replica back to its original host. However, when I tried to do so, I’ve realised the migrate option on the replica was greyed out.
Later on I found out that this was due to VMware View replicas being protected. They cannot be vMotioned using vCenter credentials. So I up-protected the replica using “Sviconfig.exe” provided with VMware View Composer installation, vMotioned it to it’s original host, then protected it using the same tool. It’s best to keep replicas protected to avoid issues.
VMware recommends using this tool if you want to get rid of “Orphaned” replicas, I didn’t use it for this purpose but the method applies for that case. Our VMware View environment is version 5.3.
Here are the steps for un-protecting a linked-clone replica:
1. Logon to your server hosting VMware View Composer. In our environment it’s on the same server as vCenter. Navigate to the VMware View Composer directory.
2. Right click on the white background with the Shift button down and click “Open command window here”.
3. Prepare your script. Sviconfig.exe is case sensitive. It might be a good idea to create a batch file to avoid typos and casing mistakes. I’ve made the the bits of the script you need to edit red.
SVIConfig -operation=UnprotectEntity -DsnName=VMwareComposerDatabase -DbUsername=DatabaseUser -DbPassword=”DatabaseUserPassword” -VcURL=https://vCenter-FQDN/sdk -VcUserName=vCenterAdmin -VcPassword=”vCenterAdminPassword” -InventoryPath=”/DataCentre/vm/VMwareViewComposerReplicaFolder/replica-09010db9-f5d1-418a-bf48-b15dafcfc4b3” -Recursive=true
-DsnName= DSN for your VMware Composer Database
-DbUsername= The user that can access the VMware Composer Database
-DbPassword= The password for the database user, use quotation marks if you have special characters such as “$” in the password.
-VcURL= Pretty obvsious, the path to your vCenter server, I recommend using the FQDN.
-VcUserName= Your vCenter admin user, I recommend putting in the domain name infront of it if any.
-VcPassword= The vCenter admin password, use quotation marks if you have special characters such as “$” in the password.
InventoryPath= This parameter can be tricky, usually the replicas are stored under the VMwareViewComposerReplicaFolder, you can find the replica store by doing an advanced search using the vSphere client.
/vm before the replica data store name is required and if your data center object is not the top level object and is inside a folder you must reflect this in the path you’re using.
4. Paste your script into the CMD screen you opened previously. Hit enter and wait for sviconfig to complete its process.
Check the “Successfully unprotected entities line”. It should say “1”. You can unprotect the whole folder VMware Composer Replica Folder by altering the path to: “/DataCentre/vm/VMwareViewComposerReplicaFolder” in which case you should see more than 1 entity in the Successfully unprotected entities line.
5. The replica is now un-protected, migrate it using vSphere. Once the migration is complete, protect it by running this script.
SVIConfig -operation=ProtectEntity -DsnName=VMwareComposerDatabase -DbUsername=DatabaseUser -DbPassword=”DatabaseUserPassword” -VcURL=https://vCenter-FQDN/sdk -VcUserName=vCenterAdmin -VcPassword=”vCenterAdminPassword” -InventoryPath=”/DataCentre/vm/VMwareViewComposerReplicaFolder/replica-09010db9-f5d1-418a-bf48-b15dafcfc4b3” -Recursive=true
Here are few helpful forum links and kb articles for anyone who is interested, pretty much the same information, I just elaborated on the subject a bit more.
https://communities.vmware.com/message/1344984
*SDRS will break your virtual desktop environment if you are using linked-clones.
Thanks very much! Your post helped me moving replica’s on a Horizon 7.0.2 environment succesfully.
Hi, thank you for the nice post.
In my case I needed to decom some esxi hosts and I could disable pool and provisioning. Then I was able to out in maint mode all old hosts, move the one with replicas to the new cluster, take it out of maint mode and put it again moving powered off machines. It worked, as pools are now rebalancing/recomposing fine.
Thanks for sharing this with us! I could successfully move around replicas while performing maintenance on the hosts.
Did they remove the “UnprotectEntity” operation from SviConfig.exe? I tried the process outlined here to unprotect a replica so I could vMotion it to another host and got this:
Usage: SviConfig -operation=OperationName [-param1[=value1]][…]
Supported operations:
databaseupgrade
restoredata
removesviclone
findunusedreplica
replacecertificate
changecertificatebindingport
exportdata
There’s no operation named “UnprotectEntity” or “ProtectEntity”. I’m running Horizon 7 Composer 7.12.0