Where to find the VCF 9.1 offline depot metadata (when you don't have an activation code for automated download)
vcf-9.1.0.0100-offline-depot-metadata.zip is on the Broadcom Support Portal under VCF Installer 9.1.0, not 9.1.0.400.
vcf-9.1.0.0100-offline-depot-metadata.zip is published on the Broadcom Support Portal under VCF Installer 9.1.0. Not under 9.1.0.400.
The dead end you’re probably coming from is that it’s not intuitive to find the metadata file which is needed if you are building the offline depot by hand (or your agent is doing it for you). Homelabbers usually don’t have the codes to do automated downloads.
In the portal, when you pick VCF 9.1 and naturally go to the latest build (at the time of writing that’s 9.1.0.0400, but with the speed of updates lately, tomorrow it will be another build), the file when you look for it is not there. For me the metadata ZIP was published at 9.1.0.0100, and no 0400 equivalent was ever released.
The metadata defines the bill of materials. Its signed catalog names every artifact by exact filename and build, and VCF Installer requests those filenames and nothing else. If you pull binaries at version 0400, or any version that does not match what the BOM asks for, against a catalog pinned to 0100, the Installer asks for files that aren’t there and 404s, while the newer version of the same component sits untouched in the same folder.
The rule: get the metadata ZIP first, read the build number out of it, then select that exact build explicitly for every binary. Do not accept the portal’s default. A depot mixing 0200 and 0400 files is not a valid BOM no matter how new the files are.
Why did 0400 ship without a matching metadata bundle? That part isn’t documented, and I don’t know the real answer. A plausible guess is that release cadence has picked up and the metadata bundle publishes on its own schedule, separate from binary drops. That’s a guess, treat it as one. What’s verified is the observable part: 0100 has the ZIP, 0400 does not, and the catalog is enforced against whatever build it names.
The metadata ZIP holds the signed productVersionCatalog.sig, vcfManifest.json, compatibility data, and the vSAN HCL. Broadcom’s docs are accurate on this point: copying individual bundle files into a folder will not work. The signature is what makes the catalog trustworthy to the Installer, and it can’t be fabricated by hand.
Setting it up
- Extract the metadata ZIP into your depot root.
- Create the
PROD/COMP/*component folders it expects. - Serve the depot root over plain HTTP with autoindex on.
- Register it against the Installer:
PUT /v1/system/settings/depot
{"isOfflineDepot":true,"url":"http://your-depot-host:port"}
A successful response returns 202 with DEPOT_CONNECTION_SUCCESSFUL.
This is API-only. The Installer UI rejects http:// URLs outright, even though the API accepts and uses them without complaint.
I published a conclusion earlier saying this was blocked on a Broadcom tenant association. That was wrong, and the reason was that I was looking under the wrong product version. More on how that lab actually got built in I Let Claude Code Deploy My VCF 9.1 Home Lab, and This Is What Happened.