vSphere Upgrade 5.0 to 6.0 - Part 4
So, now we've upgrade both legacy vCenter servers to 6.0U2 where do we go from here?! Update Manager has also been installed so we know all vCenter and Update Manager databases are on 6.0 but the underlying OS is still 2008R2 and the SQL backend is 2008R2.
I would be inclined to move vCenter and Update Manager at this point and their databases, as if we point SRM as them now, we're only going to have to change it later when their server name moves.
There is a VMware Kb on moving SRM to run on a different host:
I would be inclined to move vCenter and Update Manager at this point and their databases, as if we point SRM as them now, we're only going to have to change it later when their server name moves.
There is a VMware Kb on moving SRM to run on a different host:
Migrating an SRM server to run on a different host (1008426)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008426
So again this only covers up to SRM 5.5.x but not 6.x!
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008426
So again this only covers up to SRM 5.5.x but not 6.x!
Are we going to keep the same server name and ip address for vCenter? This is a key decision point as if we go with new the ESXi hosts have to be reconnected and what about the SSL certificates? We'll still have to deal with the PSC SSL cert so we may as well do the whole management platform while we're at it....
So where are we overall. We've actually only covered the vCenter & PSC servers as marked in orange below. Not much, huh?!! But we're in a strong position to re-platform vCenter now before returning to look at SRM.
Apart from credentials there is nothing we need off the old vCenter VMs. I'm going to use new Hostnames and IPs and see how I get on. I'll begin by powering down the old vCenter VMs after one last check they are working ok. I also powered down the whole lab and took a snapshot of each so I can return to this point. Watch your disk space!
We'll use the method of backing up and restoring the vCenter and Update Manager Databases to relocate them to SQL 2014 and upgrade their compatibility mode again. Of course this time they are 6.0 databases and not 5.0 so we should be fine. I've created a SQL database backup maintenance plan as it's quicker that way to backup all 3 databases in one go.
Note: You can use a free product like: https://sqlbackupandftp.com but it's limited to two databases. It's an easy product to use though if you're not familiar with SQL maintenance plans.
So, we'll proceed as before, choose to install an External Deployment of a vCenter Server with a new System Name. We point it at the "local site" Platform Services Controller. Choose the DSN and give it the Database Credentials and you might want to say no to the following:
The usual next, next stuff and Click Install....! Wait for this:
Now install the C# Client, Update Manager Server and then we can check things are heading in the right direction....remember the Update Manager frickin' DSN is still 32-bit, not 64-bit. See screenshot below:
So, as far as I can tell you copy the following files from C:\Program Files\VMware\vCenter Server\vpxd\sql to the SQL Server and execute their contents as SQL queries.
Back to the C# client - so the host is disconnected. We could reconnect it now but I want to fix the SSL certificates first in vCenter and the PSC before doing that. Then we can upgrade SRM. Connect to the Web Client next. I'm going to use Firefox as the administrator account won't launch IE in Server 2012R2 and I'm not bothered about circumventing it. I've also installed flash although this is a Lab, I wouldn't do this on a Production server....
Note, I'm got an error in the web client:
To resolve follow this article:
VMware vSphere Web Client displays the error: Failed to verify the SSL certificate for one or more vCenter Server Systems (2050273)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2050273
So, I've a long output file but if you take your time you'll see a number of distinct sections, one per vCenter Server - I've my old and new ones listed so I now need to pull the "Service ID" for thw two legacy ones and purge these from the PSC. I assume the change will replicate but I'll rerun the query on both PSC's to be sure.
This is the query command run from an administrative command prompt:
"%VMWARE_PYTHON_BIN%" "%VMWARE_CIS_HOME%\VMware Identity Services\lstool\scripts\lstool.py" list --url http://localhost:7080/lookupservice/sdk --type vcenterserver > c:\psc_services.txt
This is the command to purge my first legacy vCenter Service ID:
"%VMWARE_PYTHON_BIN%" "%VMWARE_CIS_HOME%\VMware Identity Services\lstool\scripts\lstool.py" unregister --url http://localhost:7080/lookupservice/sdk --id C7BDC2DE-9016-4C01-8921-BCE2DF0ECF38 --user "administrator@vsphere.local" --pasd "YOUR PASS HERE" --no-check-cert
Update the password and run it again with the other Service ID and you should be ok. My query when I ran it again on both PSC's showed that the legacy vCenter's were both purged.
That's it for this post!
So where are we overall. We've actually only covered the vCenter & PSC servers as marked in orange below. Not much, huh?!! But we're in a strong position to re-platform vCenter now before returning to look at SRM.
We'll use the method of backing up and restoring the vCenter and Update Manager Databases to relocate them to SQL 2014 and upgrade their compatibility mode again. Of course this time they are 6.0 databases and not 5.0 so we should be fine. I've created a SQL database backup maintenance plan as it's quicker that way to backup all 3 databases in one go.
Note: You can use a free product like: https://sqlbackupandftp.com but it's limited to two databases. It's an easy product to use though if you're not familiar with SQL maintenance plans.
So, we'll proceed as before, choose to install an External Deployment of a vCenter Server with a new System Name. We point it at the "local site" Platform Services Controller. Choose the DSN and give it the Database Credentials and you might want to say no to the following:
When you connect with the right 32-bit DSN the default choice is to NOT overwrite the database:
Ensure you change the server to use the FQDN and NOT the IP Address:
Now I'll load the C# client and install the Update Manager Plugin. There is an SRM one but I'm not going to load it as it's not compatible until after it's upgraded. I'm just ignoring the certificates for now. I want the warnings to remain however for when I fix them up.
Now we can fix the Database Rollup Jobs in SQL 2014 which are currently missing:
Updating rollup jobs after the error: Performance data is currently not available for this entity (1004382)
The filenames in the article are slightly different as these files have changed name it seems over the various versions of vCenter.
- Log into SQL with the same account your vCenter DSN uses to connect to the vCenter Database
- Double click each in the following order
- Ensure the vCenter Database is selected and not the MASTER DB (You can help by selecting the vCenter Database in the list of databases on the left before double clicking the SQL file below)
- Click Execute:
job_schedule1_mssql.sql
job_schedule2_mssql.sql
job_schedule3_mssql.sql
job_dbm_performance_data_mssql.sql
job_cleanup_events_mssql.sql
job_topn_past_day_mssql.sql
job_topn_past_month_mssql.sql
job_topn_past_week_mssql.sql
job_topn_past_year_mssql.sql
Back to the C# client - so the host is disconnected. We could reconnect it now but I want to fix the SSL certificates first in vCenter and the PSC before doing that. Then we can upgrade SRM. Connect to the Web Client next. I'm going to use Firefox as the administrator account won't launch IE in Server 2012R2 and I'm not bothered about circumventing it. I've also installed flash although this is a Lab, I wouldn't do this on a Production server....
Note, I'm got an error in the web client:
To resolve follow this article:
VMware vSphere Web Client displays the error: Failed to verify the SSL certificate for one or more vCenter Server Systems (2050273)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2050273
So, I've a long output file but if you take your time you'll see a number of distinct sections, one per vCenter Server - I've my old and new ones listed so I now need to pull the "Service ID" for thw two legacy ones and purge these from the PSC. I assume the change will replicate but I'll rerun the query on both PSC's to be sure.
This is the query command run from an administrative command prompt:
"%VMWARE_PYTHON_BIN%" "%VMWARE_CIS_HOME%\VMware Identity Services\lstool\scripts\lstool.py" list --url http://localhost:7080/lookupservice/sdk --type vcenterserver > c:\psc_services.txt
This is the command to purge my first legacy vCenter Service ID:
"%VMWARE_PYTHON_BIN%" "%VMWARE_CIS_HOME%\VMware Identity Services\lstool\scripts\lstool.py" unregister --url http://localhost:7080/lookupservice/sdk --id C7BDC2DE-9016-4C01-8921-BCE2DF0ECF38 --user "administrator@vsphere.local" --pasd "YOUR PASS HERE" --no-check-cert
Update the password and run it again with the other Service ID and you should be ok. My query when I ran it again on both PSC's showed that the legacy vCenter's were both purged.
That's it for this post!
