WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / Uncategorized / How to host your own simple ESXi update depot?

How to host your own simple ESXi update depot?

07.08.2022 by William Lam // 5 Comments

I recently upgraded my single ESXi host, which is used for my personal vSphere Homelab, to the latest patch release of ESXi 7.0 Update 3e using ESXCLI and connecting directly to VMware's online depot.

I still love how easy it is to update a single ESXi host using ESXCLI and using VMware's Patch Repo -

ESXI_VERSION=ESXi-7.0U3e-19898904-standard

"esxcli software profile update -d https://t.co/cs4yUyvnxQ -p ${ESXI_VERSION}"https://t.co/77Iu0K0hUG pic.twitter.com/nLhx5ztmNa

— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) July 7, 2022

This is the same method that I have been using since 2012 when I first wrote about this in a blog post using a pretty cool method of upgrading/patching a single ESXi hosts. If you are fortunate to have multiple ESXi hosts and a vCenter Server, you definitely should be using vSphere Lifecycle Manager (vLCM) provided by vCenter Server rather than the ESXCLI method, especially as there are no upgrade pre-checks built into in compared to vLCM.

Although my environment has a vCenter Server, I can not use vLCM because I only have a single ESXi host and ESXCLI method is really the only viable option. Customers may have a simliar setup, whether that is for a homelab, smaller environment or simply do not have a vCenter Server. Using the ESXCLI workflow, it certainly is the easiest if your ESXi host can reach VMware's online repo which is hosted at hostupdate.vmware.com, however this may not be possible for everyone, especially for remote locations where connectivity may be spotty or simply is not allowed to have outbound connectivity.

For such environments, you might be interested in hosting your own ESXi update repo and as always, I was curious on how one could setup something simliar without much effort and well, here we are with this blog post 😀

VMware does provide an official tool in building your ESXi depot using the VMware Update Manager Download Service (UMDS), which can be installed on a supported Linux distribution and I have even demonstrated how to do this using Docker Container. One thing that I found limiting with the UMDS tool is that it does not provide a means to limit the specific ESXi version and updates and forces you to download a ton more packages which may or may not be needed.

I was interested in exploring a more simpler way of building my own ESXi depot where I can selectively pick the ESXi versions that I would download from VMware download and/or patch website here and here.

Step 1 - You need access to a webserver (HTTP or HTTPS) to host the desired ESXi update and patch files. If you do not have one, you can easily spin one up using VMware's Photon OS or any OS distribution that you are comfortable with. In root of your webserver, create a new folder which will house all your ESXi files. In the example below, I will be using vmw but you can choose any other name, but just make a note of it as we will need to update the index file with the name you choose here.

Step 2 - Download the desired ESXi releases and/or patch updates in their offline bundle format (.zip) from here and here and then transfer them to your webserver.


Step 3 - In root of your webserver, create an index.xml file that contains the following and ensure that you update the patchUrl parameter with the desired folder name you had created in Step 1. This file simply points ESXCLI to the directory that contains index file for all available ESXi releases.

<vmwdpm:vendorList
    xmlns:vmwdpm="http://www.vmware.com/depotmanagement"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/depotmanagement ../../depot-index-xml.xsd">
    <vendor>
        <name>vmware, inc.</name>
        <code>vmw</code>
        <indexfile>index.xml</indexfile>
        <patchUrl>vmw</patchUrl>
        <relativePath>vmw</relativePath>
        <content>
            <name>VMware ESX</name>
            <type>http://www.vmware.com/depotmanagement/esx</type>
        </content>
    </vendor>
</vmwdpm:vendorList>

Step 4 - Extract the individual ESXi offline bundle zip files into their own unique directory that should be then placed into patch directory you had created earlier in Step 1. In my example, I have downloaded ESXi 7.0 Update 3a, 3b, 3c, 3d and 3e which will map to the following folder structure esxi-7.0u3a, esxi-7.0u3b, esxi-7.0u3c, esxi-7.0u3d and esxi-7.0u3e

Here is the command to unzip an ESXi offline bundle into the desired folder name:

unzip VMware-ESXi-7.0U3e-19898904-depot.zip -d /etc/httpd/html/vmw/esxi-70u3e

Step 5 - Within the folder (vmw) that houses all the ESXi update files, you will need to create another index.xml file which points to the individual ESXi releases. You will need to specify the relative path to .zip file that is located within the extract ESXi offline bundle.

For example, the ESXi 7.0 Update 3e offline bundle contains the following 4 files:

We then need to add an XML entry that points to esxi-70u3e/vmw-ESXi-7.0.3-metadata.zip file. You will need to do this for each ESXi release that you wish to host and for earlier releases, the .zip file maybe named differently and you should inspect the contents before creating the XML entry.

Here is the complete index.xml for hosting all five ESXi 7.0 Update 3 releases:

