The most valuable asset in your virtualization estate is not a license. It is the accumulated judgment of the people who run it: what a maintenance window smells like when it is about to go wrong, which alarms matter, where the bodies are buried in the storage layer. That judgment is encoded in vSphere’s vocabulary, and the practical question about any successor platform is how much of it transfers. With VME the answer is: more than you would expect, and less than the mapping table implies. This article gives you both halves.
Translation tables flatter platforms, which is why vendors love them and why I am going to be careful with this one. Two things can be true at once: an experienced vSphere administrator really can orient inside VME in an afternoon, because the concepts rhyme; and every row of the table below hides an asymmetry that will surface at three in the morning if nobody told you about it. The table is for orientation. The prose around it is the actual article.
The map
| You say | VME says | What the equivalence hides |
|---|---|---|
| vMotion | Live migration | Genuine parity for the common case; live migration for Secure Boot VMs arrived with the 9.0 generation. |
| DRS | Dynamic placement, with placement profiles | The docs use the word DRS, but profiles arrived in 2026 and there is no admission control behind them. |
| vSphere HA | Per-VM failover modes: Auto, Failover, Pinned | Availability is a property of each VM, not a promise made by the cluster. |
| Maintenance mode | Maintenance mode | The honest row. Evacuates VMs, as you expect; it is also the platform’s patching unit. |
| vSAN | Ceph HCI | Three-host floor, 4 GB RAM per disk, jumbo frames required, and a different tuning culture entirely. |
| VMFS | HPE Clustered Datastores (GFS2) | The clustering machinery was replaced outright at layout 1.3; fixes were still landing at 9.0.1. |
| dvSwitch | OVS bridges and portgroups | Per-host constructs under manager orchestration; there is no distributed switch object to configure. |
| VMware Tools | QEMU guest agent plus VirtIO drivers | Two components, not one, and swapping them is the guest surgery at the heart of every migration. |
| VADP / CBT ecosystem | Veeam plugin with changed block tracking | An API every vendor built on for twenty years maps to one vendor shipping since March 2026. |
| Site Recovery Manager | Zerto | Arguably an upgrade, and a separate purchase; nothing equivalent is native to VME. |
Now the asymmetries, grouped the way you will actually meet them.
Compute mobility: the words match and the guarantees do not
Live migration is the row where the translation is most honest. VMs move between HVM hosts while running, maintenance mode evacuates a host the way you expect, and the 9.0 generation extended live migration to Secure Boot guests, which quietly matters because a modern Windows estate is a Secure Boot estate. If your mental model is “vMotion, but KVM,” you will not be badly surprised, and it is the only row of the table about which I can say that without a qualifier worth writing down.
The scheduler needs more care. VME’s documentation itself reaches for the word DRS to describe its dynamic placement, which tells you exactly what market it is courting, and the machinery is recognisable: automatic placement decisions, and since the 9.0 generation, selectable aggressiveness profiles with cooldowns between migrations. What two decades of vSphere habit will make you assume, wrongly, is everything that grew up around DRS. There is no documented admission control, so no reservation of failover capacity enforced by the cluster; anti-affinity was a roadmap item and I cannot confirm its current state from documentation, so I will not claim it either way. The failure mode this produces is specific enough to name: a cluster that survives host loss in the demo, because it happened to have headroom, and takes an outage eighteen months later, because nothing was ever enforcing that headroom while the estate grew. On vSphere, admission control was the institutional memory that said no. On VME, that memory has to live in your capacity management, because the platform does not currently hold it for you.
On vSphere, admission control was the institutional memory that said no. On VME, that memory has to live in your capacity discipline, because the platform does not hold it for you.
High availability translates with a change of grammatical subject that is easy to miss and architecturally loud. vSphere HA is a cluster property: you switch it on for the cluster and admit VMs into its protection. VME’s failover is a per-VM property with three modes, Auto, Failover and Pinned, so availability is something each workload carries rather than something the cluster promises. The flexibility is real, pinning a license-bound VM to a host is a first-class concept rather than a DRS override, but so is the audit burden: on vSphere the question “is this VM protected” was answered by cluster membership, and on VME it is answered per VM, which means it is a report somebody has to run rather than a fact the architecture enforces. Fleet-wide guarantees that used to be structural become procedural, and procedural guarantees drift.
Storage: same diagram, different civilisation
The storage rows are where the translation layer is thinnest, because what maps is the topology and what does not map is the culture underneath it.
Ceph occupies vSAN’s box on the whiteboard: local disks in each host, pooled into cluster storage, three hosts minimum. But vSAN is a product with one vendor’s opinions baked in, and Ceph is an infrastructure civilisation with its own vocabulary, its own failure modes and its own appetite: plan 4 GB of RAM per Ceph disk and a jumbo-frame storage network, because clustered storage on VME requires both. VME’s packaging of Ceph is genuinely opinionated, the platform configures it and puts a dashboard on it, and for the workloads inside the qualification matrix that packaging holds. The cultural difference surfaces at the edges, when something goes wrong at a layer the dashboard abstracts. A vSAN administrator troubleshoots vSAN; a Ceph administrator eventually troubleshoots Ceph, and those are different careers on bad days. [VME 4] takes the whole storage decision properly, including the protocol conversation.
The VMFS row deserves its warning label. Shared block storage over iSCSI or Fibre Channel lands on GFS2, which HPE now brands HPE Clustered Datastores, and this is the least settled area of the platform: the 9.0 generation removed Pacemaker as the clustering resource manager in favour of the platform’s own agent, 9.0.0 added two-node clusters with an external quorum witness, and 9.0.1 was still shipping fixes for clustered-datastore edge cases in July 2026. VMFS earned its invisibility over twenty years; nobody thinks about VMFS, which is the highest compliment infrastructure can receive. GFS2 on VME is not invisible yet. If your estate leans on a SAN, weight your pilot toward exercising this layer hard, because it is the one place in the translation table where the vSphere reflex, shared block storage is the boring safe default, points you at the platform’s youngest code.
Networking and the guest: smaller words, real work
The dvSwitch row hides a subtraction. Open vSwitch gives you bridges, bonds, VLAN-tagged portgroups and, since 9.0, SR-IOV and trunking: the data plane a virtualization platform needs. What it does not give you is the distributed switch as an object of administration, a single fabric-wide construct with its own configuration lifecycle. The manager orchestrates consistent per-host network configuration; that is orchestration of many switches, not existence of one, and the difference shows up in how you audit, how you change, and how you break things. For flat-to-moderately-segmented estates the subtraction costs little. For estates whose network team treats the dvSwitch as their southernmost device, it is a conversation to have before the pilot, not during it. And to say it once more, because it filters who should be reading this series at all: there is no NSX equivalence anywhere in this tier, a gap [VME 2] already priced into the judgment.
The VMware Tools row looks trivial and is where migrations actually bleed. Tools is one package, one version column in your inventory. Its replacement is two components with different jobs: VirtIO drivers, which the guest needs to see its paravirtual disk and network devices at all, and the QEMU guest agent, which gives the platform its view into the guest for quiescing, IP reporting and graceful shutdown. On the way over from ESXi, Tools comes out, both go in, Linux interface names shift, block devices change from sdX to vdX, and anything that hardcoded a path or an interface name notices at the worst possible moment. The 9.0 release notes add automated VirtIO injection for bulk migrations, though the published migration guide still walks Windows guests through manual driver work, so treat the automation as narrowing the problem rather than closing it. Fleet health also changes shape: you are now monitoring two components per guest rather than one, and your build images need both baked in from day one.
Data protection: an ecosystem maps to a vendor
The last two rows share a theme: on vSphere the capability lived in an API or a native product, and on VME it lives in a named vendor, which is a different kind of dependency and should be evaluated as one.
VADP is not a feature, it is the reason every backup product you have ever evaluated worked on vSphere on day one. Its VME translation is the Veeam plugin: agentless, image-based, changed block tracking, application-aware processing, shipping since March 2026, and genuinely good. It is also one vendor, with its own requirements, including at least one datastore of a type the backup workers can use in each cluster, a detail with real consequences for pure-HCI designs that [VME 6] chases down. Translating “we have a mature backup ecosystem” as “we have Veeam” is accurate today and may be generous or stingy in a year; either way, the noun changed from an API to a vendor, and your risk register should record it that way.
Site Recovery Manager translates to Zerto, and for once the direction of the asymmetry favours the new platform: continuous replication with journal-based recovery points against SRM’s orchestrated array or vSphere replication is, in most estates I have argued this in, an upgrade. The catch is architectural rather than technical. SRM was VMware’s own answer inside VMware’s own stack; Zerto is a separate HPE-owned product with its own licensing, its own appliance estate and its own support cadence commitment to the platform. DR on VME is not a checkbox in the manager. It is a second product decision, made easier by the fact that HPE owns the product and currently prices its migration use at a dollar, and [VME 7] takes that thread where it leads.
What does not translate
Three things have no row because they have no equivalent, and naming them is the difference between a translation layer and a brochure. There is no admission control, as covered, and its absence changes who enforces capacity discipline in your organisation. There is no distributed firewall or overlay networking at this tier, so if those words are in your architecture documents, so is your answer about timing. And there is no twenty-year sediment of community knowledge: the forum thread that solves your exact problem, the consultant who has seen your exact failure, the interview pool that already speaks the platform. That sediment is what actually made vSphere cheap to operate, whatever the license cost, and it is the one thing no vendor can ship in a release note. It accretes or it does not, on a timescale measured in years.
What the table should leave you with is not that VME is vSphere with different nouns, and not that the differences are disqualifying. It is that your team’s judgment transfers at the level of concepts and has to be re-earned at the level of reflexes, and the gap between those two is precisely what a pilot is for. The next article stops translating and starts building: [VME 4] takes the architecture on its own terms, clusters, storage and networks, as a set of decisions rather than a set of comparisons.
VME
‹ Previous: [VME 2] The VMware Question: Coexist, Replace, or Wait
Next: [VME 4] How VME Is Built: Clusters, Storage, and Networks ›
