I recently upgraded from VCSA 6.0 to VCSA 6.5 and hit a few gotchas along the way — especially with the newly supported Mac installer. Read on to learn more!
UPDATE: This blog post is getting some attention. I just wanted to add my definition of “gotcha%#8221;: anything that does not work as expected (solution may be to read the documentation, perform some workaround, or wait for a fix).
Gotcha #1: No need to manually install VMware OVFTool 4.2
The UI installer requires and includes VMware OVFTool 4.2. Even if you install VMware OVFTool 4.2 manually, the installer will NOT leverage it. You will understand why this is important in a minute.
Gotcha #2: The installer for MacOS Sierra does not appear to work
Yes, you read that right — at least it did not work for me. With that said, it is not listed as officially supported. Here is what I experienced:
- Open CDROM > vcsa-ui-installer > mac > Installer
- Complete steps 1 through 5
- Hit an error on step 6
Based on the message, I thought I might have a corrupt OVA file, however the download was an ISO and the ISO mounted without issue. To start troubleshooting, I selected the “Show all%#8221; button:
OK, now it sounds like a problem with ovftool. This made me believe I needed to install ovftool manually and then rerun the installer. After do this, I hit the same issue, which resulted in Gotcha #1. Long story short, no need to install ovftool manually. Next step is to check the “Installer log%#8221; so I hovered over the link:
Well, that is kind of ugly, but I assume that is the path of the log file. If you click on what is left of “Installer log%#8221; then you can download the log file:
Next, I opened the log file and scrolled to the bottom of the log file to find:
2016-11-16T23:54:19.360Z - error: could not find ovftoolCmd: /private/var/folders/68/_76kyyfs18l4gd4qrj1hvtp80000gn/T/AppTranslocation/vcsa/ovftool/mac/ovftool
2016-11-16T23:54:19.360Z - info: ovftoolCmd: null
2016-11-16T23:54:19.360Z - error: OVF probe error: Error: ovftool is not available
Well, that is interesting. I was expecting the installer to look for ovftool in the /Applications directory, but instead it is a private path. Next, I decided to check the directory reporting the error. I made it to:
before I could go no further. The “vcsa%#8221; directory did not exist! Well, that is a problem. To fix the problem, I decided to create the missing directories and then create a link to ovftool in my /Applications directory. I restarted the installer and hit the same issue:
When I expanded the error this time though I noticed the message had changed:
OK, so it appears ovftool was found, but the OVA was not. I also took a look at the updated installer log, which confirmed the issue:
2016-11-16T18:25:05.769Z - error: Could not find ovaFile /^VMware-vCenter-Server-Appliance-.*_OVF10.ova$/ in /private/var/folders/68/_76kyyfs18l4gd4qrj1hvtp80000gn/T/AppTranslocation/vcsa
2016-11-16T18:25:05.769Z - info: ovaFile: null
2016-11-16T18:25:05.770Z - error: OVF probe error: Error: OVA file is not available
This lead me back to the ISO and the directory structure:
Well look at that — the “vcsa%#8221; directory in the ISO contains both ovftool and the OVA! I copied over the OVA and the installer worked as expected. So long story short:
- Refer to Gotcha #1
- You need to manually copy the “vcsa%#8221; directory in the ISO to the private path in the installer log to make the MacOS installer work on Sierra
Gotcha #3: Upgrade PSC before VCSA
This is nothing new, but I figured I would cover it anyway. If you have an external PSC then you need to upgrade it BEFORE you upgrade VCSA. If you do not, you will not be able to complete the second part of the VCSA upgrade, but can upgrade PSC and then return to the second part of the VCSA upgrade by going to https://<newVCSA>:5480.
Also, as a FYI, to upgrade an external PSC or VCSA, you need:
- The credentials to the existing PSC/VCSA (UI + CLI)
- The source ESXi host (CLI)
- The destination ESXi host (CLI)
- A temporary IP for this new PSC/VCSA (used until the migration is complete)
FEATURE REQUEST: The installer should check for this and report back to the user beforehand.
Gotcha #4: The INITIAL SSO username matters
Again, nothing specific to 6.5, but pay special attention to the SSO user name if you are not using the default vsphere.local domain. If you forgot to change the domain you will receive an error about authentication:
However, if you edit the SSO user name after using an incorrect one without closing the installer then the new PSC/VCSA will get deployed — which takes about 20 minutes — but you will not be able to configure the PSC/VCSA as it uses the first SSO user name you entered (i.e. [email protected]).
If you edit the SSO user name after using an incorrect one without closing the installer then you will not be able to configure the PSC/VCSA.
As I am sure you know, you cannot change the SSO domain after deployment so that means you need to power down the new PSC, delete the new PSC, close the installer, open a new installer, fill in all the information again, deploy another PSC, wait another 20 minutes, and sigh heavily (speaking from experience).
BUG: Hopefully this will be fixed in a future release.
The new Mac installer for VCSA is AWESOME! I am SO GLAD I no longer need Windows. Unfortunately, I had a couple snags, but it was straightforward to come up with a workaround. I think the installer in general could be a little simpler and more intuitive, but it is a huge leap forward from previous versions. Hats off to the vSphere team and looking forward the future (without Windows).
© 2016, Steve Flanders. All rights reserved.