How to get vCenter updates through a proxy using the Appliance MUI (or VAMI)

In yesterday’s post, I updated my VCSA 6.0 appliance to version 6.5.  Today, logged into the Appliance MUI and noticed that my appliance was not able to check for updates using the default web repository.

Before we really start, a quick note on terminology.  The Appliance MUI (which means Appliance Management UI) is the new name for the old VAMI (vSphere Appliance Management Interface).  The MUI is a HTML5 web interface for configuring basic and low-level settings for the VCSA.  It’s accessible by connecting to your VCSA on port 5480.

So, what’s the deal?  Well, when browsing to the update section of the MUI and checking for updates, I would receive the following error:

how-to-get-vcenter-updates-working-through-the-appliance-mui-using-a-proxy-img01

My proxy config was the first thing I checked.  You can check the proxy in the MUI under Networking > Manage > Proxy settings.  Sure enough, my config was correct for my environment.

how-to-get-vcenter-updates-working-through-the-appliance-mui-using-a-proxy-img02

I also knew that my proxy was working correctly and was contactable by my VCSA, because I was able to use the proxy for the VCSA 6.5’s integrated update manager to communicate with the default web-based patch repositories.

I did a web search and came across an awesome post which contained the solution, written by a vExpert named Mario.  Full credit to him – the solution to this problem is his and not mine.  I encourage you to check out his blog.

So, it turns out that when you configure a proxy via the MUI, it only configures the proxy as a HTTP proxy.  As Mario points out (as does the GUI in the screenshot above – if you’re paying attention), the update repository is a HTTPS address, so the proxy configured via the MUI won’t apply.  Why doesn’t the proxy you configure apply to both HTTP and HTTPS connections, I hear you ask?  I haven’t got a clue.

The solution is surprisingly simple, once you’ve got some instructions and know where to look (which I didn’t).  Simply edit the /etc/sysconfig/proxy file via SSH or WinSCP (which is the option I took), and manually configure the HTTPS proxy – taking care, obviously, to adjust the URL from HTTP to HTTPS (highlighted).

how-to-get-vcenter-updates-working-through-the-appliance-mui-using-a-proxy-img03

After saving the changes, return to the updates section of the MUI and try checking for updates again.  Boom!  Thanks, Mario!

how-to-get-vcenter-updates-working-through-the-appliance-mui-using-a-proxy-img04

Edit: As of the 23rd October 2017, I’ve been notified in a comment below by Stijn that a bug exists with vSAN 6.6 as documented in VMware KB 2150523 where the configuration of any proxy, even through the GUI, will break the vSAN management service.  I would suggest unconfiguring the proxy on all of your vCenter Servers which are managing vSAN 6.6 clusters until this bug is resolved.  Thanks Stijn for pointing this out!

  • Hi Andrew,
    nice to hear that my post helped you.

    I´m supprised that this issue seems to be not resolved in vSphere 6.5, as this is a setting I assume some more people need in their infrastructure and I would guess some support tickets have been already raised in vSphere 6.0 🙂

    Cheers,
    Mario

    • Hi Mario, thanks for stopping by!

      I agree, it’s surprising the issue is still unresolved in 6.5 You’d think that it would be a relatively minor code change to make the MUI update both lines in the proxy config.

      Cheers,
      Andrew

  • one

    Thanks a lot for sharing!
    Almost went insane…
    Seems like there is too much Dev and too little Ops at VMware at the moment. :/

  • Fredrik Holm

    Thank you for adressing this issue and linking to the solution for it.
    This is just one of many issues I have been having with 6.5, so I am not very impressed with it so far

  • Enrique

    Great!
    THX!!!!

  • Stijn

    WARNING: everybody should know that this workaround breaks vSAN communication !!! There is a KB from VMWare and no bugfix at the time of writing. Please be careful when doing this.

    https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2150523

    • Hey Stijn,

      Looking at the KB article, it’s actually not the workaround itself which breaks the vSAN management service. Configuring a proxy via the GUI already sets the HTTP_PROXY variable mentioned in the KB, so ultimately this bug will affect anyone who is using vSAN 6.6 and has any proxy configured at all.

      However, I’ll add a note to the bottom of this blog post just to make people aware of this bug. Thanks for your comment!

      Cheers,

      Andrew

    • Andrew Richardson

      Hey Stijn,

      Looking at the KB article, it’s actually not the workaround itself which breaks the vSAN management service. Configuring a proxy via the GUI already sets the HTTP_PROXY variable mentioned in the KB, so ultimately this bug will affect anyone who is using vSAN 6.6 and has any proxy configured at all.

      However, I’ll add a note to the bottom of this blog post just to make people aware of this bug. Thanks for your comment!

      Cheers,

      Andrew

  • Chris

    I completed this on our VCSA. It allowed the update to be checked through the VAMI. However as traffic to the proxy isn’t allowed to be back to an internal systems (in this case the external psc) the vmonapi service fails to start. This results in the vapi endpoint alarm, and VCSA updates failing.
    The failure is the vmon service checks for SSO SSL and that connection fails due to the trip to the proxy.

    So ensure that your proxy allows communication back to internal systems prior to completing.

    • Andrew Richardson

      Hi Chris,

      If I understand you correctly, you’re saying that HTTPS connections from VCSA to PSC were failing because traffic was going to the proxy, and the proxy wasn’t allowing it back to the PSC? That’s interesting, and also a fairly big problem with this process. I might put a note at the top of this post warning people not to use this workaround in a production environment, which unfortunately means updates will have to be applied via another method (like downloading the patch iso and attaching it to the VM).

      Thanks for your feedback!

      Andrew