Private Cloud Showdown: Picking the Right Platform

June 3, 2026 14 min read Virtualization & Containers

private-cloudvirtualizationopenstackproxmoxhomelabinfrastructure

Contents

This private-cloud series opened with a promise: nine deep-dives, then a head-to-head that puts them all on one table and tells you which to actually run. This is that post. If you have read the others — OpenStack, CloudStack, OpenNebula, Harvester, Incus/LXD, XCP-ng, oVirt, cloud-like Proxmox, and MAAS — this is the synthesis. If you have not, this is the map that tells you which one to go read.

The single most important thing to say up front is the thing the comparison blogs bury: the right answer is almost never the most powerful platform. It is the smallest one that covers the capabilities you actually need. Most people asking “should I run OpenStack?” should run something else, and most of this post is an argument for matching the tool to the scale honestly.

The one test that sorts the field

The series’ recurring thesis bears repeating because it organizes everything below. The feature that separates a cloud platform from a cluster manager is the placement scheduler — the component that, when you ask for a VM without naming a host, decides on its own which physical machine runs it. VMware sells this by name as DRS. It is the thing people mean when they say “AWS at home.”

Sort the nine platforms by that test and the field splits cleanly:

  Real scheduler (it picks the host)          Pool placement / partial         You pick the host
  ──────────────────────────────────          ────────────────────────         ─────────────────
  OpenStack   (Nova filters + weighers)        Incus/LXD (least-loaded          Proxmox  (name the
  CloudStack  (planner)                          member, no rebalance)            node at create;
  OpenNebula  (match-making)                    XCP-ng    (load-balance via       HA only rebalances
  Harvester   (Kubernetes scheduler)             XO, premium/manual)              after a node dies)
  oVirt       (scheduling policies)
  MAAS        (allocates *hardware* by
              constraint — different object)

This is not a quality ranking — Proxmox is an outstanding platform that happens to sit on the “you pick” side. It is a capability axis. If automatic placement is the feature you came for, the left column is your shortlist and most of the right column is disqualified by definition. If you do not actually need a machine to choose hosts for you — and many people do not — the axis stops mattering and ease and ecosystem take over.

The scorecard

One table, seven axes, rated 1–5 (5 is best — for “Setup ease,” 5 means easiest to stand up). These are opinionated ratings drawn from the deep-dives, not benchmark numbers; treat them as a relative map, not gospel.

Platform	Setup ease	Scheduler	SDN	Storage / Ceph	Multi-tenancy	UI / API	Community
OpenStack	1	5	5	5	5	4	5
CloudStack	3	4	4	4	5	4	3
OpenNebula	4	4	3	4	4	4	3
Harvester	3	4	3	3	3	4	4
Incus / LXD	5	3	4	4	3	4	4
XCP-ng + XO	4	2	3	3	3	5	4
oVirt	2	4	3	3	3	4	2
Proxmox VE	5	1	4	5	2	5	5
MAAS	2	4*	2	—	2	4	4

* MAAS schedules physical machines by hardware constraint, not VMs — a real scheduler aimed at a different object. Its storage cell is “—” because MAAS provisions disks and can deploy Ceph for you, but it is not itself a software-defined storage layer. Read its row as “the foundation under the others,” not as a peer competing for the same VM workload.

A few honest notes on the numbers, because a bare table lies by omission:

OpenStack’s 1 for setup is not a typo. It is the most capable platform on every other axis and the hardest thing in this entire series to stand up and keep standing. The fives across the rest of its row are real; you pay for every one of them in operational labor. Tools like Kolla-Ansible or Canonical’s Sunbeam soften the install, never the operation.
Proxmox’s 1 for scheduler is also not a typo — and it is the most popular platform here anyway. That single low cell is the entire reason the cloud-like Proxmox post exists. Even Proxmox VE 9.2’s new Dynamic Load Balancer only rebalances HA-managed guests after they start; it still does not pick the best node at provision time. For most homelabs that gap is irrelevant, which is why the fives in the same row matter more.
Incus’s 5 for setup is the quiet winner of the whole table. It is the only platform that is genuinely easy to stand up and places workloads for you, even if that placement is “least-loaded member” rather than a constraint engine. That combination is why it is the right answer far more often than its modest scheduler score suggests.
oVirt’s 2 for community is the saddest cell. Its scheduler is genuinely a 4 — real affinity, balancing, and power-saving policies — but Red Hat’s RHV end-of-life (August 2026) and the platform’s uncertain future drag the whole proposition down. A great engine is worth less when you are unsure who maintains it next year.

One line each

Strip the table down to its personality and you get the thirty-second version:

