Part one of this series said to judge every VMware alternative on four things: pooled capacity across hosts, live migration, shared storage, and one console. That was the easy part. Here are the answers for the model we run, including the one where the answer is “we do not have that”.
What Estate Are We Actually Talking About?
Almost every VMware environment we are asked to look at is the same shape: a vSphere cluster, shared storage behind it, and virtual machines running on top. Not vSAN. Not NSX. Not the full suite with operations tooling layered over it.
That matters more than any feature table, because the thing being replaced is much smaller than the vendor diagrams imply. The organisations running the entire stack — and depending on it — are mostly not the ones shopping. They have too much invested in the tooling, and they are not the audience for this post.
So the honest comparison is a plain cluster against a reserved pool, not a VMware Cloud Foundation deployment against anything.
Does the Capacity Still Pool Across Hosts?
Yes, and that is the whole design. A Virtual Data Centre is a block of vCPU, memory and storage reserved for one tenant and isolated from every other one — an isolated pool rather than a set of machines. You create whatever you like inside the allocation: twelve small VMs or three large ones, same invoice either way.
This is the piece that makes it feel like a cluster rather than a pile of cloud instances. Capacity is a budget you spend on shapes, not a shape you buy repeatedly.
What Happens When a Host Is Patched?
Virtual machines move off the host before it is touched, and keep running. Hardware and hypervisor maintenance does not cost you a maintenance window, which is the single behaviour most vSphere admins are worried about losing.
It is worth being clear about who does that work. On your own cluster, patching is your evening. Here it is ours, and the VMs move whether or not you were told it was happening.
Is the Storage Still Shared?
Yes — storage is visible to the whole pool rather than attached to one machine, which is what makes the migration above possible in the first place. If storage were local to a host, nothing could move without stopping.
The practical difference from a traditional SAN is that capacity is part of the same allocation as the compute. VDC Starter is $499 a month flat for 20 vCPU, 64 GB of RAM, 2 TB of storage, 2 TB of traffic, four public IPs and a virtual router. There is no separate array to size, refresh, or run out of.
Is There One Console?
Yes. Cloud Control is where the pool, the VMs, the private network, the security groups and the router all live, and it is self-service — adding a subnet is not a support ticket.
It is not vCenter, and the first fortnight will feel like someone moved the furniture. That is a real cost and it is worth planning for, but it is a training cost, not an architectural one.
What You Gain That vSphere Standard Does Not Give You
This is the part most people have backwards. They assume leaving VMware means dropping to something smaller. Against the edition most of these clusters actually run, it is the other way round.
- Software-defined networking. Private VXLAN networks, security groups and a virtual router, all self-managed. vSphere Standard does not do this — it is what NSX is sold separately for.
- Three sites. Dubai DX1, Fujairah FJ1 and Vienna VIE2, with a pool in one or split across two for data residency or a second copy.
- A flat price for the pool. No per-VM licence arithmetic, and no renewal that reprices the same hardware.
What You Give Up
There is no operations and analytics layer. No equivalent of the VMware Operations tooling — no capacity what-if modelling, no recommendation engine, none of that family. You get the platform and the console that runs it.
If your team lives in that tooling, this is a straight downgrade and you should not move. That is not a sales caveat in small print; it is the clearest signal of whether this is for you. An estate that runs a cluster and some VMs will not miss it, because it was never licensed in the first place. An estate built around capacity analytics will miss it on the first day.
Why a Hyperscaler’s VPC Is Not This
Worth repeating briefly, because the word does the damage. At a hyperscaler, a VPC is a software-defined network boundary: private address space, subnets, route tables. It is free, because it is a configuration object rather than a resource, and your machines still run on hypervisors shared with other customers.
A reserved pool is capacity held for you. One is about packets, the other about contention. Only the second is the shape of a cluster. Part one went through this in more detail, as does our earlier piece on what a virtual private cloud actually reserves.
How to Tell Whether You Are the Customer
- List what you actually licensed. If the answer is vSphere and shared storage, the replacement is smaller than you think.
- Ask who patches hosts today, and when. If that is an evening your team gives up, that cost moves rather than disappears.
- Name the tooling your operations people open daily. If capacity analytics is on the list, stop here.
- Check whether you are using NSX-class networking. If you are not, you gain it; if you are, map the features one by one before committing.
- Count the VMs that cannot tolerate a reboot. That number decides how careful the cutover has to be, which is part five.
What This Is Not
It is not a managed private cloud on your own hardware — that is a separate tier and a design engagement rather than a plan you order. It is not a public-cloud instance pile, which is what you get if you lift and shift to a hyperscaler and pay per VM. And it is not vCenter with a different logo: the concepts map, the screens do not.
Next in the series: Proxmox, including the places it does not fit — and we sell it, so that list is worth reading.
If you want to know which of these your estate maps onto, tell us what you are running and we will tell you — including when the answer is to stay where you are.
