When the Installer Sees Zero Disks: Building a Custom ESXi ISO for HPE Synergy SAN Boot

By /

A federal services integrator’s proof-of-concept upgrade hit a wall that stops more HPE Synergy deployments than people admit: boot the generic ESXi installer on a SAN-boot blade and it shows zero storage devices. No boot LUN, no install target, no way forward. The fix is a custom ISO that merges the VMware base image with HPE’s Synergy driver AddOn — and as of early 2026, building it yourself is no longer optional.

The Challenge

The customer was standing up a proof-of-concept to validate an ESXi 9.0.2 upgrade on HPE Synergy compute modules. The blades boot from SAN — the ESXi install target is a Fibre Channel LUN, not local disk. This is still extremely common in enterprise and federal environments, where centralized SAN storage is the standard and stateless-ish compute is the design goal.

They downloaded the generic VMware ESXi 9.0.2 ISO from the Broadcom portal, mounted it, booted a blade, and got to the installer’s disk-selection screen — which showed nothing. No storage devices. The boot LUN that the blade could see from its HBA firmware was completely invisible to the ESXi installer.

This is the classic Synergy SAN-boot trap. The generic VMware base ISO doesn’t include the Fibre Channel and storage drivers that HPE Synergy blades need — the QLogic native FC driver, the QLogic converged network adapter driver, the QLogic FCoE driver. Without those drivers loaded in the installer environment, ESXi can’t talk to the HBA, can’t see the SAN, and can’t find the boot LUN.

Historically, the answer was simple: download HPE’s pre-built “Synergy Custom” ESXi ISO, which bundled all those drivers. But the customer hit two compounding problems:

HPE hadn’t published a Synergy custom ISO for ESXi 9.0.2. The base patch they needed existed on the Broadcom portal, but no matching pre-built HPE image was available for that exact build yet.

And the pre-built images were going away entirely. This is the part that turns a one-off workaround into a permanent skill. Beginning with HPE Synergy Service Pack (SSP) version 2026.01.xx, HPE no longer creates or releases Synergy Custom ESXi Images or Certified Vendor Add-ons (HPE Customer Notice a00156316). The official guidance going forward: take the VMware base image and combine it with HPE drivers and management software yourself.

So the customer wasn’t just blocked on one patch level. They were standing at the front edge of the new reality where building the custom ISO is the supported path, not a stopgap.

The Journey: From Generic ISO to Driver-Complete Image

Understanding what was actually missing

The first step was confirming the diagnosis. Booting the generic ISO and dropping into the installer’s shell, the storage adapter list came back empty of FC adapters. The HBA hardware was present and the blade’s own boot firmware could see the LUN — this was purely a driver gap in the ESXi installer environment.

The HPE Synergy AddOn depot contains the missing pieces, and notably they’re not all “HPE” drivers. The AddOn bundles VIBs from multiple silicon vendors: QLogic FC/FCoE drivers (qcnic, qedf, qedi), the Marvell/QLogic native FC driver (qlnativefc), Broadcom NetXtreme and storage drivers (bnxtnet, storcli, lsi-mr3), Microsemi Smart Storage drivers (smartpqi, ssacli2), Intel network drivers, and HPE’s own management stack (amsd, ilo, ilorest, sut). The FC drivers were the load-bearing ones for this SAN-boot scenario — without qlnativefc and the QLogic converged adapter drivers, the boot LUN stays invisible.

Choosing the build approach

VMware’s PowerCLI ships an Image Builder module that can combine an offline base depot with an AddOn depot and emit an installable ISO. This is the same mechanism HPE used internally to produce their custom images — it just needed to be driven manually.

The required inputs were two depot zips: the VMware base ESXi 9.0.2 offline depot from the Broadcom patches portal, and the HPE Synergy AddOn depot from the HPE support portal. Both require valid entitlement to download. The HPE AddOn from the 9.0.0 release was compatible with the 9.0.2 base — per HPE’s documentation, an AddOn combines with a newer base patch within the same release family, provided the patch doesn’t cross a release boundary. (Note the boundary rule changed at 9.0: for ESXi 8.0 and older, the line is a VMware “update” release like 8.0 U2 to 8.0 U3; for 9.0 and newer, it’s a VMware “minor” release. A 9.0.2-validated AddOn on a 9.1 base would cross that minor boundary and is a different, riskier scenario — see the field update below.)

