operations

The Layer Below the Hypervisor Why Bare-Metal Lifecycle Became a Compliance Problem

Adding a host to a VCF cluster still means a manual, a firmware lookup and a twelve-step checklist. DORA Articles 8 and 11 now have opinions about that, which turns an operational annoyance into a regulatory one.

Here's a description of adding a server to a VCF cluster that anyone who has done it will recognise. Open a manual, look up compatible firmware, run a twelve-step provisioning checklist, and hope nothing breaks during the ESXi upgrade window.

That's not me being unkind about the platform. It's how Broadcom's own ESXi lifecycle product manager describes it, in a post published during Explore about the MetalSoft partnership. Naming the problem that plainly is unusual and makes the rest of the post worth reading.

What actually has to happen before VCF sees a host

VCF gives you a consistent software-defined platform across compute, storage, networking, management and automation. Below that layer, nine things have to be right before an ESXi host can join:

• Server discovery and inventory

• BMC access and hardware interrogation

• BIOS and firmware configuration

• Driver and firmware baseline alignment

• Network and storage readiness

• GPU, NIC, DPU and accelerator validation

• ESXi installation and host preparation

• Hardware compliance and drift detection

• Safe decommissioning or tenant reassignment

In a homogeneous estate you can handle that with OEM tools and runbooks. Most large enterprises aren't homogeneous. They run Dell, HPE, Lenovo, Supermicro and increasingly custom ODM hardware, and each brings its own firmware catalogue behaviour, its own BIOS defaults, and its own interpretation of Redfish.

That last point is the one that kills in-house automation. Redfish is a standard, and vendor implementations differ enough that a script working cleanly against one generation of one vendor's hardware may not work against the next. Teams end up maintaining a driver layer they never intended to own.

The part that makes this a governance problem

This is where the post gets more interesting than a typical partnership announcement.

Broadcom cites CrowdStrike's 2026 Global Threat Report finding that AI-enabled attacks grew 89% year over year in 2025. In response, many enterprises have set a seven-day deadline for patching vulnerabilities across the entire fleet.

Seven days across a heterogeneous fleet, including firmware, is not achievable with manual runbooks. That's the arithmetic, and it's worth doing honestly against your own estate before committing to a number in a policy document.

Then the regulatory point, which is the one I'd put in front of anyone in financial services. DORA Articles 8 and 11 require automated mechanisms for firmware management, instantaneous severability, and rapid recovery.

Read that carefully. Automated firmware management is not a maturity aspiration under DORA, it's a requirement. If your firmware process is a spreadsheet and a maintenance window, that's a compliance gap sitting in a place most compliance reviews never look, because firmware lives below the layer where most audit conversations happen.

For anyone with European exposure, that's worth raising with your risk function before they find it themselves.

The quote that will land in your next planning meeting

“The question isn't whether to automate hardware lifecycle it's whether you do it before or after a production incident forces the issue.” Infrastructure Architect, Fortune 500 Financial Services

That's from the post, attributed to an unnamed FSI architect. It's the right framing, and it applies to a lot more than firmware.

What MetalSoft actually is

An intent-based, API-first infrastructure automation engine that speaks Redfish, IPMI, BIOS configuration, firmware catalogues and switch provisioning, and turns those into policy-driven auditable workflows.

The layered model Broadcom describes:

VMware Cloud Foundation
  Fleet Manager · vCenter · vSAN · NSX
        ↓  standardised APIs, declarative policy
MetalSoft Bare-Metal Orchestration
  Multi-vendor drivers · Redfish engine · switch fabric
        ↓  direct control via BMC, Redfish, IPMI
Heterogeneous Physical Infrastructure
  Dell · HPE · Lenovo · Supermicro · ODM

The honest note in the post is worth repeating: this doesn't make OEM tooling disappear. You'll still use vendor tools for deep diagnostics, warranty workflows and vendor-specific remediation. What changes is that the lifecycle operating model becomes consistent across vendors, which is a different and more achievable claim.

The eight-step readiness flow

A typical flow, per the post: discover servers and inventory, assign to an infrastructure pool, apply hardware baseline and BIOS/BMC policy, align firmware and driver prerequisites, prepare networking and storage access, install or prepare ESXi, validate readiness before VCF onboarding, then continuously monitor drift after deployment.

Step eight is the one that separates this from a provisioning tool. Continuous drift monitoring after deployment means firmware alignment stops being a point-in-time state and becomes a monitored property, which is what closes the HCL drift problem rather than just deferring it.

The GPU angle, and one detail worth knowing

AI infrastructure raises the stakes because an AI server isn't just another compute node. Multiple GPUs, high-bandwidth NICs, DPUs, accelerator topology, fabric dependencies, liquid-cooling considerations, stricter isolation requirements.

The detail I'd draw attention to is secure tenant deprovisioning. MetalSoft describes storage sanitisation, GPU persistence reset, and removal of network segments to prevent tenant data leakage between occupants of the same GPU.

If you're planning multi-tenant GPU capacity, that's a question you need an answer to regardless of tooling. GPU memory persists. Handing an accelerator from one tenant to another without a defined reset procedure is a data leakage path, and it's not one most enterprise platform teams have had to think about before because CPUs and RAM get cleared by the hypervisor as a matter of course.

Add it to the design questions for any GPU-as-a-Service or shared-accelerator model: what exactly happens between tenants, and who verifies it happened.

The ODM connection

This ties directly to the hardware economics argument. Vendor-specific drivers plus generic Redfish support creates a path for onboarding ODM and custom hardware into a consistent lifecycle model.

The post is appropriately cautious: ODM readiness still depends on hardware validation, Redfish and BMC implementation quality, firmware integration and support agreements. Not every custom platform becomes automatically supported.

But it removes one of the real objections to ODM adoption. The concern was never only whether the hardware works, it was whether you'd end up maintaining bespoke automation per vendor forever. A multi-vendor orchestration layer changes that calculation.

What to take into your own estate

• Work out how long a full-fleet firmware update actually takes you today, end to end. If a seven-day patch commitment is anywhere in your policy documents, compare the two numbers.

• If you have European exposure, check DORA Articles 8 and 11 against your current firmware process. Automated firmware management is a requirement, not a maturity goal.

• Count your vendors and generations. The heterogeneity number is what determines whether in-house automation is viable or a slow-motion maintenance commitment.

• For any shared GPU plan, define the tenant reset procedure explicitly. Storage sanitisation, accelerator memory reset, network segment removal. Then decide who verifies it.

• Treat HCL drift as a monitored property rather than something you check at upgrade time. That's the shift the eight-step flow is really describing.

The line the post closes on is the right ambition. Adding fifty servers to a cluster, or decommissioning fifty, or updating firmware on two hundred, shouldn't be the most stressful week of the quarter.