Thursday 18 August 2016

vSphere Upgrade 5.0 to 6.0 - Part 7

vSphere Upgrade 5.0 to 6.0 - Part 7

This post deals with Site Recovery Manager. In its current state it's not working, has no clue about web interfaces and the plugin is not compatible with vCenter 6.0. The SRA is also out of date so there's no point even trying to use it. We have our new SQL ready to go, new 2012R2 VMs ready to install SRM on but what is the upgrade process going to be?

  • Upgrade in place and then move SRM & the Database?
  • Move the Database and perform new install on the new VM?
We were unable to attempt the second option with vCenter, but let's see what the KB articles say. Another wrinkle is that we can't upgrade from 5.0 to 6.1.1, we have to go to 5.5.1 first, then 6.0 and finally 6.1.1 !! We saw this in the compatibility guide in the first part of these Posts. 

Migrating an SRM server to run on a different host (1008426)

Check this one out though, very interesting:
Upgrade Site Recovery Manager Server with Migration

The second link seems to indicate we can perform an upgrade by doing a fresh install on the new VM. Now I'm not going to press my luck by jumping too many versions, I'll try installing 5.5.1 first and then upgrade to 6.0 and from there 6.1.1. While one article indicates going from 5.0/5.1 to 5.5.0 or 5.8.0 is ok, the interoperability guide blocks all lower versions out after 5.5.0 so we'll stick with that. 

If you need it the vmware-dr.xml is in the following folder on the old SRM servers:
C:\Program Files (x86)\VMware\VMware vCenter Site Recovery Manager\config\vmware-dr.xml

Take a note of the name of your old DSN using c:\windows\syswow64\odbcad32.exe mine was called SRMDB and used the SQL Server Native Client 10.0. I've the HP SRA "HP P4000 SRA for VMWare SRM 5" installed version 9.5.0.620 and SRM version 5.0.0.1652 also installed. Grab any certificates to back them up but as I'm moving to a new host I'll need to reissue them as the hostname is going to change here. More fun!! You'll also need the SQL 2012 native client we used previously. 

I've a newer SRA version 12.6.0.48 and SRM versions 5.5.1 to deploy. 

Note: It's a bit tricky to get particular SRM versions without maintenance. Trial's will only get you the latest version so unless you have other sources or downloaded them previously you may be stuck. I'm missing 6.0.0 and the following KB says this will not work from 5.8.x:

Upgrading VMware vCenter Site Recovery Manager 5.8 to 6.1 if you have already upgraded vSphere Replication to 6.1 (2136677)

So to start with I've shut down the two legacy SRM VMs. Next I've backed up and restored their SRM databases to the new SQL 2014 instances and upgraded the compatibility levels. I've recreated the SQL accounts for SRM and assign them to that database. Finally I've generated new SSL Certificates for them and created the PFX files so we're all ready to go. 

On the new SRM VMs create 64-bit DSN's to connect to the migrated SRM DBs on SQL 2014, use the SQL 11 Native Client driver. I'm using the same DSN name as on the legacy SRM VMs. I'm not installing or messing with vSphere Replication. 

Run the installer as administrator to be sure. 

So, I'm getting error code -1 when the installer asks for vCenter Server info and you give it the name of vCenter and credentials to connect. This might be to do with SSLv3 being disabled although it's connecting on port 80, but maybe vCenter 6.0 has some other restrictions....? I tried 5.5.0 and got the same error. Then I tried 5.8.0 and the same. One thing I forgot to check is what would happen to SRM after I upgraded straight from 5.0 to 6.0. Only SRM 6.x is compatible so I think I may have missed a step. I should be installing 6.0 now not 5.x. I think it would have been wise to upgrade SRM BEFORE upgrading vCenter. There's NO overlap in SRM versions though. 
I'm certainly not going to install vCenter 5.5 just to get SRM 5.5.0 installed which is a bit crazy. I'm wondering if manually backing up the configuration is going to be necessary, exporting recovery plans and then piecing it all back together again? 

