Building a VME estate takes an afternoon. Living with the way you built it takes years. The platform asks you for a manager size, a cluster layout, a datastore type and a network topology in roughly that order, and it asks in a wizard, which disguises how much each answer commits you to. This article is about what those answers actually mean, which of them you can revisit cheaply, and the one place where the platform’s current shape should change what you buy rather than how you configure it.
Everything below is written from the current documentation set rather than from a lab of mine. Where the documentation contradicts itself, and it does in more than one place, I say so instead of picking the tidier number.
The manager is an architectural decision wearing an appliance costume
The VME Manager arrives as a qcow2 image inside an ISO, and you install it onto one of the hosts it is going to manage. That sentence contains the whole of the platform’s control-plane story. There is no separate management cluster, no external database tier, no documented high-availability topology for the manager itself in VM Essentials. One virtual machine holds the inventory, the RBAC engine, the image library and the automation state for everything underneath it, and that virtual machine is a guest of the estate it governs.
The sizing table is short and its right-hand column is the part that matters. Small is 2 vCPU and 12 GB and is documented for up to one cluster. Medium is 4 vCPU and 16 GB and is documented for up to three. Large is 4 vCPU and 32 GB and is documented for up to ten. Those are not performance suggestions, they are the vendor’s stated ceilings on how many clusters a manager is expected to hold, and the memory step from Medium to Large is the only real jump. If you are standing up a proof of concept that you privately expect to become production, deploy Large. Resizing a manager is not difficult, but doing it under load, on a Tuesday, with an inventory you now depend on, is a worse afternoon than sizing it correctly on day one.
Two constraints on the manager deserve to be in your design document rather than discovered later. It does not support multi-tenancy, which the initial setup wizard states plainly while it asks you to name a master tenant, so the account name you type is an identifier and not a boundary. Delegating to business units, service providers or subsidiaries with real separation is an Enterprise-tier capability, which makes it a licensing conversation rather than a configuration one, and [VME 1] set out what that tier boundary costs. And the manager’s upgrade is a package install with a short window of manager-only downtime; running virtual machines are unaffected, but for those ten or fifteen minutes nobody provisions, nobody sees the inventory, and any automation that talks to the API gets connection errors. That is a perfectly reasonable operating characteristic. It is only a problem if your change process assumed otherwise.
The manager is a guest of the estate it governs. Every design decision downstream inherits that fact, and no amount of clustering underneath changes it.
Compare this honestly with what you have. A vCenter with a linked-mode partner, a VCHA cluster or an external PSC gave you a management plane with its own availability story. VME gives you a well-behaved single appliance with backups. For an estate of two clusters and three hundred virtual machines that is proportionate. For an estate where the management plane going away for an hour is a reportable incident, it is a gap you should price in as operational process rather than assume away, because the product does not yet close it at this tier.
The cluster is the unit of management, even when it holds one host
You create a cluster even when you have a single host, because the cluster is the construct the advanced functionality hangs off. Do not read that as ceremony. It is the platform telling you where its boundaries are: datastores are attached to clusters, networks are created on clusters, placement policy is a cluster property, and the layout version that determines how high availability actually works is a cluster attribute you choose at creation.
The shapes available to you are governed by the storage you bring. Hyperconverged with Ceph requires three hosts, because that is where the platform will build a quorum for you. External block storage presented over iSCSI or Fibre Channel, formatted as a clustered filesystem, requires three hosts as well, with the 9.0 generation adding a two-node variant that leans on an external quorum witness. NFS drops the floor to two hosts if what you want is virtual machine availability rather than a clustered filesystem. A single host is permitted, is non-converged only, and gives up live migration and automatic failover in exchange, which makes it an edge or a branch answer rather than a small-office one.
The layout version is the decision inside the decision. Layout 1.1 is the Ubuntu 22.04 lineage, 1.2 is 24.04, and 1.3 arrived with 9.0.0 and changed who is in charge of failover. Through 1.2, high availability for clustered datastores was a conventional Linux HA stack: Corosync for membership and messaging, Pacemaker as the resource manager making fencing decisions, a distributed lock manager protecting the filesystem, and STONITH to isolate a node that stopped answering. At 1.3, Pacemaker stops being the resource manager and the Morpheus Agent becomes the high-availability control plane. Corosync survives in a reduced role, used mainly to maintain a list of hosts rather than to arbitrate, and the fencing and locking machinery remains underneath.
This is a genuine improvement in coherence, because the thing that decides to evacuate a host is now the same thing that talks to the manager. It also means the platform’s availability behaviour is now vendor code rather than the open-source stack your Linux team already knows how to debug, and the observable surface changed accordingly. Heartbeat datastores are the mechanism worth understanding: each host writes to a heartbeat file that the others watch, and a stalled file is what triggers the failover. They are not enabled by default. A cluster with clustered datastores and no heartbeat target set is a cluster whose failover story is thinner than the architecture diagram suggests, and that is a configuration error that produces no error message.
The 1.2 to 1.3 upgrade is offered as a one-click action, and it deserves more respect than one click implies. It runs in two phases. The first rolls through the hosts, upgrading agents, entering and leaving maintenance mode, evacuating workloads, and leaving Pacemaker present but unmanaged; a failure here rolls the cluster back. The second phase stops and masks Pacemaker and transfers ownership to the agent, and from the moment it begins there is no route back to the older layout. Treat it as a migration with a maintenance window, healthy datastores, completed backups and enough spare capacity for evacuation, because those are the documented preconditions and they are documented for a reason.
Storage: choose by the shape of your estate, not by the fashion of the protocol
The honest inventory first, because vendor pages tend to blur it, and because the documentation gives it to you twice in two different shapes. By transport, VME will use local disks in a host, which costs you migration and any recovery from host loss and is therefore a single-host or a lab answer; NFS shares as shared datastores; external arrays over iSCSI or Fibre Channel with a clustered filesystem on top, which is the arrangement HPE has renamed to Clustered Datastores and which most documentation still calls GFS2; Ceph, built for you across the local disks of a converged cluster; an integration plugin for Alletra MP B10000 that maps array volumes straight to virtual machine disks with no clustered filesystem in the middle; and HPE SimpliVity as a separate hyperconverged answer with its own data services. By datastore type, which is the noun the interface uses, the user manual documents six: directory pools, NFS pools, GFS2 pools, 3Par, Alletra Block Storage for HVM, and Alletra Block Storage bare metal. The two lists describe the same platform from different angles, and reading only one of them is how people end up surprised by what their array integration is called.
My guidance is by estate shape and it is deliberately dull. If you already run a Fibre Channel fabric with trained staff and spare ports, present LUNs over Fibre Channel and build clustered datastores on them, because the fabric you have is worth more than the protocol argument you would be having. If you are buying storage connectivity rather than inheriting it, or you are attaching to an Alletra array, use iSCSI on a dedicated, non-routed, jumbo-framed storage network with multipathing, because that is the shape HPE’s own material recommends for these estates and it is the path the tooling is most exercised on. If your cluster is small and your workloads are not storage-bound, NFS is a legitimate answer that buys you a two-host floor and a much simpler failure mode. Use Ceph when converged is a deliberate choice about hardware footprint rather than a way of avoiding a storage purchase.
Three details about Ceph on this platform will change a bill of materials. Memory is consumed per data disk, budgeted at four gigabytes for each one, so a dense node is a memory purchase before it is a capacity purchase. The documentation asks for a data disk of at least five hundred gigabytes for testing and is explicit that production wants more. And the disks are given to the platform raw: the guidance says not to RAID them on physical servers, and multiple devices per host are specified as a comma-separated list when the cluster is built. That last point matters because the older documentation layer restricted a host to a single data device, and practitioner reports through the 8.1 line still describe that limit. The current documentation does not carry it. If you are sizing a converged cluster on the strength of a blog post from earlier this year, check it against the version you are actually deploying.
The Alletra plugin is the most interesting thing in the storage story and also the most misread. Removing the clustered filesystem in favour of a volume per virtual machine disk is a real architectural simplification: snapshots, clones and replication become array operations on the object you actually care about, and the failure domain stops being a shared filesystem. The documentation also covers active-active peer persistence between two arrays with a quorum witness at the array layer, which is a credible metro story for people who already own the hardware, and which carries real conditions: replication targets are synchronous only, the mapping is strictly one to one, and the arrays have to be on a current operating system release. What the plugin is not is a modern-transport story. The stated prerequisite, in the current documentation, is that every array iSCSI port is reachable from every cluster host. Fibre Channel appears in that integration only for array-to-array replication, not for the host data path.
NVMe over Fabrics is not a choice you are making on VME. It is a protocol the platform does not document as a datastore path at all, and you should treat it as a gap to watch rather than a box to tick.
That deserves stating plainly rather than being left as an absence. The industry has moved to NVMe over Fabrics; vSphere consumes NVMe over TCP as a first-class datastore transport, and HPE’s own Alletra MP arrays speak NVMe natively. VME, as documented today, offers no NVMe over Fabrics datastore path by any route, including the Alletra plugin that would have been the obvious place for one. The practical consequence for most estates is small, because iSCSI on a properly built ten-gigabit storage network with jumbo frames and multipathing is not the bottleneck in a mid-market virtualisation estate, and it will not be the reason your database is slow. The consequence for the platform’s positioning is larger, and it is the kind of gap that gets closed in a release rather than a generation. Watch the release notes, and do not let a vendor conversation imply the capability exists today.
Two documentation seams are worth knowing about because they will confuse someone on your team. The Deployment Guide’s supported-storage-protocols page lists local, external block, NFS, the Alletra plugin and SimpliVity, and does not mention Ceph at all, while the user manual’s cluster pages configure Ceph as the converged answer and the ports table carries its daemons. Both pages are current. Read the cluster documentation for what a converged cluster does and the protocol page for what an external one connects to, and do not conclude from the omission that converged has been withdrawn. The second seam is in the host requirements themselves: the Deployment Guide asks for eight gigabytes of memory and a hundred gigabytes of operating system storage, and the user manual’s hardware requirements page still says four and fifteen. Build to the larger numbers and move on.
Networking: the host operating system is the source of truth
[VME 3] made the argument that there is no distributed switch object here, and I am not going to make it twice. What matters architecturally is the direction authority flows. The manager builds Open vSwitch bridges and libvirt networks when it provisions a cluster, and afterwards you add port groups through it, but it does not discover network interfaces that the host operating system does not already know about. A new interface has to exist in the host’s netplan configuration, be applied there, be assembled into a bond through the platform’s own host console utility, and only then does refreshing the cluster surface it to the manager.
Read that as a statement about ownership rather than as a limitation. On vSphere the distributed switch was the authority and the host was a follower, which is why an ESXi host with a broken uplink was a problem you solved from vCenter. Here the host is the authority for physical connectivity and the manager is the follower for virtual connectivity. Your runbooks, your configuration management and your change control need to reflect that split, because the failure mode is not an error, it is an interface that simply never appears in the interface picker and an engineer who assumes the product is broken.
The recommended topologies are unglamorous and correct. Four interfaces across two cards and two switches gets you full redundancy with management and virtual machine traffic converged on one bond and storage kept separate. Six or more lets you decouple management from compute onto their own bonds, which is what I would specify for anything I expected to grow. The two bond modes HPE calls out for virtualisation are active-backup and LACP, and LACP means the switch pair has to be joined into one logical switch, which turns a host decision into a network-team project and is the usual reason active-backup wins in practice.
Storage is not bonded, and HPE’s guidance says so directly, because the host’s storage layer already handles multipathing to the array and a bond underneath it is two mechanisms competing for one job. The two storage interfaces sit on different subnets, they normally land on untagged access ports, they carry no gateway because the storage network should not route, and they run at a nine-thousand-byte MTU end to end. Clustered storage traffic is documented as requiring ten gigabits with jumbo frames, and the documentation says outright that performance is unlikely to be acceptable below that. Every one of those is a sentence somebody eventually violates in a hurry, and each violation produces a symptom that looks like a storage array fault rather than a network one.
The tagging question is where installations go wrong, and it goes wrong at cluster creation rather than at install. The management interface you hand the cluster is the tagged one; the compute interface is the bond with no tagging on it, and the documentation calls selecting the untagged bond crucial for letting VLANs flow through the virtual switch. What it does not spell out is the failure, which follows from the design: get the pair the wrong way round and the cluster builds successfully and then cannot carry virtual machine traffic on any VLAN. That is a diagnosis worth an afternoon if you did not know to look for it. [VME 4.1] names it as a step with a check attached.
Placement is a small set of dials, and you own the consequences
Dynamic placement is on or off as a cluster property, and at 9.0 it acquired aggressiveness profiles named Conservative, Moderate and Aggressive together with migration cooldowns, balancing on memory utilization. That is a narrower input than the multi-dimensional cost function vSphere’s balancer used, and narrower is not automatically worse: memory is the resource that actually runs out in most estates, and a balancer with one clear input is a balancer whose behaviour you can predict. Cooldowns exist because the failure mode of any automatic balancer is thrash, and having the dial exposed rather than hidden is the right call.
Underneath that sits a second dial most people miss. vCPU placement has three settings: Unmanaged, which makes no attempt to keep a virtual machine’s threads together; Region, which attempts to keep them inside one NUMA region while allowing them to move between cores; and Pinned, which fixes them to cores. HPE’s own guidance is to start at Region absent a specific reason, and its internal testing reports a seven to ten percent improvement over Unmanaged on a synthetic compute benchmark. Take the number as an indication of direction rather than a promise about your workload, but take the setting seriously, because it is a cluster-level default that will quietly shape every virtual machine you provision afterwards. Power policy is the third dial, defaulting to balanced, with a performance mode that reduces network latency and drives CPUs harder, and it requires a recent enough host agent to take effect at all.
None of these is difficult. All of them are cluster properties set once and inherited forever by workloads nobody revisits, which is exactly the category of decision that deserves a deliberate answer in a design document rather than a default accepted in a wizard.
Stretching across sites, and what the arbitration actually does
The 9.0 generation added stretched clusters, and the documented requirements are more demanding than the headline suggests. Six hosts minimum, three at each site, plus a witness at a third location that is a Morpheus Distributed Worker rather than a lightweight appliance, plus network paths that let every host reach the witness, the manager and each other. Quorum operates at two layers, inside a site and between sites.
The arbitration behaviour is worth reading before you commit, because it is deterministic in a way that will surprise people who expect a weighted decision. A site is considered failed when every non-witness node there has been unreachable for sixty seconds. A surviving site that cannot reach the witness fences itself rather than assume it won. A surviving site that can reach the witness proceeds, and where the tie needs breaking the winner is the site that sorts first alphabetically. The loser stops its locking and membership services and stays down until it has been healthy for three consecutive ping cycles, roughly three minutes, at which point fenced nodes reboot and rejoin.
Alphabetical tie-breaking is a defensible engineering choice and a slightly startling operational one, because it means your site names are an availability parameter. If you have a primary datacentre and a secondary, and the secondary’s name sorts first, the platform’s tie-break prefers the site you would not have chosen. That is not a defect, and there is a witness precisely so that genuine tie-breaks are rare. It is simply a thing to know before you name things, and naming is free to get right on day one.
The decisions that are expensive to reverse
Strip the architecture back and four decisions carry most of the long-term weight. The manager size, because it caps how many clusters this control plane is meant to hold and because resizing it later is done under load. The cluster layout, because the path from 1.2 to 1.3 is one-way past its first phase and because it determines what owns your failover. The datastore type, because it sets your host floor, your failure domain and, as [VME 6] will show when it gets to the ecosystem, whether your backup vendor can protect the workloads sitting on it. And the network topology, because bonds, tagging and storage separation are decided at install and cluster creation, and revisiting them means touching every host.
Everything else on this platform is genuinely adjustable. Placement profiles, vCPU policy, power policy, adding hosts, adding datastores, adding networks: all of that is Tuesday-afternoon work. The four above are the ones I would want written down, argued once, and signed off before anybody mounts an ISO. [VME 4.1] takes exactly that path end to end, from the install medium to a running virtual machine with a validation that proves the cluster does what the diagram claims.
VME
‹ Previous: [VME 3] Speaking VMware: The Translation Layer
Next: [VME 4.1] Build Sheet: The VME Cluster End to End ›
