Next, mount the ISO and start the installer UI. The UI presents the already known options: install, upgrade, migrate, restore. My target is to upgrade existing lab environment so, I am choosing upgrade. Before going further into the post, I want to clarify the upgrade process. It is not an in place upgrade, it is actually a migration and you will end up with a new VM running vCSA 7.0 alongside the old vCSA 6.7.
I don't intend to describe the step by step upgrade since there are already a few good blog posts and the process itself is pretty straight forward. I will however highlight some things I came across during the upgrade.
- you will end up with 2 VMs - a powered off old vCSA 6.7 and a powered on vCSA 7.0
- vCSA 7.0 will preserve in the end FQDN and IP of vCSA 6.7
- a temporary IP address is required for vCSA 7.0 to be used during the data migration from vCSA 6.7 (that moment in time when both VMs are up and running)
- it's a 2 stage process: first a new vCSA VM is deployed, then the data is migrated
- migration offers possibility to chose how much data you actually want transferred (the more you choose, the longer it takes)
- configuration and inventory
- configuration, inventory, tasks and events
- configuration, inventory, tasks, events and performance metrics
- the whole process took almost 2 hours (my lab), expect bigger times for real environments
During the upgrade itself I got a couple of warning at pre-check and a couple of notifications at the end for the rest being smooth and uneventful. The warning was about not having DRS enabled on my cluster, which was fine because I had a single node cluster where vCSA was running:
The notifications is about TLS 1.0 and 1.1 being disabled and Auto-Deploy needing an update:
I did try to upgrade using CLI installer, however there are some issues with the upgrade templates and its schema in the GA version (15843807) and it kept on failing during JSON template precheck. I will come back to this topic once I figure it out.
No comments:
Post a Comment