A WARNING Regarding credentials used to create Virtual Standby in 6.4: If you change the password, you must delete the Virtual Standby AND the target VM, then re-create.

I am writing this merely so that it gets put on the Radar and is an issue that I ran into during the activation of a Virtual Standby clone of a production machine.

If the credentials you are using to manage your virtual standby targets change, you may or may not receive any error or warning regarding whether virtual standby updates have failed. In my case, I did not.

I'm talking about the credentials which are used to authenticate to the target virtual infrastructure. In my case, VMware 6.5 vCenter.

If you attempt to change or edit the virtual standby, and the credentials have changed, you will NOT be able to edit the virtual standby settings. THIS IS A MAJOR FLAW IN THE FUNCTIONALITY OF VIRTUAL STANDBY AND SHOULD BE CORRECTED ASAP.

If you do change the credentials which are used to create / update a virtual standby target, YOU MUST DELETE THE VIRTUAL STANDBY SETUP IN RAPID RECOVERY and - This is key - YOU MUST ALSO DELETE THE TARGET VM. If you do not delete the target VM, then here's what happens: It will go through the entire process of syncing the VM (Which took 24 hrs in my case, see below), then it will DELETE the target VM! Yes, that's right- it will delete it.

For details, here's a timeline of my experience:

1. A virtual standby was created of a physical SQL machine, crucial to our business, in order to facilitate a P to V migration. We used RR for 2 reasons: 1. vmware's tool was very slow and could not do incremental updates; we're talking 2 days plus to migrate this beast to a VM, which failed half the time. 2. so that upon the day of migration of this machine from physical to virtual, the last Virtual Standby update would take minutes, rather than hours, and our testing & dev teams could do their thing quickly.

2. 2 weeks before migration, the password on the account used to sync the Virtual Standby was changed, due to security reasons. This broke the incremental updates going to vCenter NO ALERTS were generated on these failures. When looking at the console, the message read, "Last Virtual Standby: Successful" but with the date of when the password had been changed. (Shame on me for not noticing the date, but...)

3. 2 days before the migration, I log in to double check the virtual standby. I notice that it is 2 weeks out of date! No problem; I attempt a sync. It fails. Upon investigation, I realize the reason is that the password for the account which syncs the virtual standby has changed. No problem... I'll just update it in RR, right? ...WRONG. Upon attempting to go to the settings for the virtual standby, I receive an error message: "Incorrect credentials." I am not able to edit the V.S. settings. A call is placed to support. I am assured that I can delete, then re-create the virtual standby , and if the target VM already exists, it will simply continue to do incrementals, not a full image of the machine. I do this and... Bam. It kicks off a full image of the entire machine. OH WELL... at least it will be finished in about 32 hours right? This pushes our timeline back several hours, but the show can still go on. We inform the dev & testing teams.

4. The next morning, I am delighted to see that it is ahead of schedule. There are only 2 hrs remaining in the V.S. sync. It reaches 99% , then jumps to "Complete!" great! But then to my horror, I see, "VM Deleted." Yes, that's right - after spending 24 hours updating an entire SQL server to virtual standby, IT DELETED IT.

5. I call support back. They apologize, and state that indeed, if you delete a V.S. you must delete the target VM "for security reasons", otherwise it will delete it. 

6. I must re-create and start the entire virtual standby process over. We inform the dev & test teams that it will be another day before our migration is complete. This time it finally works: the virtual standby is powered on, configured, and finally works as it should with the data 100% up to date.

To their credit, support called me back and explained that the two engineers who had given wrong information have been corrected.. I told them that it's not those guys' fault. This is 1. really crappy configuration problem with this product; and 2. such a glaring issue should be highlighted as a very potential red flag with any service call regarding virtual standby.