In this post I would like to show you the process of updating a VCF deployment at a customer site to the current version which was released in mid december.
The pictures show only the update of the management workload domain, as that is the only one currently available there. If you have multiple VI/VDI workload domain still you have to update the management domain first, and then individual workload domains.
The steps necessary are the same as in previous updates. E.g. if you are located at an environment isolated from the internet you can use a laptop to download the bundle files based on a delta file provided by the SDDC manager and import these afterwards, as described in one of my previous posts.
The update itself can be scheduled or started immediately. The process is the same as before, but consists of multiple phases.
The first phase updates the VCF services itself, including domain manager, SDDC manager UI and LCM:
Afterwards the NSX components are updated to version 6.4.4 as shown in below screenshot:
In the next phase the platform service controllers (for the management domain typically two) and the vCenter are updated to version 6.7. Sadly in the first release of the VCF 3.5 update bundles there was a but resulting in an error in the stage “vCenter upgrade create input spec”:
The SDDC manager�s log file “/var/log/vmware/vcf/lcm/lcm-debug.log” only showed a “java.lang.NullPointerException”
error at the component “com.vmware.evo.sddc.lcm.orch.PrimitiveService“, which didn’t help me much, so after a unlucky Google search I contacted VMware�s support. Upon opening a support case on my.vmware.com a very friendly Senior Technical Support Engineer got back to me within minutes and pointed my attention to this knowledge base article. Apparently the issue cannot be fixed in place, but a new update bundle is available replacing the buggy one. If your SDDC manager has internet access it can download the bundle automatically, but if you are at a “dark site” you first need to get rid of the faulty bundle�s id by running the following python script:
/opt/vmware/vcf/lcm/lcm-app/bin/bundle_cleanup.py 0864d5b4-2901-4198-83b8-457985af2ff8
Afterwards a new marker file has to be created and transferred to a workstation with internet access where the updated bundles are downloaded: (same procedure as described before)
This screen shows the new successful import of the previously downloaded bundles after copying it back to the SDDC manager:
Finally we can retry the phase 3. As you can see here a new screen appears now:
As vCenter appliances can not be upgraded from 6.5 to 6.7 directly a new appliance has to be deployed which then imports all settings from the old one. To be able to complete this process the SDDC manager needs a temporary IP address for that new appliance in the same range as the vCenter/PSC:
Check the review screen to confirm the temporary IP settings and hit “Finish” to start the update:
Hooray! The update process did not fail at the stage it did before:
After a little more than an hour all three appliances are up-to-date:
As we can see in the overview screen of the domain all components are updated, except for the ESXi hosts:
This means the fourth and final phase can be started: the update of the ESXi hosts to build 1076412:
This concludes the update to VCF 3.5 as all components now have the current build numbers:
The next screenshot of the Update history section shows the update from 3.0.1 to 3.0.1.1 and the four updates from above:
