HPE VM Essentials 9 Is Ready for Metro-Style Stretched Clusters

HPE Morpheus VM Essentials is ready for multi-site virtualisation only if “multi-site” means a tightly coupled, metro-style cluster. Version 9 can stretch an HVM cluster across two locations and keep eligible workloads protected through defined infrastructure failures. It does not turn two ordinary sites into a complete disaster-recovery service.

That sounds like a small distinction until an outage exposes it. “Multi-site HA” (high availability) is often used to describe two very different jobs: keeping workloads running after a host or site failure, and recovering an application elsewhere after a wider incident. VM Essentials 9 makes a meaningful move on the first. It supplies only part of what is needed for the second. (support.hpe.com)

The significant change: v9 has a proper stretched-cluster model

The earlier VM Essentials HA story was uncomplicated: an HVM virtual machine could restart automatically after a host failure, but within its own cluster. HPE’s reference material still describes live migration and automatic VM restart in those terms. For a conventional cluster, that remains the correct mental model. (support.hpe.com)

Version 9.0.0, released in June 2026, adds HVM cluster layout 1.3 and stretched-cluster support across multiple logical sites. HPE describes one management domain spanning two physical locations, with site-level fault tolerance. This is not two separately managed clusters wearing a shared-console badge; it is a different cluster design. (support.hpe.com)

The entry requirements are intentionally demanding: at least six hosts, divided three per site, plus a Morpheus Distributed Worker acting as a witness from a third, independent location. Every host must communicate with every other host, the witness and VM Essentials Manager. The arrangement uses both intra-site and inter-site quorum. Quorum determines which side may continue using shared resources after a communications failure; without it, both sides may write to the same disks—a classic split-brain event. (support.hpe.com)

So VM Essentials 9 is no longer purely a single-site HA product. But it is not a geographically unconstrained distributed platform either. Stretching a cluster extends its failure-domain assumptions along with its hosts. It is not a licence to carry storage and Layer 2 networking across any distance that happens to have fibre.

HA spans the cluster, but the failure path decides whether it helps

Within a standard HVM cluster, the expected capabilities are present: automatic failover for eligible VMs after host loss, maintenance-mode migrations, affinity placement and dynamic balancing. HPE calls the balancing feature Dynamic Placement. Version 9 adds conservative, moderate and aggressive profiles, along with migration cooldowns based on memory utilisation. Those are sensible controls where automatic balancing might otherwise cause unnecessary VM movement. (support.hpe.com)

A stretched cluster makes the awkward scenarios more important. What happens when an entire site disappears? What happens when the inter-site link fails but both sites are still powered? HPE treats a site as failed when all non-witness nodes there are unreachable for 60 seconds. The surviving site must still reach the witness before it can proceed; if it cannot, it self-fences rather than assuming it has won. Fencing isolates a failed or suspect node from shared storage so it cannot corrupt data when it returns unexpectedly. (support.hpe.com)

One documented detail is easy to overlook and difficult to excuse after the fact: in a tie, HPE’s arbitration selects the first site listed alphabetically as the winner. Predictable is better than ambiguous, but alphabetical order is not a business-continuity policy. Make the preferred result explicit in naming, placement policy and runbooks. A regional network event is a poor moment to find that the less capable site won because of a naming convention. (support.hpe.com)

And automatic VM restart is not uninterrupted service. A failed host still means a guest restart unless the application has its own clustering or replication. That may be perfectly reasonable for a web tier. For a busy database, getting the VM booted can be the least complicated part of recovery.

Workload mobility remains cluster-local

It helps to separate two mobility scenarios. Inside an HVM cluster, VM Essentials can place, rebalance and migrate workloads among member hosts. With v9 stretched clusters, those hosts can sit across the two logical sites in the stretch design. HPE also says live migration now supports VMs using Secure Boot, removing a previously awkward guest configuration. (support.hpe.com)