The build, and the things that went wrong

The build procedure looks simple on paper: query the base image version, query the AddOn details, write a small JSON software spec, run New-IsoImage. In practice, three specific failures ate most of the troubleshooting time, and all three are the kind of thing you only learn by hitting them.

The JSON spec needs UTF-8 without a byte-order mark. PowerShell’s Out-File and Set-Content both add a BOM by default. New-IsoImage reads the spec, chokes on the BOM, and fails with a parse error that gives no hint that encoding is the problem. The fix is to write the file with [System.IO.File]::WriteAllText, which doesn’t add a BOM. This one cost an hour of staring at a “malformed spec” error on a spec that looked perfectly valid.

PowerCLI resolves relative paths from the user profile directory, not the current working directory. Point it at .\depot.zip from a working directory full of depots and it goes looking in your home folder instead, then reports the file missing. The fix is to resolve every path to absolute before passing it to the cmdlets.

The acceptance-level error. HPE’s VIBs are partner-signed, not VMware-certified. By default New-IsoImage enforces a certification level that the HPE drivers don’t meet, and it refuses to build. Passing -AcceptanceLevel PartnerSupported tells it to accept partner-signed VIBs, which is correct and expected for vendor driver bundles.

With those three resolved, the build produced a roughly 700 MB ISO combining the 9.0.2 base with the full HPE Synergy driver set.

Validating before deploying

The worst failure mode with a merged image isn’t a build error — it’s a silent partial merge. The ISO builds successfully but is missing one driver, you deploy it, and the blade still can’t see its LUN. Now you’re debugging a “the custom ISO didn’t work” problem on a host that won’t boot, instead of catching it on the workstation where you built it.

So the build step is followed by a validation step: load both source depots back into a PowerCLI session, enumerate every VIB in the HPE AddOn, and confirm each one is present in the combined image. All of the AddOn’s VIBs should report present. Any missing VIB means the merge dropped something and the ISO shouldn’t be deployed. This pre-deploy check turns a “why won’t this host boot” mystery into a green/red checklist you run before ever touching a blade.

After install, a second validation runs on the ESXi host itself: an esxcli software vib list filtered for the expected driver names, plus a storage adapter enumeration to confirm the boot LUN is now visible. Two checkpoints — one before deploy, one after — and the SAN-boot host comes up clean.

The Results

The custom ISO booted on the Synergy blades, the installer saw the SAN boot LUN, and the ESXi 9.0.2 proof-of-concept proceeded. More durably, the customer walked away with a repeatable build process rather than a one-time fix.

The immediate unblock. The POC upgrade that was completely stalled — no install target, no path forward — proceeded the same day the custom ISO was built and validated.

A repeatable process, not a one-off. Because HPE is retiring pre-built Synergy custom ISOs, every future ESXi patch on these blades will need the same combine. The customer now has the scripts and the documented procedure to do it themselves, every time, without waiting on an HPE image that may never come.

Validation built into the workflow. The pre-deploy VIB-merge check and the post-install driver check mean the team finds problems on the build workstation, not on a blade that won’t boot. That’s the difference between a five-minute rebuild and a multi-hour outage investigation.

Knowledge that outlives the engagement. The gotchas — the BOM, the path resolution, the acceptance level, the FC-driver-version caution — are documented. The next engineer doesn’t rediscover them the hard way.

Lessons Learned

The generic ISO will never work for SAN-boot Synergy, and now you build the fix yourself. This used to be “download HPE’s custom image.” As of SSP 2026.01.xx it’s “build the custom image.” Anyone running ESXi on HPE Synergy boot-from-SAN should treat custom-ISO-building as a core skill now, not a rare workaround.