<metaList>
    <metadata>
        <productId>embeddedEsx</productId>
        <version>7.0.3</version>
        <locale />
        <url>esxi-70u3a/vmw-ESXi-7.0.3-metadata.zip</url>
        <channelName>default</channelName>
    </metadata>
    <metadata>
        <productId>embeddedEsx</productId>
        <version>7.0.3</version>
        <locale />
        <url>esxi-70u3b/vmw-ESXi-7.0.3-metadata.zip</url>
        <channelName>default</channelName>
    </metadata>
    <metadata>
        <productId>embeddedEsx</productId>
        <version>7.0.3</version>
        <locale />
        <url>esxi-70u3c/vmw-ESXi-7.0.3-metadata.zip</url>
        <channelName>default</channelName>
    </metadata>
    <metadata>
        <productId>embeddedEsx</productId>
        <version>7.0.3</version>
        <locale />
        <url>esxi-70u3d/vmw-ESXi-7.0.3-metadata.zip</url>
        <channelName>default</channelName>
    </metadata>
    <metadata>
        <productId>embeddedEsx</productId>
        <version>7.0.3</version>
        <locale />
        <url>esxi-70u3e/vmw-ESXi-7.0.3-metadata.zip</url>
        <channelName>default</channelName>
    </metadata>
</metaList>

Here is what the final directory structure should look like if you followed my exact folder names:

Note: Make sure all files, directories(s) and their sub-directorie(s) have the correct permissions so they can be accessed over HTTP(s).

The final step is to verify that everything was setup and configured correctly by using an ESXi host (Nested ESXi Appliance is recommended for ease of testing and patching purposes) to probe our depot and pointing the initial index.xml located at the root of your webserver (e.g. http://patch.primp-industries.local/index.xml)

esxcli software sources profile list -d http://patch.primp-industries.local/index.xml


If everything was configured correctly, we should see the list of ESXi releases that we have added to our webserver that can now be used to patch and update your ESXi host(s)!

More from my site

  • How to Enable Nested ESXi & Other Hypervisors in vCloud Director 5.1
  • ESXi on SolidRun V3000
  • Duplicate MAC Address concerns with xVC-vMotion in vSphere 6.0
  • virtuallyGhetto gets a bit less ghetto ...
  • How to increase capacity of /var/log on vMA 4.1

Categories // Uncategorized

Comments

  1. *protectedAndré Pett says

    07/08/2022 at 1:42 pm

    >>> ... because I only have a single ESXi host ...
    What would be interesting to know, is whether it is possible to stage patches using VUM or vLCM, then shut down the VMs (including vCenter), and start the remediation on the host itself.

    Reply
    • William Lam says

      07/08/2022 at 2:13 pm

      afaik, there's no way to stage using vLCM and you'd still run into issue where hosts is attempted to be placed in MM before patching can occur and the other issue is that VUM/vLCM will fail operation as it can't issue the actual update operation. This is something I've asked about and there's no creative solution and ESXCLI method is the recommended approach

      Reply
      • *protectedMark says

        08/15/2023 at 7:20 am

        I've been running the command below for about a year and just changing the image file name. Today is the first time the command failed. Any idea why?

        [root@esxihost:~] esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-8.0U1c-22088125-standard
        [NoMatchError]
        No image profile found with name 'ESXi-8.0U1c-22088125-standard'
        id = ESXi-8.0U1c-22088125-standard
        Please refer to the log file for more details.

        Reply
  2. *protectedNirav says

    08/17/2022 at 7:41 am

    Hello,
    I've tried to replicate your set up. But, I am getting below error when I tried to sync updates using vLCM.

    """A general system error occurred: Download patch definitions task failed while syncing depots. Error: 'integrity.fault.MetadataDownloadFailure'. """

    If I put info about only one bundle [one metadata node] in second index.xml file, it works fine. But, If i put more than one metadata nodes, it gives above error.

    Also, the command "esxcli software sources profile list -d http://my-wevserver-ip/index.xml" returns nothing. It succeeds but returns nothing.

    Reply
    • *protectedCesar Caminero says

      03/26/2024 at 8:44 am

      I'd make sure that the contents of the XML files are pointing to the correct names/path for other XML files. In my case, to make it less complicated, I renamed the (/hostupdate/)__hostupdate20-consolidated-index.xml file to vendor-index.xml, and the (/hostupdate/vmw/)__hostupdate-consolidated-metadate-index.xml to metadata-index.xml. Then updated those names on each XML file. And instead of creating the new XML file inside the "vmw" directory as William suggested, I just updated the existing "metadata-index.xml" file with the metaList entries. That cleared that error for me.

      My tree looks like this:
      - hostupdate/
      - vmw/
      -vendor-index.xml
      - version.xml
      - /vmw/
      - esxi-70u3i/
      - metadata-index.xml
      - /esxi-70u3i/
      - vib20/
      - index.xml
      - vendor-index.xml
      - vmw-ESXi-7.0.3-metadata.zip

      I hope this helps others.

      Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...