Separate clusters are another matter. VM Essentials Manager can centrally manage more than one cluster, including existing VMware targets and HVM resources, but one console does not create one compute or storage pool. HPE’s documentation and reference architecture describe live migration within the same cluster; the supplied documentation does not establish automatic cross-cluster placement or transparent live WAN migration as a general HVM capability. (helpcenter.veeam.com)

That is not uniquely an HPE limitation. Cross-site live migration requires compute state, storage access, guest networking and IP addressing to remain valid at the destination. If Site A and Site B are independent clusters, plan for migration, restore, replication-led failover or a rebuilt workload at the other end—not VMware DRS (Distributed Resource Scheduler)-style automation.

Affinity rules still deserve care. Pinning a VM to a host can be justified for specialist hardware, licensing or performance, but it narrows the room available for automated maintenance and recovery. HPE notes that a live pinned VM can prevent a host entering maintenance until it is moved manually or powered down. In a stretched design, use host affinity sparingly and prefer site-aware application design where possible. (docs.morpheusdata.com)

Storage is where a plausible design becomes a supportable one

For a basic single-site cluster, VM Essentials offers directory pools, NFS (Network File System) pools and GFS2 pools. HPE is clear about the compromises. Directory storage has no external dependency, but offers neither redundancy nor migration capability. NFS centralises storage and enables migration, although the NFS service itself needs HA and network latency can affect performance. GFS2—Global File System 2—is the clustered filesystem choice for shared disks, live migration and clustered workloads, but it needs dependable shared storage and brings additional operational complexity. (support.hpe.com)

In a stretched cluster, storage is not a later implementation detail. HPE’s deployment procedure has administrators add an HPE Clustered Datastore, formerly called a GFS2 datastore, which activates the quorum service. Cluster layout 1.3 also changes the HA control path for these datastores: the Morpheus Agent replaces Pacemaker in fencing decisions, while Corosync and distributed locking remain part of the consistency model. (support.hpe.com)

The storage path between sites needs as much scrutiny as the compute layer. Fibre Channel, iSCSI (Internet Small Computer Systems Interface) and NFS appear in HPE’s wider HVM material, but validation is not the same as generic support. One recent HPE reference architecture supports external storage through those protocols while stating that its tested design validated Fibre Channel only. Confirm support for the exact array, replication mode, fabric extension and NFS implementation rather than extrapolating from a reference build. (support.hpe.com)

This does not mean the storage must come from HPE. It does mean the external shared-storage design must work as an end-to-end service: dual paths, sensible multipathing, consistent host presentation, failure testing and an unambiguous fencing method. HPE recommends MPIO, or multi-path I/O, for Fibre Channel and iSCSI LUNs used with GFS2. A stretched storage design with one untested dependency is simply a larger single point of failure. (support.hpe.com)

Organisations planning an array refresh should also ask whether the chosen platform has a supportable path for this specific design. The choice between HPE Alletra MP and Dell PowerStore matters more when the array participates in quorum and recovery, rather than merely holding VM disks.

Backup helps, but it is not orchestrated DR

VM Essentials includes native VM backup and restore workflows, including full, incremental and optional synthetic-full schedules for HVM instances. It also supports backup targets through configured storage buckets. That is useful for routine protection and individual-machine recovery. A successful backup job, though, says very little about whether a multi-tier service will start correctly at another site. (support.hpe.com)

Third-party protection becomes more relevant in a multi-site design. Veeam’s current HPE Morpheus VM Essentials support can restore an entire VM to its original or a new location, and Veeam documents VM Essentials Manager as the central interface through which its plug-in accesses clusters, networks, datastores and VMs. HPE’s Commvault material likewise describes an out-of-place restore to a different cluster managed by the same VM Essentials instance. Those are useful recovery routes. They are not evidence of native automated site failover. (helpcenter.veeam.com)

