For twenty years, running a second hypervisor meant staffing a second career. A vSphere estate and a Hyper-V estate did not share tooling, habits, failure modes or muscle memory, and the organisations that ran both usually did so by accident and regretted it on a schedule. HPE VM Essentials is built on a different bet: that a KVM platform can be operated by the people you already have, with the judgment they already carry, under a management plane one company is accountable for. Whether that bet pays is the subject of this series. What the product is, where it came from, and what you are actually buying when you sign for it is the subject of this article.
I am going to use the name VME throughout, because that is the product you license. The full name is HPE Morpheus VM Essentials Software, the hypervisor inside it is called HVM, and the distinction between those three names carries more architectural information than most datasheets, so it is worth taking slowly.
A management product that grew a hypervisor
Most hypervisor platforms accreted management late and it shows. VME came into existence the other way around, and that ordering explains nearly everything about its shape.
Morpheus Data was a hybrid cloud management vendor, spun out of Bertram Labs around 2015 by most accounts, and it spent a decade building one product: a control plane that provisions, governs and meters workloads across other people’s infrastructure. VMware, the public clouds, Nutanix, OpenStack. Morpheus never owned a hypervisor. It sat above them all and made a business of the sitting, and by the early 2020s it was the management layer HPE itself had embedded inside its Private Cloud Enterprise offering. On 15 August 2024, HPE announced it was acquiring the company outright. The close was announced two weeks later. Terms were not disclosed, and the timing was not subtle: Broadcom had closed on VMware nine months earlier and the repricing of the installed base was in full swing.
What HPE did next tells you what it thought it had bought. On 20 November 2024, at Discover Barcelona, it announced HPE VM Essentials: a KVM-based hypervisor product, priced per socket, that could also manage existing VMware clusters and convert VMs out of them. The quote HPE put in the release called VM Essentials “the first step in utilizing Morpheus across the HPE portfolio.” Standalone availability came in December 2024. In May 2025 the naming settled into its current form: HPE Morpheus VM Essentials Software and HPE Morpheus Enterprise Software, two tiers of one platform, both carrying the HVM hypervisor, both licensed per socket.
VME is the Morpheus control plane, cut down and repriced, with a hypervisor of its own underneath. Read it in that order and the product makes sense. Read it as a hypervisor with a bundled manager and half its decisions look arbitrary.
This lineage has a practical consequence I will lean on for the rest of the series. Because the management plane came first and the hypervisor second, the interesting engineering in VME is almost all in the manager: the clustering model, the placement logic, the migration tooling, the API surface. The hypervisor layer underneath is deliberately boring, and deliberately boring is exactly what you want a hypervisor to be.
What HVM actually is
HVM, which HPE expands as HPE Virtual Machine, is HPE’s packaging of KVM. The install medium is an HPE-built ISO whose boot menu announces an Ubuntu 24.04 base, the virtualization stack is KVM with libvirt underneath, and the platform’s own audit daemon logs libvirt and virsh actions, which is as clear a statement of the internals as you will get from documentation. There is no exotic kernel work here and no proprietary virtualization layer. HPE took the hypervisor that already runs a large share of the world’s public cloud instances and put its name on a curated distribution of it.
I want to be precise about why that is a strength rather than a shortcut, because “it’s just KVM” gets used as a dismissal by people selling something else. KVM’s maturity is not in question anywhere serious. What has always been in question, for an enterprise buyer, is the packaging: who curates the kernel and QEMU versions, who tests the combination, who answers the phone, and who is accountable when a live migration eats a guest. Raw KVM makes you the integrator. VME’s answer is that HPE is the integrator: the host OS ships on HPE’s ISO, patches come only from HPE-hosted repositories that HPE signs and curates, and the supported-configuration boundary is drawn by HPE’s qualification matrix rather than by your appetite for testing. You can dislike the tightness of that boundary, and later articles will poke at it, but it is the entire value proposition. You are not buying a hypervisor. Hypervisors are free. You are buying an accountable configuration of one.
The nouns that matter for the rest of the series: an HVM Host is a server running HPE’s HVM OS. An HVM Cluster is a set of them under common placement and failover logic. The VME Manager is a virtual appliance that holds the control plane, and a Cloud, in VME’s vocabulary, is either a grouping of HVM clusters or a connection to a VMware vCenter. That last sentence is not colour, it is the platform’s entire worldview, and the fact that vCenter is one of exactly two things VME dignifies with the name Cloud tells you precisely which incumbent this product was built to sit beside.
Because the three names cause more confusion than anything else in this product line, here is the whole model in one picture. It is the diagram I draw on whiteboards when a client says “so VME is the hypervisor and Morpheus is the vCenter, right,” which is close enough to be dangerous and wrong in the one place that matters.
One appliance, always Morpheus
The license key decides the tier
What that key lets the manager manage
The hypervisors underneath: this is where HVM lives
Read it bottom-up and the names stop fighting: HVM is the hypervisor and only ever appears in the bottom layer, as a thing being managed. The manager is Morpheus at every tier. VME is neither of those alone; it is the product, the bundle of both, whose key limits the manager to two kinds of cloud. Morpheus Enterprise is not a different manager. It is the same manager allowed to talk to everything.
Three tiers, one product image
The platform ships as a single product image, and the license key decides what it is. That is HPE’s own framing, stated plainly in the documentation, and it is unusual enough to be worth dwelling on. There is no VME installer and separate Enterprise installer. There is one appliance, and elevating it from VM Essentials to Enterprise is a licensing change applied in place, not a migration.
As of the 9.0 generation there are three tiers. VM Essentials is the hypervisor tier: HVM clusters, the vCenter integration, role-based access control, and the core of the management plane. Enterprise is the full Morpheus inheritance: a catalogue of twenty-nine cloud types including the public clouds, Nutanix, OpenStack and the rest, plus multi-tenancy, a policy engine, costing and the blueprint machinery. Between them, announced at Discover Las Vegas in June 2026, sits HPE Morpheus Advanced, which per HPE’s marketing adds Kubernetes and software-defined networking above VM Essentials. I can tell you what HPE says Advanced is. I cannot yet point you at a documentation set that describes it, and until one exists I treat the middle tier as vendor-defined packaging and write accordingly. When it firms up, the articles that touch it will be updated rather than defended.
The two series in this section follow that structure deliberately. This series stays inside the VM Essentials tier, because the hypervisor question deserves to be answered on its own terms. The Morpheus series that follows it starts where the license key changes, and [MOR 1] picks up the Enterprise tier as its own subject. If your interest is the console above the hypervisors rather than the hypervisor itself, that series stands alone and you can start there.
What six hundred dollars a socket buys
HPE’s suggested US list price for VME is $600 per CPU socket per year, and the subscription includes 24×7 HPE support. One, three and five year terms exist. I have seen at least one HPE store listing quote a higher figure, which is a useful reminder that list prices are an opening position, but the order of magnitude is the point: a two-socket host runs about $1,200 a year at list, and per socket rather than per core means a 64-core server and a 16-core server cost the same to license. In a market that has just spent two years being repriced per core, that choice of unit is not an accident. It is the sales pitch.
What the money buys is the subscription to the accountable configuration: the licensed manager, the curated HVM distribution, the patch repositories, and the support relationship. What it does not buy is everything vSphere’s flagship bundles have folded in. There is no NSX equivalent at this tier, no vSAN-style licensing entitlement to unlock, and the ecosystem around the platform is younger by two decades. Comparing VME’s list price against a VMware Cloud Foundation quote is comparing a hypervisor and its manager against a full private cloud stack, and any comparison that skips that sentence is marketing, whichever direction it runs. The honest version of the money argument, with every figure labeled and the arithmetic shown, is in [VME 2], and I would rather you read it there than absorb a headline multiple from a slide.
One release-cadence note belongs in the anchor because it frames every claim in this series. VME ships fast, roughly monthly, and the version that is current as I write this, 9.0.1 from July 2026, followed one month behind a 9.0.0 LTS release that removed a whole clustering subsystem and replaced it with something simpler. A platform moving at that speed makes documentation-based writing perishable. Every article in this series states what was true of the shipping release on the day it was verified, and where a claim is about absence, the absence of a feature or a support statement, I say so explicitly, because on this product absence has a habit of becoming presence within two release notes.
The control question
Strip away the pricing and the lineage and what remains is the question this whole section of the site runs on: who holds the control plane of your estate, and who is accountable for it.
For most readers of this series the honest current answer is vCenter, and everything else orbits it. The renewal that made you open this article did not change the technical facts of your estate. It changed the ownership and intent of the company that holds its control plane, and that is an architectural event, not a commercial one, because control planes are where authority lives. The tool that decides where workloads run, what a cluster promises about availability, and which admin can do what is not one vendor among many. It is the vendor.
You do not evaluate a second hypervisor because you love hypervisors. You evaluate one because a control plane you do not control has become a liability line.
VME’s design acknowledges how estates actually move. It does not ask you to repudiate vCenter on day one; it connects to vCenter as a managed cloud, sits beside it, and gives workloads somewhere to go. That coexistence posture is its strongest architectural feature and also the source of its subtlest risks, because a platform that manages both sides of a migration owns the narrative of that migration. [VME 2] takes the resulting judgment head on: what coexistence actually manages, what replacement actually costs, which gaps are real, and who should wait. [VME 3] does the vocabulary work, mapping the vSphere concepts you think in onto what VME actually does, including where the mapping flatters the product. The articles after those build the thing.
A second hypervisor without a second career is a real offer now, and it was not one five years ago. Whether it is your offer depends on your estate, your tooling and your appetite for a platform still hardening in public, and those are exactly the terms on which the rest of this series argues.
VME
Next: [VME 2] The VMware Question: Coexist, Replace, or Wait ›