OpenStack — the real private AWS. Everything, done properly, at a price measured in headcount. Right when “cloud-grade” is a requirement and you can staff it.
CloudStack — the underrated workhorse. Most of OpenStack’s multi-tenant cloud at a third of the operational pain. The best-kept secret for providers and serious shops.
OpenNebula — the pragmatic middle. A genuine scheduler and a clean UI without the sprawl. “A real cloud, but I want to sleep at night.”
Harvester — the cloud-native bet. KubeVirt VMs and containers under one Kubernetes-shaped roof. Right if your future is Kubernetes anyway and you will pay its weight as rent.
Incus / LXD — the low-effort sweet spot. Easiest real path to self-service-with-placement for mostly-Linux workloads. Punches far above its install effort.
XCP-ng + Xen Orchestra — the polished refuge. The natural home for Citrix Hypervisor refugees; a beautiful UI over a mature XAPI, with placement as the weak spot.
oVirt — the great engine with an uncertain home. The best open scheduling policies here, shadowed by RHV’s sunset. Lean to OLVM if you need it supported.
Proxmox VE — the default for a reason. Easiest, best Ceph integration, huge community — with no provision-time scheduler. The right answer for the overwhelming majority of homelabs and SMBs.
MAAS — the floor under everything. Not VMs at all: bare metal as a pool you allocate from. Lay any of the above on top.

Recommendations by scenario

This is the part that matters. The platform is downstream of your scale, your workloads, and your tolerance for operating infrastructure as a second job. Find your row.

Single-node homelab (one box, maybe a NUC or an old tower)

Run Proxmox VE. Full stop, for almost everyone. With one node there is no cluster to schedule across, so the entire “does it have a scheduler” axis evaporates — the one thing Proxmox lacks is the one thing a single node cannot use. You get a superb UI, snapshots, backups via Proxmox Backup Server, LXC containers and KVM VMs, and the biggest community in the space. If your workloads are mostly Linux and you want the cloud feel — incus launch and a container exists in a second — Incus is the other excellent single-node pick, lighter than Proxmox and scriptable to the bone. Everything else on this list is overkill on one machine; deploying OpenStack on a single node is a learning exercise, not an infrastructure decision.

Three-to-five-node homelab (the HCI sweet spot)

This is where it gets interesting, because now you have a cluster and the scheduler axis comes alive.

Want it boring and bulletproof? Proxmox VE + Ceph. The hyperconverged Proxmox+Ceph build is the canonical homelab cloud: three identical boxes, shared storage, live migration, HA failover. You still name nodes at create time, but at three nodes a five-line placement script (see the cloud-like Proxmox post) closes the gap.
Want real auto-placement with low effort? Incus/LXD clustering. It lands instances on the least-loaded member automatically and the operational weight is feather-light. The best “self-service that picks for you” per hour of setup.
Want a genuine cloud to learn on? OpenNebula or CloudStack. Both give you a real scheduler, multi-tenancy, and an API without OpenStack’s operational tax. OpenNebula is the gentler on-ramp; CloudStack is the one that scales into a provider later.
Betting your career on Kubernetes? Harvester. If everything you build is heading toward Kubernetes anyway, running VMs as Kubernetes objects via KubeVirt stops being overhead and starts being consistency.

SMB (a business that needs this to stay up, with limited ops staff)

The deciding variable is who operates it at 2 a.m. A business pays for reliability and a support phone number, in money or in salaried time.

Default: Proxmox VE, ideally with a support subscription and a tested VMware migration path. It is the lowest-risk open-source choice for a small team, and the commercial support makes it defensible to a CFO.
If you are a hosting/service provider selling tenants: CloudStack. Multi-tenancy, accounts, domains, and billing hooks are its native language in a way Proxmox’s pools and ACLs are not.
If you are deep in the SUSE/Rancher world: Harvester, with commercial backing from SUSE.
Avoid standing up OpenStack with a two-person team. The platform is magnificent and it will eat both of those people. If you need OpenStack’s capabilities at SMB scale, buy it as a managed/hosted private cloud rather than running the control plane yourself.

Enterprise (real scale, dedicated infra team, compliance)

Now the calculus inverts: you have the staff, and the cost of not having cloud-grade capabilities (true multi-tenancy, quotas, SDN, IAM, metering) exceeds the operational cost of running them.

OpenStack is the open-source answer at this tier and essentially the only one that does all eight cloud capabilities seriously. Run it via Kolla-Ansible or Canonical’s Sunbeam/Charmed OpenStack, ideally on a MAAS-managed bare-metal fleet so the hardware layer is also self-service. The current 2026.1 release is mature; the operational discipline is the hard part, not the software.
CloudStack remains a serious enterprise option, especially for service providers, and is dramatically cheaper to operate than OpenStack while covering most of the same ground.
MAAS underneath everything. At enterprise scale, the bottom of the stack — turning racks of steel into an allocatable pool — is itself worth automating. MAAS is the layer that makes the hardware feel like a cloud so OpenStack or Kubernetes can sit on top.
The honest commercial baseline: if you are already on VMware and the migration cost exceeds the license savings, staying may be rational even after Broadcom’s price hikes. Run the numbers, do not run on principle.

“Just use Proxmox” — and when not to