For critical applications, define the recovery point objective (RPO)—the acceptable amount of lost data—and recovery time objective (RTO)—the acceptable time to restore service—before selecting the tooling. Then test the real sequence: DNS or load-balancer changes, identity dependencies, database recovery, application start order, certificate availability, security controls and user validation. Recovering a VM is one task in the plan, not the plan itself.

This matters especially for VMware exits. Backup tooling can contribute to migration or recovery, but that is separate from deciding whether a stretched HVM cluster suits the workload. A VMware exit strategy using HPE VME or Veeam still needs a destination and protection model that remains credible after the migration project ends.

Centralised management is useful—and another dependency to protect

VM Essentials Manager is a control plane. It brings multiple managed clusters into one interface and provides inventory, VM provisioning, networks, policies, roles, activity records and tenancy controls. HPE’s role model can apply a multi-tenant role down to subtenants, allowing central IT to retain governance while separating local teams or customers. (helpcenter.veeam.com)

That can work well for a small IT team looking after a main office, secondary site and perhaps a hosted recovery location. It is not independent local autonomy. If the manager, its database, name resolution, identity source or management connectivity fail, operators may retain local host-level options but lose the central workflow they expected to rely on during the incident.

Protect the management plane accordingly. HPE documents appliance backup to a configured bucket or file share, while newer releases add support bundles, health metrics and operational runbooks. Helpful as those additions are, they do not remove the need to plan for manager restoration, secure its backup destination, document emergency access and prove what remains possible when the manager is absent. (hpevm-docs.morpheusdata.com)

Networking needs the same discipline. HVM creates Open vSwitch and libvirt network objects during cluster creation, while later interface additions require manual preparation in netplan and the hpe-vm tool before a UI refresh. The manager’s networks view can cover all configured clouds, but it cannot repair inconsistent VLANs, MTUs, firewall policy or IP address management. (support.hpe.com)

What to check before calling it a two-site solution

• Confirm the physical shape. A supported stretched design calls for two sites, at least three hosts per site and an independent third-site witness. A two-node GFS2 option exists in v9, but that does not provide the capacity or fault tolerance of the six-host stretch pattern. (support.hpe.com)
• Measure latency and packet behaviour. Test under load and during link impairment. Storage, cluster heartbeats, migrations and guest networks do not share the same tolerance for delay and loss.
• Document the winner. Check site-group configuration and understand HPE’s documented deterministic tie-break behaviour before an outage makes the choice for you. (support.hpe.com)
• Design application recovery separately. VM HA restarts guests; it does not make a database, directory service or line-of-business application resilient by itself.
• Validate the exact storage stack. Include array firmware, protocol, multipathing, switches and any inter-site replication or fabric extension in the support discussion.
• Test manager loss. Back up the appliance, retain emergency credentials and rehearse recovery into a clean management environment.

Who should use it now—and who should wait

VM Essentials 9 may suit organisations leaving VMware with a compact, well-connected two-site estate, HPE-compatible hardware and a team able to own the storage and networking design. It is particularly relevant where ordinary infrastructure workloads need availability across a local metro footprint, without retaining a large vSphere estate for that purpose alone.

It also deserves consideration where central management during a staged transition matters. VM Essentials can manage VMware alongside HVM, allowing an estate to change in stages rather than requiring one cutover. That is a practical advantage, even though the two environments retain different mobility and recovery characteristics. (support.hpe.com)

Wait, run a proof of concept, or select a more mature alternative if the requirement is active-active application continuity across long distances; automatic policy-led failover between independent clusters; broad, proven third-party storage interoperability; or a deeply established DR orchestration ecosystem. Those outcomes may be possible around VM Essentials, but they require additional products and evidence beyond the core HVM feature list.

HPE has moved VM Essentials beyond single-site virtualisation with v9’s stretched clusters. That is the development worth taking seriously. The less glamorous conclusion matters just as much: multi-site resilience is only as strong as its weakest dependency. Treat VM Essentials as the cluster and management layer—not as a substitute for storage engineering, network design, quorum discipline and application recovery testing.