Dedicated hosts under a vCenter that belongs solely to you — vCenter is the management instance of vSphere. If a host fails, HA restarts the affected guests. DRS distributes the load during operations, vMotion clears a host before maintenance. The price is per host — and vSphere requires 2 of them.
The entry price is a host price, not a cluster price. PC-S32 is not approved under vSphere: the class has no separate storage fabric and therefore no shared datastore. Without it, HA will not restart anything.
The pages on hyperconvergence and data storage answer the same four questions in the same place. The answers are different — especially the second one.
The price of a managed host is the bare metal plus platform operations. The vSphere licence is deliberately not included: it is tied to the stack, not the host, and is billed per core and month.
The entry level is €1,498.20$1,737.91 — and that is the price of one host of the PC-M64 class, not of a cluster. vSphere requires 2 hosts, because otherwise HA has nowhere to restart a failed guest. The smallest permitted cluster therefore costs €2,996.40$3,475.82 net per month, not yet including a datastore.
The licence costs €9.90$11.48 per core and month, with a minimum purchase of 16 cores per socket. On PC-M64 that is 48 cores and thus €475.20$551.23 per host and month. The minimum purchase does not apply to any approved class in today's catalogue — the smallest has 48 cores per socket. It is an assurance in case a smaller class is added, not a hidden surcharge.
Billing by cores means: consolidation saves nothing on the licence. 96 cores cost the same whether they are in one or two sockets. What differs is the operations — two hosts meet the minimum cluster size, one does not.
The licence share of the platform in the entry-level cluster is 32%. That is the figure that makes the difference to an open hypervisor — not the host price, which is the same in both cases.
2 × PC-M64 with a shared Datastore NVMe Standard via 4 TB — the smallest configuration in which HA actually does something.
Both stacks run on the same bare metal. The difference is not in the hardware, but in what the management plane itself does in operations — and in what that costs per core. On PC-M64, it is €49.00$56.84 against €475.20$551.23 per month.
| Feature | ENTRONYX KVM PlatformOpen platform | ENTRONYX Managed vSphereThis stack |
|---|---|---|
| Licence model | per socket and month | per core and month |
| Licence rate | €49.00$56.84 | €9.90$11.48 |
| Licence per PC-M641 sockets, 48 cores | €49.00$56.84 | €475.20$551.23 |
| Cluster from … to | 1 – 16 hosts | 2 – 32 hosts |
| Approved host classes | 5 | 4 |
| Continuous load balancing in operationsDRS moves guests without anyone intervening | ||
| HA restart after host failure | ||
| Live migration within one CPU generation | ||
| Dedicated management instance per tenant | ||
| Synchronous Metro mirroring bookableRPO 0 minutes | ||
| Maintenance windows | Tue and Thu 02:00–05:00 CET, announcement 10 calendar days in advance | Wed 02:00–06:00 CET, rolling host by host, announcement 14 days in advance |
Those running vCenter today bring templates, roles, port groups and operating procedures with them. The move is a relocation, not a redevelopment: export and import in the open exchange format OVF lead to the same object tree.
Databases that are licensed by physical cores need a hard mapping of guest to host. Affinity rules on the cluster keep the affected guests on designated hosts instead of letting them migrate across the entire cluster.
Dedicated vCenter, dedicated Distributed Switch, dedicated datastores: the separation lies in separate objects, not in a permissions rule on shared ones. This can be demonstrated in an audit.
For a single host, for development environments without availability requirements, and for workloads that run containerised anyway, the per-core licence is the most expensive way to reach your goal. The KVM platform or managed Kubernetes is the right choice there.
Each class is dedicated bare metal with a fixed allocation of cores, memory, local NVMe and connectivity. The total includes host and licence together — the amount that appears on the invoice per host and month.
Host classes under ENTRONYX Managed vSphere with CPU, allocatable memory, local NVMe, connectivity, vCPU limit, licence and monthly price per host — all amounts net.
EPYC 9454P2.75 – 3.80 GHz · 1 sockets
Xeon 6741P2.50 – 3.80 GHz · 1 sockets
EPYC 95543.10 – 3.75 GHz · 1 sockets
2× EPYC 99652.25 – 3.70 GHz · 2 sockets
| Class | Processor | Cores / threads | Allocatable RAM | Local NVMe | Connection | vCPU cap | Licence / month | Total / month |
|---|---|---|---|---|---|---|---|---|
| PC-M64EntryPC-M | EPYC 9454P2.75 – 3.80 GHz · 1 sockets | 48 / 96 | 232 GB | 3.84 TB | 1 Gbit/s | 288(6:1) | €475.20$551.23 | €1,498.20$1,737.91 |
| PC-M64iPC-M | Xeon 6741P2.50 – 3.80 GHz · 1 sockets | 48 / 96 | 232 GB | 7.68 TB | 1 Gbit/s | 288(6:1) | €475.20$551.23 | €1,568.20$1,819.11 |
| PC-L128PC-L | EPYC 95543.10 – 3.75 GHz · 1 sockets | 64 / 128 | 472 GB | 7.68 TB | 5 Gbit/s | 256(4:1) | €633.60$734.98 | €2,532.25$2,937.41 |
| PC-X256PC-X | 2× EPYC 99652.25 – 3.70 GHz · 2 sockets | 384 / 768 | 960 GB | 3.84 TB | 5 Gbit/s | 1,536(4:1) | €3,801.60$4,409.86 | €9,594.78$11,129.94 |
The allocatable memory is the installed memory minus the reservation for the hypervisor — on PC-M64 this is 24 GB of 256 GB. The proportion decreases with increasing capacity: PC-X256 holds back 64 GB of 1 TB.
Configure clusterA class without a stated limit is a class whose limit no one has looked for yet. Here it stands for each of the four.
One socket, one NUMA node: VMs over 232 GB RAM no longer fit on this class. For wider single VMs, PC-L128 or PC-X256 is the right fit.
Live migration is only guaranteed between hosts of the same CPU generation. A mixed cluster of PC-M64 (AMD) and PC-M64i (Intel) does not migrate during operations.
The boost ends at 3.75 GHz — the class wins on width, not on clock speed. Loads that depend on single threads run faster on PC-S32 with 5.7 GHz.
Two sockets mean two NUMA nodes. VMs over 480 GB RAM or over 192 vCPU exceed one node and lose around 12% memory bandwidth — with licences per core, this host also pays for 384 cores.
The classes differ in availability. PC-M64 is available at 4 locations, PC-X256 at 3. A cluster is always located entirely at one location — distributed clusters across two regions are only created via the recovery tiers.
Available for PC-M64 4
Every host class carries a guaranteed upper limit of vCPUs per physical core. Nothing is placed above this — not even briefly, not even during an evacuation.
The ratio becomes stricter the more densely the class is populated. On PC-M64, 6 vCPUs per core are guaranteed, on PC-X256 only 4. The reason is not compute performance, but memory bandwidth: it does not scale with the core count, and an overbooked core then waits for data instead of compute time.
Under vSphere, the permitted memory overbooking is 0% — on all approved classes. What you assign to a guest is physically present. Ballooning — the hypervisor reclaims unused memory from a guest — and memory compression remain active as emergency mechanisms. They are not part of capacity planning: the latency loss under load costs more than the gained memory is worth.
In practice, memory is therefore the binding limit, not the core count. Guests with 2 vCPUs and 4 GB fill PC-M64 after 58 guests — 116 of the 288 permitted vCPUs are then occupied.
The third limit is the number of guests itself. It does not depend on compute performance or memory, but on what every running guest permanently costs in administration: monitoring paths, network ports on the distributed switch, queues at the datastore. A cluster of 32 hosts of class PC-X256 mathematically supports 20,480 guests — the practical limit is set beforehand by the datastore.
Assignable, not recommended. If you want to keep an availability commitment, you plan for the failure of a host and stay below this.
Dedicated vCenter per customer, API access, SSO against your directory
Your environment is attached to its own vCenter instance, not a shared one with tenant filters. You see your clusters, your datastores and your task list — not someone else's, not even filtered.
If a host fails, vSphere HA restarts the affected guests on the remaining hosts. This is a restart, not an uninterrupted takeover: the guest loses its memory state and boots up again from its file system.
DRS moves running guests between hosts via vMotion if the distribution diverges. The same mechanism evacuates a host before maintenance: maintenance mode moves every running VM away before the host restarts.
The network is configured once on the cluster, not host by host. Each project gets its own port group with its own VLAN; a new host adopts the configuration upon joining, without you having to update it.
The boundary between your responsibility and ours lies at the top edge of the host: we maintain the hypervisor, firmware, fabric and storage controllers. Everything from the guest system upwards remains with you — unless you book a higher operations level. Both sides operate the vCenter itself; your roles are the same as those you know from your own installation.
Wed 02:00–06:00 CET, rolling host by host, announcement 14 days in advance. No window takes the cluster out of operation — it takes out one host at a time. The cost of this is in capacity: as long as one host is missing, the rest must carry the full load.
You receive the window, scope and the list of affected hosts. A window without changes to your cluster is cancelled, not silently run through empty.
One host is mathematically deducted from the cluster. If the running load does not fit on the remaining hosts, we postpone the window — instead of starting it and realising halfway through that the evacuation will not complete.
The host enters maintenance mode, DRS moves every running VM to another host via vMotion. The guests continue to run during this time; the duration depends on the used memory, not the number of guests.
BIOS, storage controllers, network cards and the ESXi build are upgraded to the target version. Afterwards, the host restarts and reports back to vCenter.
Only when a host is back in the cluster and DRS has redistributed the load does the next one begin. That is why the window takes longer with the cluster size — and why the cluster remains available throughout.
A host fails or is evacuated — in both cases, the load must fit on the remaining ones. This results in a hard upper limit for utilisation, and it is uncomfortable for small clusters.
The value is the utilisation at which the failure of exactly one host can still be absorbed. If you want to cover two simultaneous failures, you calculate with two missing hosts — with 2 hosts, this is not possible.
Without shared storage, there is no HA restart, no vMotion, and no maintenance-free evacuation. The datastore is therefore ordered together with the cluster, not afterwards.
Billing is per gigabyte and month, with a minimum commitment per class. The IOPS commitment — input/output operations per second — applies per datastore, not per guest. Larger environments are therefore split across multiple datastores instead of one large one.
NVMe over TCP for databases that depend on write latency.
Restriction: The IOPS guarantee applies per datastore, not per VM. A single guest only reaches it with at least four parallel queues; with one queue, around 28,000 IOPS remain.
The standard case: NVMe backend via NFS or iSCSI, for mixed guest workloads.
Restriction: From 24 concurrently active VMs on a datastore, the guaranteed latency drops from 0.9 ms to 1.4 ms. Larger environments are therefore split across multiple datastores.
NVMe cache in front of HDD capacity — for file services and quiet volumes.
Restriction: The NVMe cache covers 8% of the datastore size. Working sets beyond this pass through to the HDD tier; the 4 ms latency guarantee then no longer applies.
Under ENTRONYX Managed vSphere, all 4 levels are available — including synchronous mirroring, which other stacks do not get. Each level states its RPO, the maximum lost time period, and its RTO, the maximum required startup time. It costs a base amount per protected environment plus a rate on the protected capacity.
Nightly backup to a second EU region, restart on demand.
Restriction: The restart uses free capacity in the target region. Without booked capacity reservation, the RTO commitment only applies Mon–Fri 08:00–18:00; outside this time, there is no guaranteed restart time.
One standby host in the target region, replication every four hours.
Restriction: A single host runs in the target region with around 25% of the productive capacity. Full throughput is only available after adding more hosts — lead time up to 90 minutes.
Quarter-hourly block replication to a region in the same jurisdiction.
Restriction: The RPO of 15 minutes applies up to a change rate of 40 MB/s per datastore. Above this, the replication lag grows, and the actual recovery point is further back than committed.
No data loss: every write operation is acknowledged at both locations.
Restriction: Only available between fra1 and fra2. Every write operation costs around 0.3 ms extra, and logical errors are mirrored synchronously — this tier does not replace a backup, it complements it.
Platform operations are included in the host price and cannot be deselected. They end at a strict boundary: we work below the guest system, you work above it.
Firmware maintenance requires a host evacuation. Without a second host in the cluster, this means downtime of up to 45 minutes per maintenance window.
If you also want to hand over the guest system, book a higher operations level. The boundaries of the levels are on the managed hosts page.
The entry-level cluster of 2 × PC-M64 is therefore mathematically a one-host cluster: whatever runs on the second must be carried by the first during the maintenance window.
Host class, quantity, datastore, recovery level and operations level are side by side in the configurator. The total is calculated using the same rates shown on this page — there is no second price behind the quote.
