After about 6 months of planning and preparing for our VCSA upgrade, we had to completely revamp our upgrade path. In our environment, we use Netapp, and along with Netapp comes some extension like Virtual Storage Console (VSC) and now, the new Netapp Snapcenter.
I spent a lot of my time planning the deployment for an upgrade of our environment which included a upgrade of VSC from 6.2.1 to 7.0 and the install of SnapCenter 3.0, not wait, 3.1, no wait 4.0.
Yes, that’s right, SnapCenter released 2 version in the time of my upgrade planning and it still couldn’t to what needed it to do, mainly cross-domain authentication, so, we had a little shout at our account manager who confirmed cross-domain authentication will be available in August 2018, so lets see what happens. So, this process is still required, however, this made the upgrade a lot easier.
A global overview of our vCenter environment:
There are three deployments, in three separate geographical locations: UK, NA, SA. The SSO domain connects to the AD Domain and passes authentication through the platform services controllers to the vCenter servers, which are all connected via ELM (Enhanced Linked Mode).
Before doing anything, I cleared all old snapshots from all systems and I deleted from disk, all the powered off and decommissioned VMs.
I used VMware vCenter Server 6.5 U1e which was the most recent at the time of the upgrade. I also had to check Interoperability Matrix to ensure all services and applications were in fact, compatible. Whilst looking at the matrix, I realised that our DR hosts are not compatible with ESXi 6.5, but ESXi 6.0U3 is still supported in vCenter 6.5u1 ,so the DR hosts will not be upgrade. Our production hosts however are able to benefit from the later ESXi 6.5u1 upgrade.
I also HIGHLY recommend reading the VMware Best Practices Guide and the attached guides for example: Upgrading the vCenter Server Appliance and Platform Services Controller Appliance
I wanted to deploy to an ESXi host instead of to our vCenter, so I had to ensure I had root access to the ESXi hosts I was deploying my upgrade to (I don’t recommend deploying to a vCenter server as you will be upgrading it and when the vCenter server goes offline, you will break your upgrade).
I also needed at least 1 free IP address as a staging IP address for the upgrade, in the same Subnet as the VCSAs that I will be upgrading.
Also, for my own sanity (and ALWAYS a best practice), I vmotioned all systems to a single host (in each region) and set DRS to manual (this stopped vCenter from trying to move my systems around). Once this was done, I connect to each ESXi host, powered down VCSA systems and took a snapshot. Once snapshot was complete, I powered the VMs back up again. Note, this was ONLY to the Platform Services Controllers and vCenter Server instances. Never take a snapshot of an Active Directory Domain Controller!
Not seen the image above is separate windows server, where I installed VMware Update Manager (VUM), this is the server where we will do the install process from. The reason for this is that we need to migrate VUM from a windows server to the embedded VUM, which is included in the 6.5 upgrade.
The migration assistant is required and VCSA will not deploy with out it.
A little something to note, I highly recommend, if you have a large environment like mine, you do this in the shortest possible window. Tackle all Platform Services Controllers FIRST, and THEN begin on the vCenter Servers
This was a fantastic series! Thank you for the detail and full context of the steps for a project of this sort.
One thing I ran into is when the stage 1 deployment created the new VCSA VM. It was unable to set some VM property, but had no idea which one. It went through and completed Stage 1 but it failed moving to Stage 2 because the migration couldn’t contact the new VCSA. The issue was that the vNIC was not set as connected.
What was nice is that the migration application gave me the appliance link where I could manually kick off the Stage 2 portion of the migration. It worked without issue and was a mirror of what the migration would have presented. In fact, it worked a lot faster through the browser.
I am glad you found this post useful. Let me know if there is anything else you are interested in me blogging about.