Base64 isn’t the only encoding gotcha — BOMs bite too. The UTF-8 BOM problem is the exact same class of issue as the password-encoding problem in other integrations: data crosses a boundary between tools and one side adds invisible bytes the other side can’t parse. When a file “looks fine” but a tool rejects it, check the encoding and the BOM before anything else.

Validate the merge before you deploy, not after. A silent partial merge is the failure that costs the most time, because the symptom (host can’t see its LUN) looks identical to the original problem you were trying to solve. Confirming every AddOn VIB made it into the image — on the workstation, before deploy — eliminates an entire category of confusing field failures.

FC driver versions are load-bearing for SAN boot. HPE’s own release notes document a case on ESXi 7.0 U3 where a custom image revision shipped an updated lpfc driver that dropped support for a specific FC HBA, causing loss of LUN access and a host that wouldn’t boot from SAN. The lesson generalizes: when you build a custom image for SAN-boot hosts, the FC driver version is not a detail. Test on one host, confirm the boot LUN survives a reboot, then go fleet-wide.

Read the deprecation notices. The whole reason this became a “build it yourself” exercise is a Customer Notice most people never read. Keeping an eye on vendor deprecation announcements — HPE Customer Notices, Broadcom KBs — is the difference between being ready for a change and being blindsided by it mid-engagement.

What We’d Do Differently

Wrap the whole thing in a single orchestration script earlier. The first build was done command-by-command, interactively, which is exactly how you discover the gotchas but not how you want to run it the tenth time. Packaging the query-spec-build-validate flow into parameterized scripts came after the manual run; doing it first would have made the repeat builds trivial from the start.

Build a depot-compatibility pre-check. The AddOn-to-base compatibility (same major version, no update-boundary crossing) was confirmed by reading HPE’s documentation. A script that reads both depots and warns if the versions look incompatible would catch mismatches before a 700 MB build that’s destined to produce an unsupported image.

Capture the post-install validation as a one-shot. The post-install driver check is a manual SSH-and-grep today. Folding it into a kickstart %firstboot script, or a small post-deploy automation, would make “did the drivers actually load” an automatic green light rather than a manual step someone might skip.

Getting Started

The tooling requires VMware PowerCLI (specifically the VMware.ImageBuilder module), Python 3.7–3.12 with a few modules (six, lxml, psutil, pyopenssl), and two depot zips you download yourself: the VMware base ESXi offline depot from the Broadcom patches portal, and the HPE Synergy AddOn offline depot from the HPE support portal. This repository does not redistribute either binary — you provide them with your own entitlement.

Clone the repository, install PowerCLI and point it at your Python executable, write the software spec with the BOM-free helper, run the build script, and run the validation script before deploying. The full walkthrough — including the dependency setup and every gotcha — is in the repository’s build guide.

Field Update: Where the Drivers Live Now, and the 9.0+ Boundary

Shortly after this was first written, a peer working the same problem on a different engagement raised two points worth folding in, because they sharpen exactly where “it builds” and “it’s supported” diverge.

The driver source is moving from the standalone AddOn to the SSP. This runbook uses the standalone HPE Synergy AddOn depot, which is the approach that works today. But HPE’s stated direction is that the supported components increasingly come bundled inside the HPE Synergy Service Pack (SSP) rather than as a separately downloadable AddOn. With HPE retiring the Synergy Custom Images and Certified Vendor Add-ons tooling (SSP 2026.01.02, Customer Notice a00156316), the long-term expectation is: take the VMware base image and apply HPE-supported drivers and utilities delivered through the SSP. Practically, that means future builds may involve extracting the relevant driver components from the SSP bundle rather than grabbing a tidy standalone AddOn zip. The Image Builder combine mechanics in this repo stay the same — what changes is where you source the driver VIBs.

