What is Private Cloud Software?

Evaluating private cloud software comes down to five capabilities:

• The virtualisation layer - the hypervisor and how it is driven.
• An API and portal - how workloads are created and who is allowed to create them.
• Tenancy and quota - how teams and projects are separated and limited.
• Metering - what was consumed, so chargeback or showback is possible.
• Integration points - identity, storage, network and backup systems it plugs into.

A sixth question cuts across all of them: how the platform reports consumption. Without metering, chargeback is guesswork - and a private cloud that cannot say what a project consumed behaves like a cost centre with an API.

The software is the same across settings; what changes is where the racks sit and who walks to them. Private cloud software is deployed in three common shapes:

• On-premise - the platform runs in a datacenter the organisation owns and staffs.
• Colocation - own hardware, own platform, a facility and network someone else operates.
• Hosted single-tenant - a provider operates dedicated infrastructure for one customer under contract, often called managed private cloud.

Each shape moves operational chores between in-house teams and a provider without moving control of the cloud layer: the tenancy, quota and image policy still belong to whoever operates the platform in that arrangement.

Because most of the category is open source, buying private cloud software is not one decision but two. The first is upstream: pick the project and accept its release cadence. The second is how much scaffolding to put around it - self-built packaging and runbooks, or a distribution that charges for tested builds, security backports and someone to call.

Neither route changes what the software does; they change who absorbs the undifferentiated work - upgrade testing, vulnerability triage, compatibility verification - and on whose timeline. Operators with mature platform teams routinely run upstream alone; regulated environments often prefer a supported distribution precisely so the maintenance story has a named owner.

The same question reappears at the hardware layer. Platform releases state the virtualisation and storage versions they support, so fleets drift toward combinations the project has tested; validating that matrix before an upgrade is unglamorous, unavoidable work in every arrangement described above.

Either way, the licence is not the cost centre: open source removes the purchase order, not the platform team. Buyers comparing options get further asking who will be running this in two years than asking what the software costs to download.

Running private cloud software means owning the lifecycle: procurement, upgrades, capacity headroom, and the people who keep it healthy. The alternative on the other side of the spectrum is renting private capacity from a provider - the same isolation without the operational ownership. Between them sits a useful middle: operators can offer single-tenant private capacity to the open market, and tenants can order it like any other listing. On VirtEngine, IaaS listings can express reserved capacity, dedicated quotas and network isolation, so a private cloud can be bought rather than built - or built, and then sold.

Private infrastructure narrows the trust boundary but does not remove the need to know who is inside it. On VirtEngine, both sides of a private-capacity order are VEID-verified before matching, and payment runs through escrow - so the software question and the counterparty question are answered together rather than one being left to a contract.

The same discipline applies inside the boundary: provider technicians and tenant administrators hold distinct roles, and a private cloud worth operating treats those roles as platform objects with their own permissions - not as shared credentials on a jump host.