Which open-source platform replaces VMware Cloud Director for a provider's tenants?
If you run tenant clouds on VMware Cloud Director (VCD), the search usually starts with a renewal, a price change or a wish to stop depending on one vendor's tenancy model. For that job, three open-source platforms are the realistic candidates: Apache CloudStack, OpenNebula and OpenStack. Each one handles tenants differently. CloudStack organizes users into accounts and domains with resource limits and native accounting, and it can manage vSphere and KVM side by side under one API. OpenNebula offers multi-tenancy, self-service and multi-zone federation on a KVM-centred model with Sunstone as its portal. OpenStack provides projects, quotas and a broad set of APIs, but it is a larger system that needs a bigger operations team.
Timing matters. Broadcom's knowledge base lists VMware Cloud Director 10.6.2 and VMware Cloud Director Availability 4.7.6 with an end of service date of August 12, 2028. That leaves a defined window to decide, pilot and move tenants, and the window is shorter than a full platform change usually takes when it is planned late. Confirm the end of service date against your own contract and the current Broadcom notices before you build the plan around it.
The right choice depends on three things you can check now: your hypervisor mix (vSphere only, or KVM and Xen alongside it), the skills your team already has, and what your tenants expect from the API and portal. If tenants script against the VCD API, map each call they use to the CloudStack, OpenNebula or OpenStack equivalent before you choose. Ask each candidate for a proof of concept that runs one real tenant workload, with its quotas, networks and usage reports, before you commit.
How each open-source platform covers VCD capabilities
This table maps the tenant-facing capabilities a provider relies on in VMware Cloud Director to Apache CloudStack, OpenNebula and OpenStack. Read each cell as a starting point for a proof of concept, since portal, quota and billing depth must be confirmed in each platform's own environment. The main takeaway is that every option covers the core model, but the gaps sit in self-service portal behavior, usage billing and identity design.
| Capability | Apache CloudStack | OpenNebula | OpenStack |
|---|---|---|---|
| Tenant and account model | Accounts, domains and users with native user and account management | Multi-tenancy through users, groups and ACLs; confirm the tenant hierarchy you need | Projects, domains and roles in Keystone; design the mapping before onboarding tenants |
| Quotas and resource limits | Resource limits per account and domain; verify CPU, memory, storage and network limits in your version | Multi-tenancy is documented, but quota depth is not confirmed in the sources; test per-tenant limits | Per-project quotas for compute, block storage and network; set defaults and review them per release |
| Self-service portal | Web interface for end users and administrators; confirm the user-facing workflows you sell | Sunstone web UI with tenant views; confirm what end customers can do without admin rights | Horizon dashboard is the usual portal; plan branding, catalog and onboarding work separately |
| Multi-tenant networking | Network-as-a-Service with isolated networks per account; confirm VPC and firewall features needed | Virtual networks assigned to tenants; confirm isolation and multi-zone federation for your design | Neutron networks per project with overlay isolation; requires a deliberate network design |
| Usage accounting and billing | Resource accounting is native; billing rating and invoicing usually need an external tool | Accounting and showback depth must be confirmed; plan an external rating engine | Ceilometer-era metering has changed; plan usage collection and rating with a separate system |
| Hypervisor support | KVM, XenServer, Xen, Hyper-V, vSphere and LXC in one management layer | KVM as the main hypervisor, with LXC support | KVM through Nova; confirm driver support for any other hypervisor you keep |
| APIs and automation | Native query API, CloudMonkey CLI and Terraform and Kubernetes providers | XML-RPC API with Ruby, Java, Go and Python bindings, plus OneFlow and CAPONE | Native REST APIs for each service, plus client libraries and Terraform community providers |
| High availability | Management server and host redundancy; confirm the HA design for your zone layout | Front-end and host node high availability as listed in the product comparison | Control plane HA is a deployment design choice in Kolla-Ansible or OpenStack-Ansible; confirm it |
| Identity integration | Built-in users; confirm LDAP or SSO options in your release | Confirm directory and SSO integration for your tenants | Keystone federation with SAML 2.0 and OpenID Connect; mapping rules must be written and tested |
When Apache CloudStack, OpenNebula or OpenStack fits a provider
Each platform below can replace part of what a provider runs on VMware Cloud Director, but they differ in how much they manage and how large a team they need to run them. Read the trade-offs against your tenant count, your mix of hypervisors and the size of the team that will operate the control plane.
CloudStack for mixed estates
Apache CloudStack, licensed Apache-2.0, manages VMware vSphere, KVM, XenServer and Hyper-V under one API, with user and account management and resource accounting built in. That suits a provider moving tenants off vSphere in phases while both hypervisors run side by side. The trade-off is migration work: virt-v2v must be installed manually on every destination KVM host, or the VMware to KVM import fails. Check the LTS window before you choose a release, because LTS releases receive bug and security fixes for 18 months after the main release, and plan the upgrade path to the next LTS early.
OpenNebula for centralized KVM tenancy
OpenNebula is Apache-2.0 licensed and provides multi-tenancy, multi-zone federation and high availability for front-end and host nodes, with the Sunstone web UI, a CLI, and XML-RPC and RESTful APIs. It manages KVM with LXC support and lists over 2,500 hypervisor nodes in a single instance. The trade-off is licensing: certain enterprise-grade releases, LTS versions and enterprise drivers are available only to subscribers, and the subscription is priced per hypervisor host. Ask for a written proposal, because the subscriptions page publishes no prices.
OpenStack for large self-service clouds
OpenStack suits providers building a large self-service private cloud with projects, APIs and Keystone federation over SAML 2.0 and OpenID Connect. Ceph can back Glance images, Cinder volumes and Nova guest disks, so VMs can boot from Ceph without local hypervisor storage. The trade-off is the larger operations team it needs: staff must run Kolla-Ansible or OpenStack-Ansible deployments, operate Ceph and carry out upgrades on a cadence that includes SLURP releases. Stable branches are maintained for approximately 18 months, so schedule upgrades before a branch leaves maintenance.
How tenants, quotas and self-service portals differ across the three
The three platforms isolate tenants with different building blocks, and that difference decides how much of your current VCD model carries over. In Apache CloudStack, the unit of isolation is the account, and accounts can be grouped into domains, which lets a provider delegate administration of a branch of customers while keeping resource accounting visible at each level. CloudStack's resource accounting and its native API are the core of its tenant model. In OpenNebula, tenancy is built from groups, users and access control lists (ACLs) that define which group can use which virtual networks, datastores and images. The Sunstone web UI presents those permissions to tenant users, so the isolation rules you set in the back end are the same rules a customer sees in the portal. In OpenStack, a tenant is a project, and Keystone roles assigned per project control what a user can do, with domains available for grouping projects under a common administrator.
Quota enforcement is where the platforms differ most in practice. CloudStack applies limits to accounts and domains for resources such as instances, volumes and networks, and these limits are the first thing to validate against your VCD quota policies. OpenNebula's quotas are set per user or group and cover compute, storage and network consumption, so a provider must decide whether limits follow the customer's group or a sub-account. OpenStack enforces quotas per project through Nova, Cinder and Neutron, and the defaults and enforcement behavior depend on the release you deploy. Self-service portals also vary: CloudStack ships its own web interface and an API that third-party portals can call, Sunstone serves the same role for OpenNebula, and OpenStack typically relies on Horizon or a portal built on its APIs, which means you may need to build or buy the customer-facing layer.
Before committing to any of the three, test quota and billing hooks against your own tenant plans. Take three representative plans, such as a small shared tier, a dedicated tier and a tier with reserved capacity, and confirm for each platform that a quota breach blocks the action without corrupting accounting, that usage records can be exported per tenant and per resource type, and that your billing system can ingest them without manual correction. Ask each vendor or community contact which parts of this are native, which need an add-on, and which must be written by your team. Confirm your own requirements with your billing and finance owners first, because a platform that enforces quotas well but produces usage data your invoicing cannot read will still force manual work every billing cycle.
Networking and usage accounting: what to design before tenants move
Tenants on VMware Cloud Director depend on isolated networks, edge routing, public addressing and metered usage that feeds billing. Before moving any tenant, a provider needs to decide how each of these will work on CloudStack, OpenNebula or OpenStack, and which parts of the existing billing chain will be rebuilt rather than carried over.
Tenant network isolation and virtual routers
Each tenant needs its own isolated L2 segments, DHCP and a routed edge. CloudStack provides network offerings for isolated and VPC-style networks with virtual routers, while OpenNebula and OpenStack (through Neutron) use different constructs for the same job. Map every VCD organization VDC network, including overlapping address ranges and any stretched networks, to a target model and test isolation between tenants with a packet-level check before the first move. Confirm the exact router and VPC features in the release you choose.
Public IP and firewall policy
Public address pools, source NAT, static NAT and port forwarding decide how tenants reach services and how the provider keeps control of egress. Inventory every edge gateway rule in VCD, then decide which rules become CloudStack firewall or port forwarding rules, which move to a shared perimeter firewall, and which are retired. Record who approves public address allocation and how released addresses are reclaimed, because these are the processes most often lost in a migration.
Usage metering and invoicing exports
CloudStack includes resource accounting, but the depth of usage records, the granularity of metered units and the export format must be verified in the version you deploy. Compare what your billing system consumes today from VCD, such as per-VM allocation, storage and network transfer, with what the target platform records. Run a parallel metering period where both systems report the same tenant usage, and confirm the rating logic and invoice totals match before billing changes. Ask the billing vendor whether it can ingest the new export format.
API tooling for provisioning and tenant automation
Tenant onboarding and provisioning scripts often call the cloud API directly. CloudStack publishes the CloudMonkey command-line tool at v6.6.0, a Terraform provider at v0.7.0 and a Kubernetes provider at v1.2.0. Use CloudMonkey for operator scripts, the Terraform provider for repeatable tenant templates, and the Kubernetes provider where tenants run clusters. Rewrite every automation path that touches VCD, since the query-based CloudStack API has different calls and identifiers, and test role-based access so tenant credentials cannot reach other accounts.
How to move tenants off VCD in waves
This sequence moves each tenant from VMware Cloud Director to a new platform in controlled waves, so every tenant is verified before VCD is switched off ahead of its August 12, 2028 end of service date.
Inventory tenants, orgs, catalogs and networks
Export the full picture of your VCD estate: each tenant organization, its virtual datacenters, vApps and VMs, catalog templates, edge gateways, routed and isolated networks, firewall and NAT rules, and the users and roles attached to each org. The provider operations team owns this step, with tenant account managers confirming which workloads are production and which are dormant. The step is done when you have a signed-off spreadsheet or CMDB extract that lists every tenant, its resource allocation and its network dependencies, and each tenant has a named owner who has reviewed it.
Choose the target platform and build a pilot zone
Select the target platform based on the tenant model you need, then build a small pilot zone to test it. Apache CloudStack is one option that manages vSphere and KVM side by side, which can help during a phased exit. OpenNebula and OpenStack are alternatives with different tenancy and operations models. Your platform engineers should install the chosen platform on a small set of hosts, connect storage and networking, and confirm that a test tenant can log in, deploy an instance and see usage records. The step closes when the pilot zone passes your internal acceptance test and the team has written down which VCD features have no direct equivalent.
Map tenant plans to quotas and projects
Translate each VCD provider virtual datacenter allocation and organization policy into the target model's quota, account, domain or project construct. Document CPU, memory, storage and network limits per tenant, plus who can administer each account. Confirm with the target platform's documentation how each limit is enforced and reported. The output is a tenant mapping table that the billing team and the tenant success team both sign off, so that the new environment reproduces the commercial promises made in each tenant's contract.
Migrate VM images and networks per tenant
For each tenant, rebuild its networks in the target platform, then move its catalog images and VMs. Where the source is vSphere-backed and the target is a CloudStack KVM zone, the VMware to KVM import needs virt-v2v installed manually on every destination KVM host, or the migration fails. Running Linux VMs can be cloned first, which gives a crash-consistent copy, while Windows VMs must be shut down gracefully before import. Supported KVM host distributions include Alma Linux, Red Hat Enterprise Linux, Rocky Linux 8 and 9, and Ubuntu 22.04 and 24.04 LTS. Test each imported VM for boot, network reachability and tenant access before marking the tenant ready.
Cut over tenant by tenant
Schedule each tenant's cutover as a separate change with a rollback plan, a freeze window agreed with the tenant, and a named contact on both sides. Re-point DNS, load balancers, VPN and firewall rules, then run application smoke tests with the tenant. Keep the VCD copy powered off but intact until the tenant confirms. Review the first few waves before accelerating, and record lessons in the runbook. The step closes for each tenant when the tenant signs off, usage metering shows the new environment, and the old VCD workload has been archived.
Decommission VCD before August 12, 2028
Once every tenant is cut over, export VCD configuration and audit records for retention, confirm that no active org or catalog depends on the appliance, and remove the VCD cells, databases and related VMware components in a documented change. Broadcom's knowledge base lists VMware Cloud Director 10.6.2 and VMware Cloud Director Availability 4.7.6 with an end of service date of August 12, 2028, so plan the final decommission to finish before that date. The step is complete when the decommission record, the retained exports and the tenant sign-off archive are filed with your compliance evidence.
What do providers ask before moving tenants off Cloud Director?
How much effort does a tenant migration take, and what drives it?
Effort depends less on the number of tenants than on how much each tenant has built on top of Cloud Director. Plain virtual machines with a few networks are the simplest case. The work grows with custom org networks, edge gateway rules, load balancers, catalog templates, tenant-specific roles, and any integration that calls the VCD API or billing data directly. Each of these must be mapped to an equivalent in CloudStack, OpenNebula or OpenStack, then tested with the tenant. Ask your team to inventory tenants by complexity before estimating. For the workload move itself, check which hypervisor and import path you plan to use, because the VMware to KVM route has its own host prerequisites. Confirm sizing against your own environment rather than against averages.
Can our team run the new cloud platform in-house after the move?
It can, but only if the skills exist before cutover. Operating a multi-tenant IaaS means owning the control plane, database, hypervisor hosts, storage, networking and the tenant-facing API or portal. CloudStack needs a MySQL-compatible database, MariaDB or MySQL, and is managed through its web interface, CloudMonkey or the query API. OpenStack adds identity federation, image and volume services and a larger set of components, and deployment typically uses Kolla-Ansible or OpenStack-Ansible. Map the skills you have against the operations you will run each week, including upgrades, backups and incident response. Where gaps exist, you can close them through training, hiring, or a retainer for ongoing support and upgrades. A written skills assessment is a useful first step.
What does a fixed-scope implementation cover for a provider migration?
A fixed-scope engagement covers the agreed deliverables, which are set in writing before work starts. For a provider move, these usually include the platform design, deployment in your own cloud accounts or data centers, tenant and network model mapping, identity integration, backup configuration, hardening, migration runbooks for agreed tenant waves, and documentation for your operations team. Security testing and compliance readiness evidence can be added as separate scoped work. DeployOpen does not issue audit reports or certifications, so any assessment you need for tenants will come from independent auditors. Ask for the exclusions in writing, such as tenant application changes, licensing for third-party tools, and any hardware procurement, so the scope has no hidden gaps.
How long does a tenant move take, and what sets the timeline?
The timeline is set by the number and complexity of tenants, the depth of the platform build, and how much change tenants can accept during their own windows. Two dates matter. Broadcom's knowledge base lists VMware Cloud Director 10.6.2 and VMware Cloud Director Availability 4.7.6 with an end of service date of August 12, 2028, which gives a fixed outer limit. Work back from that date, and allow time for a pilot wave, rollback testing and a final wave that does not compete with renewal cycles. Build the plan around tenant waves rather than one cutover. Ask any implementation partner for a schedule tied to written milestones, not a generic duration.
Does CloudStack LTS or the OpenStack upgrade cadence fit our support model?
It fits if your team can plan upgrades on a set schedule. CloudStack LTS releases receive bug and security fixes for 18 months after the main release, while regular releases get only critical fixes for a short period. The current LTS is 4.22.1.1, and the previous 4.20 LTS line still has a maintenance release, 4.20.3.1. OpenStack stable branches are maintained for about 18 months, and only SLURP releases may enter an unmaintained phase afterwards. Upgrades are supported between SLURP releases as well as adjacent releases. Compare these windows with your tenant SLAs and your change calendar. Confirm the current release status on the CloudStack downloads page and the OpenStack releases site before committing.
What does a quote need from us before a provider migration can be priced?
A quote follows from the written scope, so bring the inputs that define it. Provide a tenant inventory with counts, resource sizes, networking features in use, catalog and template usage, and integrations with billing or identity systems. Describe the target platform, the hypervisors you want to keep, the storage design and the backup and recovery requirements. State your compliance obligations, data residency constraints and any air-gap conditions. Include the hardware you will reuse and the timeline constraints from your contracts. DeployOpen does not publish a price list. Ask for the quote to break out planning, build, tenant migration, testing, documentation, training and any retainer for ongoing support, with each item tied to a deliverable.
What the cost of replacing VCD is made of
The software licence line is the smallest and simplest part of replacing VMware Cloud Director. Apache CloudStack and OpenStack are Apache-2.0 projects, so there is no per-core or per-tenant licence to buy. OpenNebula is also Apache-2.0 at its core, but its Enterprise Edition is a subscription priced per hypervisor host with no limits on cores, VMs or memory, and the OpenNebula subscriptions page publishes no prices and asks buyers to request a proposal. Ask any vendor for the subscription fee in writing, the tier it covers, whether it includes support, and whether the perpetual licence clause applies after the term ends. Support plans for OpenNebula are sold as Standard (9x5 coverage, 2 named accounts) or Premium (24x7 coverage, 4 named accounts). Those are recurring costs, and their price should be compared against the cost of your own on-call rota.
The larger costs sit around the software and do not disappear with it. Hardware, storage and network capacity are bought once for the initial build and then renewed on a hardware lifecycle. Staff skills are a recurring cost: a CloudStack or OpenStack operations team needs people who can run the database, the management servers, the hypervisor hosts and, for OpenStack, the control plane components. Migration work is one-time but can be large, because each tenant's networks, images, backups and billing records must be moved or rebuilt. The CloudStack VMware to KVM import needs virt-v2v installed manually on each destination KVM host, and that preparation belongs in the quote as a separate line. Ask the integrator to price each of these items separately, so you can see which ones scale with tenant count and which are fixed.
When you request quotes, ask for a written scope that lists the platform, the number of hypervisor hosts and tenants in year one, the tenant portal and billing integration, the backup and disaster recovery design, the migration waves and the handover to your operations team. Ask what is included for patching and LTS upgrades, since CloudStack LTS releases receive fixes for 18 months after the main release and OpenStack stable branches are maintained for approximately 18 months. Each of these determines how often you pay for upgrade work. Once the scope is agreed, compare the total cost over the period you plan to run the platform, not the first-year figure alone. Your own finance team should confirm the quote before the decision, because the figures that matter depend on your hardware, your tenant mix and your staff.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a cloud director replacement, we start from your tenant model and move through a written, fixed scope before any build work begins.
How we scope
- Inventory of VCD organizations, catalogs, provider VDCs, edge gateways and tenant-facing portal workflows
- Written mapping of each tenant service to CloudStack, OpenNebula or OpenStack features, including the gaps you must accept
- Agreed deliverables, timelines and acceptance criteria for tenant migration waves, usage accounting and billing exports
How we build
- Deploy the chosen platform, database, hypervisor zones and storage in your environment with documented configuration
- Build tenant, quota, network and identity federation designs and test them against your real tenant requirements
- Test security controls and tenant isolation, and run VM import and usage accounting checks before any tenant moves
How we hand over
- Runbooks for tenant onboarding, quota changes, backup, upgrades and incident response, written for your operations team
- Evidence packs of configuration, test results and access controls that your auditors or assessors can review
- Knowledge transfer sessions with your administrators, plus a record of open items and known platform limits
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover
- Retainer scope, response coverage and upgrade windows are agreed in writing, with the platform's own release cycle in mind
- Confirm with us and with the vendor which release line, support plan and certified scope apply before you sign