The version-boundary rule is stricter on 9.0 and newer. For ESXi 8.0 and older, a VMware patch is supported on an HPE image as long as it doesn’t cross an “update” release (8.0 U2 to 8.0 U3). For ESXi 9.0 and newer, the line moved: the patch must not cross a “minor” release. That’s a meaningful tightening. Combining a 9.0.2-validated AddOn with a 9.0.2 base (this story’s scenario) stays comfortably inside one minor release and is fine. Combining a 9.0.2-validated AddOn with a 9.1 base crosses the minor boundary — the drivers were never validated against that base, and you’d be running an unsupported combination even though Image Builder will happily produce the ISO.

Validate the HCL before you trust the build. The right pre-flight when you’re near a boundary is to confirm the drivers in your AddOn actually match the hardware in your blades. Check the VID (vendor ID), DID (device ID), SVID (subsystem vendor ID), and SSID (subsystem ID) of your I/O devices — NICs and HBAs especially — against the driver set in the SSP or AddOn you’re about to merge. If a device’s IDs aren’t covered by the drivers in your image, that device won’t work regardless of what the build tool reports. This catches the “unsupported drivers on the wrong base” case before you’ve burned a deploy cycle on it. (One concrete example from HPE’s own 9.x notes: the Synergy 3830C 16Gb FC HBA is not supported on ESXi 9.x at all — exactly the kind of thing an HCL check surfaces before install, not after.)

The takeaway: the build mechanics in this repo are stable, but which drivers you feed in, and which base you target, are where the support boundary lives. Stay within a minor release, source drivers from the SSP/AddOn that matches, and validate the HCL by device ID when you’re near an edge.

Companion Tool: Getting the Drivers Out of the SPP

There’s a practical wrinkle in “source the drivers from the SPP.” The SPP is a single bundle of smart components for every operating system — ESXi, RHEL, SLES, Windows — plus firmware, and its content list has no column grouping components by OS release. So when you need just the ESXi 9.0 VIBs to feed into the build, you’re left doing spreadsheet archaeology against the SPP contents report, matching driver names and versions by hand.

That friction is its own small tool. A second open-source companion, spp-esxi-vib-extractor, does the grouping automatically: point it at an extracted SPP and it finds the ESXi-relevant VIBs (including the ones wrapped inside HPE smart components), determines which ESXi release each one targets, sorts them into per-release folders, and emits a manifest with the OS-release column the SPP report is missing. Its output drops straight into the build process described here.

It’s the front half of the workflow — extract and group the right drivers, then merge them with a VMware base depot into the ISO:

HPE SPP → spp-esxi-vib-extractor (group by release) → esxi-hpe-synergy-imagebuilder (merge into ISO) → custom ESXi ISO

Worth a note on how that tool got built, because it’s a small lesson in itself: the first version only recognized HPE’s OEM.900-style version tags. Run against a real SPP’s mix of HPE drivers and VMware base VIBs, it promptly dumped most of the VMware components into an “unknown” pile — because VMware uses a different version encoding (vmw.902) and the system VIBs carry a bare leading version with no tag at all. Testing against real binaries, not assumptions, is the only way that surfaces. The fix was straightforward once the real formats were visible; the point is that “it worked on my synthetic test” and “it works on a real SPP” are different claims, and only the second one counts.

Conclusion

The HPE Synergy SAN-boot “zero disks” problem has a clean solution: a custom ESXi ISO that merges the VMware base image with HPE’s Synergy driver AddOn. What changed in early 2026 is that building that ISO is now the supported, expected path rather than a stopgap — HPE has retired the pre-built custom images, and the combine is yours to run.

It’s not hard once you know the three gotchas that aren’t in the documentation: the UTF-8 BOM, the relative-path resolution, and the partner acceptance level. Get those right, validate the merge before you deploy, and a generic installer that saw zero disks becomes one that sees the boot LUN and finishes the install.

The complete build scripts, validation tooling, VIB reference, and full documentation are open-source on GitHub under GPL-3.0.

Repository: github.com/noahfarshad/esxi-hpe-synergy-imagebuilder

Related Stories:

1 thought on “When the Installer Sees Zero Disks: Building a Custom ESXi ISO for HPE Synergy SAN Boot”

Leave a Comment

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

Scroll to Top