When vSphere or Apache CloudStack fits your VMware exit
Choose vSphere if your renewal under Broadcom's VVF or VCF subscription model is the main problem and your estate is a single, well-understood vCenter cluster that your team already runs well. Choose Apache CloudStack if you are leaving ESXi in phases and need one management layer across vSphere and KVM during the move, or if you must issue tenant accounts with resource accounting on your own hardware. The decision turns on four drivers, and each one is worth settling before you price anything. First, host count and how long the mixed state will last. CloudStack pays off when hosts will run under both hypervisors for months, because one API and one web interface cover both zones. A small, fixed cluster that can cut over in one window gains little from that layer. Second, whether you truly need a single control plane. If your only requirement is a like-for-like cluster, a KVM-only platform may be simpler to run.
Third, operations skills. CloudStack needs a MySQL-compatible database, MariaDB or MySQL, and someone who can operate the management server, zones, storage and the KVM hosts. Confirm that your team can own that stack, or that a partner can, before committing. Fourth, your tolerance for release cadence. Confirm which CloudStack line you will run: LTS releases receive bug and security fixes for 18 months after the main release, while regular releases receive only critical fixes for a short period, so plan upgrades around the LTS calendar on the CloudStack downloads page. Also confirm that each destination KVM host has virt-v2v installed before your first import wave.
Which platform fits which scenario
This table matches common exit scenarios to the option that fits best and the condition that makes it true. Read each row against your own estate: if the condition does not hold, the next row is likely the better starting point. The main takeaway is that CloudStack earns its operating cost when several hypervisors, tenants or phased exits must run under one API.
| Scenario | Better fit | Condition that makes it true |
|---|---|---|
| Single-cluster renewal | Proxmox VE or XCP-ng, not CloudStack | One site, one cluster and no plan to run a second hypervisor. A single-cluster estate rarely needs the CloudStack management layer, and a like-for-like platform has a smaller operations footprint. |
| Phased host-by-host exit from ESXi | Apache CloudStack | Hosts must leave ESXi in waves while vSphere and KVM keep serving workloads. CloudStack manages vSphere and KVM under one API, so each wave changes the host pool rather than the management tooling. |
| Multi-tenant service provider | Apache CloudStack | Tenants need accounts, domains, quotas and resource accounting through a native API. Confirm that your billing and usage reporting can consume CloudStack's accounting data before committing. |
| Air-gapped or regulated estate | Proxmox VE or XCP-ng for most sites, CloudStack when phased migration is required | Choose CloudStack only if the phased move is mandatory, because every KVM host needs virt-v2v installed manually and the import path has more moving parts. Confirm the import path and repository mirroring in your isolated network before the first wave. |
| Teams with no cloud-operations staff | Proxmox VE or XCP-ng | The team cannot staff a MySQL-compatible database, CloudStack management servers and KVM host maintenance together. Ask for a written operations runbook and training scope before selecting CloudStack. |
| Mixed VMware and KVM during migration | Apache CloudStack | Workloads need both hypervisors reachable during the move, and the team accepts running the CloudStack control plane for the duration. Plan the VMware to KVM import per host, starting with the supported KVM distributions named in the CloudStack docs. |
| Linux-heavy migration with crash-consistent cloning | Apache CloudStack or Proxmox VE | Most running VMs are Linux, where CloudStack clones them before import, while Windows VMs need a graceful shutdown. Compare the Windows shutdown window against your change calendar before choosing. |
How the choice changes by environment
A single data center with one vSphere cluster and a stable set of internal application teams usually gains little from CloudStack's multi-layer model. A like-for-like hypervisor platform such as Proxmox VE or XCP-ng keeps the management surface small, and the team can focus on the migration itself. CloudStack becomes worth a closer look when the site must hold a phased transition from ESXi to KVM while the business still expects a single management point.
- Staffing: One small platform team can run a single zone, but CloudStack adds its own management server, MySQL-compatible database and agents, so confirm who will own those components after handover.
- Accounts and domains: Internal departments can be modeled as accounts under domains, which helps with quota and chargeback reporting, but a single business unit rarely needs that structure.
- Migration path: Running vSphere and KVM hosts under one API lets you move waves without changing tooling, provided virt-v2v is installed on each destination KVM host.
- Operations: Compare the time your team needs to learn CloudStack's zone and network model against a vCenter-style workflow.
Before committing, confirm how HA restart and live migration behave for your VM types in your own environment, since these depend on the hypervisor and storage you choose.
Organizations with several sites, some already running KVM or XenServer and others still on vSphere, face the most direct fit for CloudStack. Its design expects to orchestrate more than one hypervisor type, so a zone can host vSphere clusters during the transition while KVM zones receive migrated workloads. The main question is whether a single control layer reduces the number of tools your operators must use across sites.
- Zones: Zones let you separate physical locations or hypervisor pools, and the migration can be planned zone by zone rather than as one cutover.
- Accounts and domains: Use domains to reflect business units or regions, so that accounts inherit policy and resource limits in a predictable way.
- Resource accounting: Track usage per account across both hypervisors, which helps show which workloads still depend on vSphere.
- Tooling: CloudMonkey, the Terraform provider and the Kubernetes provider give automation teams several entry points, but confirm their versions against your CloudStack release.
- Import limits: Plan VMware to KVM imports host by host, since each destination KVM host needs virt-v2v installed manually.
Confirm your site-to-site network design, storage replication and failover expectations with your own architects, because the supplied facts do not cover multi-site failover behavior.
Service providers that sell infrastructure to outside tenants use CloudStack's multi-tenant design most directly. Accounts, domains, a native API and resource accounting map to the way a provider must separate customers, apply limits and bill for consumption. A provider already invested in VMware Cloud Director should compare CloudStack against its own tenant model, portal requirements and billing integrations before planning a move.
- Tenant isolation: Domains and accounts give a provider a structured way to separate customers, but the networking and isolation guarantees must be validated against your own design.
- Usage accounting: Resource accounting supports per-account reporting, which billing systems can consume through the API, so test the exact usage records your invoicing needs.
- Self-service: The web interface and API let customers or internal teams request resources, though the portal experience will depend on what you build or integrate.
- Hypervisor mix: During a move, tenants on vSphere and KVM can remain under one management layer, which reduces the risk of a single large cutover.
- Lifecycle: Choose between the LTS line, which receives bug and security fixes for 18 months, and regular releases with a shorter critical-fix window.
Ask the CloudStack community and your own engineers to confirm tenant-level quota behavior and billing data formats before sizing the platform team.
Where your data sits and who controls the platform
CloudStack places the management plane, hypervisor hosts and VM disks inside infrastructure you choose, so the control questions move from a vendor contract to your own operating model. The cards below cover where data lives, who runs the platform, how access is governed, what evidence you must produce, who owns patches, and how you leave. DeployOpen prepares controls and evidence, but independent auditors issue any attestations.
Data location and residency
CloudStack's management server, MariaDB or MySQL database, secondary storage and VM disks all sit in your data center or cloud account, so residency is set by where you deploy the zones. During a vSphere migration, data also passes through conversion hosts running virt-v2v, which is why those hosts belong in the same controlled network. Confirm where the database backups, templates and import staging storage are kept, not only where the production VMs run.
Hosting model: self-run or partner-run
Your team can run CloudStack entirely, or a partner such as DeployOpen can plan, implement and support it inside your infrastructure under a written scope. Either way, the platform stays in your environment and the operating responsibility is agreed in advance. Ask who holds administrator credentials, who answers on-call pages, and how changes to the management plane are approved and recorded.
Identity and access through accounts and domains
CloudStack separates tenants with accounts and domains, and each user role controls what can be seen or changed inside its scope. Map these roles to your existing identity groups before the first cluster is added, and decide which people hold root-domain administration. Review the API keys issued to automation tools, because a single leaked key can reach every resource the account can touch.
Compliance evidence you must prepare
Your auditors will want to see access reviews, change records, backup restore tests and configuration baselines for the CloudStack estate, and none of these are produced automatically by the platform. Define which logs leave the management server, how long they are kept, and who reviews them. DeployOpen prepares these controls and evidence for your assessment, but independent auditors issue any attestation or certification.
Supply chain and patch ownership
Apache CloudStack is released under Apache-2.0, so the code is open, but your team owns the timing of upgrades on every hypervisor and the management server. Choose between the LTS line, which receives bug and security fixes for 18 months after the main release, and regular releases, which get only critical fixes for a short period. Confirm who tracks the KVM host operating system patches and the virt-v2v package versions on each host.
Exit path and data portability
Leaving CloudStack should be planned as carefully as entering it. Keep VM disks in formats you can convert, export the database schema and configuration, and test restoring a VM on another platform before you commit to a wave. Ask any implementation partner for a written exit plan covering data return, credential revocation and removal of conversion hosts once the estate has moved.
What a move from vSphere to CloudStack involves
The sequence turns a vSphere estate into a CloudStack zone where ESXi and KVM hosts run under one management layer, so workloads move in waves and each wave ends with a verified VM on KVM.
Inventory VMs and their dependencies
The VMware administrator and the application owners list every VM with its operating system, disks, network port groups, snapshots, backup jobs and external dependencies such as licenses, DNS entries and load balancer pools. Flag Windows VMs, VMs with snapshots and any VM tied to a specific vSphere feature. The output is a signed-off inventory with a proposed wave for each workload, so you know which VMs can be cloned and which need a graceful shutdown window.
Build the CloudStack management server and database
Your platform team installs the CloudStack management server and a MySQL-compatible database, MariaDB or MySQL, sized and backed up under your own standards. They then define the zone, pod, cluster, primary and secondary storage, and the network model, and create the first accounts and domains for the tenants or teams that will use the platform. Confirm the supported management server and database versions for your chosen release line in the CloudStack documentation before you build. The step is done when the management server reports healthy and an administrator can log in through the web interface, the command-line tools and the API.
Add KVM hosts and install virt-v2v on each
Install a supported KVM host operating system on the destination hardware. The CloudStack VMware to KVM import documentation lists AlmaLinux, Red Hat Enterprise Linux and Rocky Linux 8 and 9, and Ubuntu 22.04 and 24.04 LTS, so confirm the current list for your release line before you buy or reimage hosts. Add each host to a CloudStack cluster, then install the virt-v2v binary manually on every destination KVM host. CloudStack does not install it with the agent, and the migration fails on a host that lacks it. The step is done when every host shows as up in CloudStack and virt-v2v runs successfully on each one.
Pilot Linux VMs by cloning and Windows VMs by shutdown
Choose a small set of non-critical VMs from the inventory, one Linux and one Windows, and run them through the import. CloudStack can import running Linux VMs by cloning them first, which produces a crash-consistent copy. Windows VMs must be shut down gracefully before import, so the pilot should include a planned outage window agreed with the owner. Compare boot behavior, drivers, network connectivity, disk performance and backup jobs against the source. Record the results and any conversion errors. The step is done when each pilot VM boots on KVM, passes the owner's acceptance tests and has a working backup job in the new environment.
Run both hypervisors under one management layer in waves
Keep the ESXi hosts in service and manage them from CloudStack alongside the KVM cluster. Move workloads in waves grouped by application, tenant and risk, starting with the lowest-impact group and ending with databases and systems that depend on tight latency. Each wave follows the same runbook: freeze changes, clone or shut down, import, validate network and storage, switch DNS or load balancer pools, then confirm backups. Track the snapshot and import status in the VM Import Tasks view that CloudStack 4.22 added, and confirm this view exists in your release. The step is done when every wave has a signed acceptance record and rollback steps have been tested for that wave.
Retire ESXi hosts after the last wave
Once the final wave is accepted, confirm that no VM, template, backup job or monitoring check still points at the ESXi hosts. Move any remaining templates or datastores you still need, then remove the hosts from CloudStack and decommission them under your data destruction policy, including disk and licensing records. Update the asset register and the operations runbooks to show the KVM cluster as the production platform. The step is done when the ESXi hosts are out of service, the vCenter inventory is empty of production workloads, and the operations team has handed over the CloudStack runbooks.
Which operations skills the team needs compared with vCenter
vCenter teams think in clusters, hosts, datastores, port groups and vMotion-based placement. CloudStack asks them to think in a cloud control plane: accounts and domains that hold tenants, service and compute offerings that define what a user can request, zones, pods and clusters that map to physical failure and capacity boundaries, and resource accounting that records what each account consumed. Day-to-day work moves from the vSphere Client into the web interface, the native query API and CloudMonkey, the command-line tool the project publishes (v6.6.0 according to the CloudStack downloads page). Staff should practice creating an account, attaching an offering and deploying a VM through CloudMonkey before the first wave, because most automation and troubleshooting will run through the API rather than clicks.
Experienced vSphere administrators carry over more than they expect: capacity planning, host maintenance discipline, network design across VLANs, storage sizing, backup verification and change control. What they must learn is the management layer itself. CloudStack requires a MySQL-compatible database, MariaDB or MySQL, so someone must own its backup, replication, patching and performance tuning, since a damaged management database leaves the platform unable to orchestrate even when hypervisors are healthy. The team also needs KVM host operations, including installing virt-v2v manually on each destination host for VMware imports, and an understanding of which Linux distributions are supported on those hosts. Confirm with your own environment which of these skills already exist in-house before deciding.
A short vendor-led or partner-led training plan is usually more practical than hiring when the existing team already runs Linux and databases well and only needs to learn the CloudStack model and API. Hiring makes sense when no one can own the database or KVM hosts after the move. Ask any training provider for hands-on labs in a lab zone that mirrors your network, accounts and offerings, and for runbooks covering management database failover, host maintenance and the import procedure. Budget for the time staff spend away from production work as well as the course fee. Define in advance who holds on-call duty for the management plane during the phased period when both vSphere and KVM hosts sit under one CloudStack deployment.
Common questions before moving from vSphere to CloudStack
How much effort does a vSphere to CloudStack migration take?
The effort depends mostly on the size and mix of the estate, not on the number of hypervisors alone. The main drivers are how many VMs are Linux and how many are Windows, which of them can be cloned while running, how many depend on vSAN-backed or encrypted storage, and how many need network and storage mapping that CloudStack must reproduce. Each KVM destination host also needs virt-v2v installed by hand, and every host in the migration path has to be prepared and kept consistent. Ask any partner to split its quote into discovery, host preparation, pilot waves, production waves and handover, so you can see which parts scale with your estate.
Can our own team run the migration without outside help?
A team that already runs KVM, Linux administration and a MySQL-compatible database can usually handle a pilot on its own, provided it reads the CloudStack import documentation closely. The skills gap is larger than the hypervisor gap: CloudStack adds zones, pods, clusters, accounts, domains and an API-driven model that most vCenter administrators have not used. Teams with no KVM or cloud management experience often choose a fixed-scope engagement for the first wave, then take over operations. Be honest with yourself about staff time, because pilot waves tend to surface host and network issues that need engineers available on short notice.
How long does a phased move from vSphere to CloudStack take?
The length of a phased move is set by the number of waves, the number of change windows your business allows, and how many applications need coordinated cutover. Duration grows with the count of stateful databases, the number of Windows servers that require a graceful shutdown, and the number of integrations that depend on fixed IP addresses or hostnames. Hosts can be moved in groups while the rest of the estate stays on ESXi, so the schedule follows your change calendar more than the technology. Ask for a wave plan with explicit entry and exit criteria for each wave rather than a single completion date.
What inventory and inputs do we need to provide before the work starts?
You need an accurate inventory of VMs, their operating systems, VMware Tools status, disk layouts, snapshot history, network segments, storage datastores and the owners who approve each change. You also need the list of change windows, the staff who can approve a rollback, and named contacts for each application. On the CloudStack side, you should confirm which KVM host distributions you will use from the supported list in the CloudStack documentation, and who will install virt-v2v on each destination host. Staff time is needed for application owners, network engineers and database administrators, not just the platform team.
Does the 18-month LTS support window fit our upgrade cadence?
CloudStack LTS releases receive bug and security fixes for 18 months after the main release, while regular releases only get critical bug fixes for a short period. That means an LTS line suits organizations that patch on a slower schedule, but you still need to plan a minor-version upgrade before the window closes. Check the current LTS line on the CloudStack downloads page, and map its end-of-fix date against your change calendar and your audit obligations. Document who owns each upgrade, how you test it in a non-production zone, and how you roll back if the upgrade fails.
How do we handle running VMs during the import?
For running Linux VMs, CloudStack can clone the VM first, which converts it in a crash-consistent state, so the source keeps serving users while the copy is converted. Windows VMs must be shut down gracefully before import, so they need a scheduled outage. Crash-consistent copies can contain uncommitted database writes, so database servers should be quiesced or backed up in the application's own way before cloning. Test the clone of each application type in a pilot wave, confirm that the restored VM boots and that its services start, and keep the original VM powered off only after the business has signed off.
What does DeployOpen cover if we bring in a partner?
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, which includes CloudStack zones, KVM hosts and the migration waves that move VMs into them. Engagements are normally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and testing can be added as a retainer. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Pricing follows from the written scope, so ask for a quote that lists each deliverable.
How DeployOpen helps evaluate and implement CloudStack
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from vSphere to Apache CloudStack, that means testing whether a multi-hypervisor CloudStack zone fits your tenancy model and migrating workloads in phases under one management layer.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Scope covers which vSphere clusters move, which tenants and accounts map to CloudStack domains, and the resource accounting you need.
- We confirm KVM host distributions, storage pools and the MariaDB or MySQL database layout against your environment.
How we build
- We build a CloudStack management environment and KVM zone in your own data center or cloud accounts, with the chosen CloudStack release line.
- We install and validate virt-v2v on each destination KVM host, since CloudStack does not install it with the agent.
- We run test imports of representative Linux and Windows VMs, including graceful shutdown rules for Windows, and record the results.
How we hand over
- You receive runbooks for account and domain setup, network and storage configuration, and wave-based VM migration.
- Documentation covers operating CloudStack through its web interface, CloudMonkey command-line tool and query API for your operations team.
- We prepare configuration and evidence for your internal or external compliance assessment, without issuing any audit report or certification.
How we support
- Ongoing support, LTS upgrades and continuous security testing are available as retainers after handover.
- Upgrade planning follows the CloudStack LTS support window, so you can schedule moves to newer LTS lines before fixes stop.
- Ask any implementation partner to confirm in writing which CloudStack release, support scope and response terms they will deliver.