It deserves its own heading because it is the correct answer so often that ignoring it would be dishonest. For the overwhelming majority of homelabs and a large fraction of SMBs, the entire decision tree above collapses to: install Proxmox VE, add Ceph if you have three nodes, and get on with your life. It is the easiest to run, has the best storage story, the largest community, commercial support if you need it, and a real migration path off VMware. The only thing it does not do is pick hosts for you — and below a few dozen nodes, you genuinely do not need it to.

The signals that you have actually outgrown Proxmox and need a real cloud platform are specific, and you should be able to name at least one before moving:

You need true multi-tenancy — isolated projects with their own quotas, users, and networks — not just folders and ACLs.
You need automatic placement and rebalancing across enough nodes that hand-placing VMs is a real bottleneck.
You need software-defined networking with tenant overlays, security groups, and floating IPs as first-class API objects.
You need a self-service API that internal teams or customers consume directly, with metering behind it.

If none of those is true, reaching past Proxmox is buying complexity you will pay for and not use.

“Just pay for it” — the vSphere / Nutanix case

The series exists because Broadcom’s VMware changes — subscription-only, per-core pricing with a 16-core-per-CPU floor, bundled editions, late-renewal penalties — reopened a question many shops considered closed. But the honest finale has to include the cases where the answer is still write the check:

You lack the ops headcount and the workloads are business-critical. VMware vSphere with DRS and vSAN, or a Nutanix appliance, genuinely does the automatic-placement and HCI thing more smoothly than any open-source option, with a vendor on the hook when it breaks. That reliability is a real product, not just lock-in.
Your migration cost exceeds the license delta. Re-platforming hundreds of VMs, retraining staff, and rebuilding runbooks is not free. Sometimes the renewal, even inflated, is cheaper than the project to escape it.
Compliance or vendor requirements mandate a supported commercial stack. Some audits and some software contracts simply will not accept “we run it ourselves.”

The trade the entire series describes is money for operational effort. Open-source private cloud has no license fee and a significant labor bill; commercial virtualization inverts that. Neither is free. Pick the side of that line your actual situation sits on, not the side that feels more impressive.

Migration paths and TCO — the part the demo skips

Two realities every comparison glosses over.

Migration is rarely a clean cutover. The realistic moves between these platforms:

VMware → Proxmox is the best-trodden path in 2026, with native import tooling for VMDKs and a documented SMB playbook. This is the migration most people in this audience are actually doing.
VMware → OpenStack / CloudStack is a re-platforming project, not an import — new networking model, new storage model, new operational culture. Budget months, not a weekend.
Citrix Hypervisor → XCP-ng is close to a drop-in; the XAPI lineage makes it the gentlest migration here.
RHV → OpenShift Virtualization or OLVM is the path Red Hat is pushing oVirt-adjacent shops toward as RHV sunsets in August 2026.
Anything → Anything at the VM level is eased by sticking to standard disk formats (qcow2/raw) and cloud-init, which most of these platforms speak.

Total cost of ownership is dominated by labor, not licenses. The demo shows you a VM booting in ninety seconds. It does not show you the upgrade that wedges the control plane, the Ceph rebuild that competes with production for network bandwidth, the 2 a.m. page, or the engineer-months of expertise the platform demands before it is trustworthy. The rough shape of real cost:

   "Free" open-source private cloud TCO
   ────────────────────────────────────
   License .................. $0
   Hardware ................. one-time, knowable
   Operational labor ........ the actual price ───────────────►  (grows with platform complexity)
   Expertise / ramp ......... months for OpenStack; a weekend for Proxmox
   Downtime risk ............ inversely proportional to your ops maturity

OpenStack’s license bill is zero and its TCO can exceed a VMware renewal once you price the team. Proxmox’s TCO is genuinely low because the labor line is small. That difference — not any feature on the scorecard — is what should drive the decision for most organizations.

The verdict

If you read only this paragraph: most people should run Proxmox VE, add Ceph at three nodes, and stop there. If your workloads are mostly Linux and you want auto-placement for nearly free, run Incus/LXD. If you genuinely need a multi-tenant cloud with a real scheduler and can spare the operations, OpenNebula or CloudStack hit the balance OpenStack overshoots. Run OpenStack only when cloud-grade capabilities are a hard requirement and you can staff the platform like the product it is. Reach for Harvester if your world is Kubernetes, XCP-ng if you are fleeing Citrix, and oVirt only with eyes open about its future. Put MAAS underneath any of them when the hardware layer itself needs to become a self-service pool. And when the math says the renewal is cheaper than the escape, paying VMware or Nutanix is not a failure — it is the same money-for-effort trade, settled the other way.

The cloud feeling — type a command, capacity exists, something else decided where — is reproducible on your own hardware. The series has shown nine ways to get some or all of it. The discipline is wanting only as much of it as your problem actually requires, and being honest that the API was always the easy part. The operations are the product you are really buying, whether you pay for them in dollars or in your own evenings.

That is the series. Go build the smallest cloud that solves your problem.