Nobody evaluates VME on its merits, and I mean that as an observation rather than a complaint. Every conversation about this product is a conversation about VMware wearing a lab coat. So let us have that conversation honestly, in the three postures that actually exist: coexist, where vCenter keeps its authority and VME sits beside it; replace, where the estate moves in waves and the vSphere licenses lapse; and wait, which is a legitimate architectural position and not a failure of nerve. The right answer differs by estate, and the point of this article is to let you locate yours.
[VME 1] made the framing argument: the Broadcom acquisition was an architectural event because it changed the ownership of your control plane. This article is the judgment that follows from it. I am going to be specific about capabilities, name the gaps without softening them, and label every price figure with where it came from, because this is the article most likely to end up in front of your CFO and it should survive that audience.
Coexistence: what VME actually manages when it manages vCenter
VME connects to an existing vCenter as a managed cloud, using a service account you create with a long and specific privilege list. Once connected, it can inventory the brownfield estate, provision new VMs onto ESXi, take and manage snapshots, migrate VMs between vSphere environments, sync vSphere tags, and scope its view to particular datacenters or clusters. Templates work, cloud-init works, and the platform converts its own image formats to VMDK on the way in. For an organisation running both stacks during a transition, this is a real capability: one inventory, one provisioning surface, one API, across both estates.
Now the boundary, which matters more than the feature list. Nothing in the documentation claims management of ESXi host configuration, DRS policy, or the distributed switch, and the docs’ silence should be read as absence. vCenter remains the authority for host lifecycle, for cluster availability policy, and for the network fabric. VME is a tenant of your vSphere estate, not a regent. There are also two documented limits worth knowing before anyone demos this to you: the hypervisor console works only for VMs that VME itself provisioned, and snapshot and backup features fail for VMs carrying SR-IOV adapters. And one absence I want on the record because it is the kind of thing that surfaces during an incident rather than a proof of concept: the VME documentation states no supported vCenter or ESXi version matrix at all. The only version references anywhere near the integration are API-level minimums, not a tested range. I cannot tell you which vSphere releases HPE has tested against, because HPE does not say, and an integration boundary without a version matrix is a support conversation waiting to happen.
Coexistence means VME becomes a tenant of your vSphere estate, not a regent. vCenter keeps host lifecycle, availability policy and the network fabric, and the docs never pretend otherwise.
Understood on those terms, coexistence is the strongest thing VME does. It converts an exit from a leap into a posture you can hold for as long as the licensing arithmetic makes holding it worthwhile. The subtle cost is narrative control: the platform that manages both sides of your migration also frames your migration, in its inventory, its reporting and its defaults. That is not sinister. It is what every management plane does, and you should simply know it is happening.
Replacement: waves, surgery, and the tool you will actually use
Replacing vSphere with VME is a project with a shape, and the shape is waves under coexistence: stand up HVM clusters beside the vSphere estate, move workloads in planned batches, and let the vSphere footprint shrink toward its renewal date. What makes it a project rather than a feature is the guest-level reality. A VM leaving ESXi for HVM changes its paravirtual organs: VMware Tools comes out, the QEMU guest agent goes in, VirtIO drivers arrive, Linux NICs and disks change names, and anything with a hardcoded device path notices. This is routine work, well understood since the P2V era, but multiplied across five hundred VMs it is the actual cost center of the migration, and no licensing discount touches it.
The built-in migration tool is cold only. The VM powers down, transfers, and powers up on HVM; nothing warm or live is documented, and I checked the current release specifically because this is the claim I most expected to have gone stale. It has not. The warm path exists, but it is a separate product: Zerto, HPE-owned since 2021, replicating continuously from vSphere into HVM and cutting over with minutes of downtime rather than the duration of a copy. That pairing, cold built-in or warm via a product HPE happens to own, is not an accident of the portfolio, and the migration offer below prices it accordingly. The full migration argument, batch limits, rollback, wave planning and all, is [VME 7]’s subject; what belongs here is only the judgment-level fact that the exit door is real, it is cold by default, and warming it up is a purchase.
The gaps, named plainly
Every platform evaluation I trust has a section like this one, and every vendor deck omits it. Four gaps are load-bearing as of the current release, and I will keep this list honest release by release because two of them are moving.
There is no NSX equivalent in VME. Networking is Open vSwitch with VLANs, bonds and SR-IOV, which is a competent 2015 answer to a question NSX moved past: no distributed firewall, no microsegmentation, no overlay fabric at this tier. HPE’s software-defined networking answer arrives in the 9.0 generation, but in the Advanced tier per current reporting, and Advanced remains undocumented in public. If your security architecture leans on NSX microsegmentation, VME is not currently your exit, and anyone who tells you otherwise is selling the middle tier on futures.
The backup ecosystem is one vendor deep at the level that matters. Veeam shipped agentless, image-based protection for HVM with changed block tracking in March 2026, and it is real and current. Commvault documents image-based protection with storage caveats. Everyone else, Cohesity and NetBackup and Data Protector among them, drops to in-guest agents, and Rubrik, Dell and IBM have published nothing for HVM at all. Set that against vSphere’s VADP, an ecosystem every backup vendor on earth has built against for two decades, and the asymmetry is stark. If your data protection standard is anything other than Veeam or Commvault, your backup posture on VME changes, and [VME 6] walks the whole vendor table.
The hardware envelope is narrow. HPE recommends ProLiant, permits compatible servers, and publishes a qualification matrix that is a fraction of the VMware compatibility guide’s breadth. An estate standardised on HPE metal will not feel this. A mixed estate will, and should check the matrix against its actual fleet before any commercial conversation starts.
And the platform is hardening in public. Releases land roughly monthly. The 9.0 generation replaced the clustered-storage resource manager outright, and 9.0.1 was still fixing clustered-datastore edge cases in July 2026. Per-VM failover exists; a documented equivalent of vSphere’s admission control does not. None of this is disqualifying, young platforms harden or die, but the maturity difference between a two-year-old product line and a twenty-year-old one shows up precisely in these corners, and pretending otherwise would waste your reading time.
The money, with every figure labeled
Price is where this conversation usually starts, so let us do it with the labels attached, because the two sides of this comparison publish very differently. HPE publishes a list price. Broadcom publishes none, so every VMware figure in circulation is reported, negotiated or leaked, and I will mark them accordingly.
VME’s suggested US list is $600 per socket per year with 24×7 support included. Vendor figure, printed on HPE’s own SKUs. On the Broadcom side, the ground moves under the description, which is itself part of the story. What is settled: the perpetual model is gone, licensing is per-core subscription with minimum core counts, and the vSphere 9 generation is packaged around VMware Cloud Foundation and VMware vSphere Foundation. What is not settled is what you are allowed to buy, and where: vSphere Standard remains on sale, VVF was withdrawn in parts of EMEA effective late 2025, and minimum core commitments have been introduced, walked back and reintroduced by region inside eighteen months. The going rates reported by licensing advisories put VVF roughly between $135 and $190 per core per year and VCF at roughly $350 and up, against a baseline of 16 cores per CPU. Third-party figures, not list, because Broadcom publishes none, and negotiated outcomes vary widely. A pricing regime you cannot describe without a region map and a changelog is an argument in its own right, and your renewal quote, not any published number, is the figure your model should use.
Run the arithmetic on a plain two-socket, 64-core host and label it as the estimate it is: VVF at reported rates lands somewhere between $8,600 and $12,200 a year, VCF north of $22,000, VME at list $1,200. HPE’s own marketing claims savings of up to 90 percent, and that is HPE’s internal analysis, so treat it as a vendor claim; but the striking thing about the independent arithmetic is that you do not need the vendor claim. An order-of-magnitude gap survives any plausible discount on either side. What the gap does not survive is a scope error: VCF is a full private cloud stack, compute, storage, network virtualization and operations tooling, and VME at this tier is a hypervisor and its manager. If you consume vSAN and NSX seriously, the honest comparison adds their replacements, Ceph capacity planning, backup ecosystem consequences and the SDN question, back onto VME’s side of the ledger. The gap narrows. In most estates I have modeled it does not close, but your arithmetic should be done on your estate, not mine.
You do not need the vendor’s 90 percent claim. The independent arithmetic is loud enough, provided you compare stacks and not stickers.
Then there is the offer, and for once it is on the record. In June 2026, alongside Discover Las Vegas, HPE announced a migration program for VMware customers: up to one year of VME licenses free, a year of Zerto for one dollar to carry the migration itself, and zero percent financing on software through HPE Financial Services. Those terms are on HPE’s own press page, and the intent is explicit: the double-bubble problem, paying two vendors while you migrate, is the single best commercial argument for staying put, and HPE priced it away for a year. Note what the offer covers and what it does not: licenses, not support costs, and “up to” one year, which is contract language for terms and conditions apply. It is a promotion, promotions expire, and if you are reading this at any distance from mid-2026, verify current terms before they enter your business case.
The judgment
Coexist if you are HPE-friendly on hardware, Veeam or Commvault on backup, and light on NSX. This is the widest lane. Stand up VME beside vCenter now, move the workloads that migrate cheaply, and let real operational experience rather than a slide deck decide how far you go. The offer makes the trial year nearly free, and coexistence is the posture the product is genuinely best at.
Replace if the profile above fits and your renewal math is brutal enough to fund the guest surgery. Cost-driven exits from mid-sized, mostly-virtualized estates on qualified hardware are the case VME was built for, and the case the June offer was priced for. Go in with eyes open about the operational maturity gap, size the migration as a project, and read [VME 7] before you commit a date to anyone.
Wait if you are deep in NSX microsegmentation, standardised on a backup vendor that still protects HVM with in-guest agents, running hardware off the matrix, or dependent on availability semantics like admission control that VME has not yet grown. These are not permanent disqualifications; the backup table gained a second image-based vendor within the last eighteen months and the SDN answer is allegedly one tier away. But architecture on futures is how estates get stuck, so the discipline for waiters is to name the specific gap that blocks you, write it down, and re-evaluate when a release note closes it. The worst position is not choosing any of the three. It is drifting into a renewal with no position at all, which converts the strongest negotiating leverage you will ever hold into list price.
Whichever posture you land in, the vocabulary problem comes next: your team thinks in vSphere nouns, and the platform speaks something adjacent. [VME 3] builds the translation layer, including the places where the translation flatters the product.
VME
‹ Previous: [VME 1] HPE VME: A Second Hypervisor Without a Second Career
Next: [VME 3] Speaking VMware: The Translation Layer ›
