Quick Fix – VCSA Can’t Update via URL from Management Interface

I had an issue with my VCSA today trying to upgrade to vCenter 6.7 Update 1 whereby the Management Interface Upgrade option was not detecting the update to upgrade the appliance to 6.7 Update 1. It was a similar issue to this VMwareKB, however the URL that is mentioned in that instance was already in the VCSA Settings.

My first instinct was to check the disk space and see if there where any pressures in that area. I did find that the /dev/sda3 partition was low on space, so I expanded the disk following advice given by Mark Ukotic. After a reboot and resize I had plenty of storage left, but still couldn’t trigger an update from the URL. At this point I did download the Update patch ISO from the VMware Patch center and loaded it up manually…however the issue of it not popping up automatically was annoying me.

As mentioned, the settings of the VCSA Update window has the following URL listed:


Having asked around a little the quick fix was provided by Matt Allford who provided me with the URL that was present in his VCSA after he upgraded successfully via the CLI.


I added that as a custom repository as shown below…

I was then able to rescan and choose from the list of updates for the VCSA.

And perform the upgrade from the Management Interface as first desired.

Interestingly enough, after the upgrade the default Update Repository was set to the one Matt provided for me.This is the first time i’ve seen this behavior from the VCSA but I had reports of people being able to upgrade without issue. I’m wondering if it might be the particular build I was on, though that in it’s self was not picking up any patches to update to either. If anyone has any ideas, feel free to comment below.

One thought on “Quick Fix – VCSA Can’t Update via URL from Management Interface

  1. In my experience this behavior is not a new thing at all. I had similar issue in the past with v6.5 several times while making minor release upgrades and most of the time I just had to copy the default repository URL to the custom repository fields. Except for one time where I had issues with the VCS instance this workaround seemed to work all the time, so my suspicion is that there is an unraveled bug somewhere in the product. Also another interesting thing on my end was that this behavior with the default repository seems to be pretty inconsistent across different deployments. For example I never had issue with the detection on PSC instances but I’ve encountered the problem on VCS deployments (with external PSC’s) many times. Two days ago I noticed also that when I initially checked the default repository on my v6.7 PSC and VCS instances I was able to see the new version listed and I engaged a Stage Only operation. Couple of hours later when I wanted to do the actual upgrades I was not able to see the update on the VCS anymore, but when I switched to the custom repository trick, then the update appeared again and it also detected that the stage operation was completed successfully. On the v6.7 PSC instance I didn’t have to apply any workarounds, so I kinda get the feeling that there might be a relationship around the VCS product when it comes to updating from the default repository.

Leave a Reply

Your email address will not be published. Required fields are marked *

WordPress Appliance - Powered by TurnKey Linux