Just for kicks I gave it the SRM 6.1.1 installer. It asks for the PSC address and credentials. Now it gets past the screen I was stuck on before and asks to confirm the vCenter address, then ti confirms the extension information, the plugin ID, then you get this:
So, it's not a compatible upgrade...let's continue and see what happens...

Note: SSL differences in SRM 6.0 from previous versions. You used to have to use the same common name in both sites SSL Certs, no longer the case. Just use the same process for generation except choose the SRM template. Then when you get to the screen below change from IP Address to FQDN as shown or you will get a mismatch error later:
Mismatch if you don't change the IP to FQDN to match the certificate details:

I'm using the following commands with openssl to generate the certs:

openssl req -new -nodes -out rui.csr -keyout rui.key -config openssl.cfg

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:hiccuptest -out rui.pfx

For SRM: rename rui.pfx to rui.p12

Now I can specify the DSN and the credentials but then encounter this error:
What?!!! The compatibility guide says it support SQL 2014 RTM & SP1 so what gives?! Checked the error in the following file:
C:\Users\administrator.LAB\AppData\Local\Temp\2\VMSrmInst.log and saw this:

VMware: Srm::Installation::Database::CheckDbPopulatedAndNeedsUpgrade: INFORMATION: Database already contains product tables.
VMware: Srm::Installation::Database::CheckDbPopulatedAndNeedsUpgrade: INFORMATION: Database data version: 5.0.0
VMware: Srm::Installation::Utility::CompareVersion: INFORMATION: Comparing: 5.0.0 to 5.8.0
VMware: Srm::Installation::Utility::CompareVersion: INFORMATION: 5.0.0 older than 5.8.0
VMware: Srm::Installation::Utility::CompareVersion: INFORMATION: Comparing: 5.0.0 to 6.1.1
VMware: Srm::Installation::Utility::CompareVersion: INFORMATION: 5.0.0 older than 6.1.1
VMware: Srm::Installation::Utility::GetMsgFromErrorTable: INFORMATION: Error message is The provided database version is not supported. Please enter a supported database.

So version 5.8.0 might work but 5.0.0. certainly won't. I can always wipe the database and do a fresh install but it will require additional rework to reconfigure SRM afterwards and the config will be lost. I would export the recovery plans and mappings etc and refer to them when recreating them on the new version. If I find any other way without having to install multiple vCenter versions I'll revert but I think that effort would be wasted. 

Note: I cheated and edited the SQL 2014 SRM Database Table "dbo.dr_product_info" to change the values "data_version" and "version" from 5.0.0 to 5.8.0 and got past the error. 

The second option might be safer but I'll try the first as it's a Lab....Ooops...so close!:
VMware: Srm::Installation::CisRegistration::ValidateVcUuid: INFORMATION: The database is older than 6.0, no VC UUID exists

I re-ran the installer and chose this time to overwrite the existing Database. Creating database tables is where it died the last time but this time it worked. I was shocked! I know this is NOT SUPPORTED however so I think a fresh database and fresh install is my best solution.


I did the same steps on the other SRM server, edited the version in the Database table and chose recreate the data in the SRM 6.1.1 installer. Now install the SRA adapter software on both servers.

Note there is no SRM plugin for the C# Client anymore, you must use the web client. Let's see how SRM looks:
There it is, top row on the right hand side!

Now I'm stuck on pairing options!! This can be due to underlying certificates not being correctly setup so back to the drawing board.

In summary I think I'll do a fresh install of SRM 6.1.1 and recreate the configuration as the SRM 5 to 6.1.1 is just too large a jump unless accompanied by vCenter 5.5 interim which would bore me to death just to get this product upgraded. 

Update: I tried several times to get the underlying stack all built and correctly ssl certificated but usually one small typo defeated me. I reset half the lab but this broke SSO! I've run out of time to try again so all I can offer is to take your time, and you should see the Pairing section work.