I've run into a few scenarios where it's been beneficial to not replicate a particular disk attached to a VM when using vSphere Replication, yet in order to recover the VM correctly it's necessary to have even a really stale copy of it there as a placeholder.
For example, a SQL Server might have a temp DB on a dedicated disk. We want it to be available so the VM will boot and SQL will have the DB there to use, but it is a waste of bandwidth to replicate it on an ongoing basis.
So the workaround is to copy the disk over to the recovery site, or to replicate it at least once. There are other means, but this is the simplest as it gives you a disk that has the right ID etc.
Next, copy the replicated but unwanted copy of the disk at your recovery site to somewhere else. This is important, as the next step is to disable replication for that disk and detach it within vSphere Replication as identified in this blog. The reason we copied the disk somewhere else is because disabling/detaching the disk very sensibly deletes the replicated copy of it!
Force another sync, to make sure it's all up to date, then move the copy of the disk back into the original directory at the recovery site.
You should now have a disk that is a one-time copy, resident in the recipient directory at your recovery site, but not being replicated on an on-going basis.
The last step is to use a simple PowerCLI script to attach the disk using a callout in the recovery plan. This script will use the stale copy of the disk and mount it to the VM during the recovery process.
You'll need to have powershell and powercli installed on your recovery SRM server as outlined in this post, and create a very simple script that looks something like the following.
Obviously there are specific variables that you'll need to alter to match your environment. They've been marked in italics in the below example.
Finally, add a poweron script to the VM in your recovery plan that calls the script on the SRM server (not a prompt, nor a script that runs within the VM):
Note two other things about this. First, I'm using the 32 bit syswow64 powershell. This is necessary because SRM is a 32 bit environment. Secondly, I am also presuming your SRM service is running with VC admin-level credentials like a domain admin or service account, because this is the security context under which the script will be executed on the SRM server. If this is not the case you can add hardcoded userids and passwords in the script to authenticate against the VC.
So what's the end result and the benefit?
It will automatically attach the appropriately IDed disk to the VM that needs to have the disk without doing ongoing replication of unneeded data. Perfect for a temp DB scenario where the data is junk but the DB won't work correctly without it!
