ZSvirt: an open source IaaS engine built on ZStack's ZSphere hypervisor

What ZSvirt is, and the problem it targets

ZSvirt describes itself as the open source release of ZStack's ZSphere virtualization engine. The problem it addresses is concrete: teams running KVM hosts often end up assembling their own control plane for VM lifecycle, images, primary storage, networks, security groups and permissions. ZSvirt offers that control plane as one product, with a web UI, a RESTful API and a CLI over the same environment. The README also lists Terraform and Go, Python and Java SDKs, so automation is expected to go through the API rather than the UI. The audience is infrastructure engineers at organisations that want private cloud on their own hardware and want to avoid vendor lock-in. The repository topics mention Proxmox, VMware Labs, vSphere and VMware migration, which tells you the project positions itself against both the commercial VMware stack and the common open source alternative. It is not a desktop hypervisor and not a container runtime. It manages virtual machines on KVM-based hosts, which means you still supply the hardware, the network and the storage.

How the management node and KVM hosts fit together

The README describes a two-part deployment. You install a management node, then attach KVM-based hosts to it. Everything you operate (VMs, clusters, storage, networks) is managed through that node, whether you use the web UI, the REST API or the CLI. The architecture section splits capabilities into compute virtualization (hosts, clusters, VMs, images, lifecycle), network virtualization (virtual networks, network services, security groups), storage virtualization (primary storage, backup storage, volumes, snapshots) and a management plane covering the API framework, permissions, events, alarms and auditing. Extension services cover migration, disaster recovery, monitoring, quota management and access control. The stated design principles are asynchrony, statelessness, extensibility and automation, with asynchronous messages and asynchronous methods called out explicitly. That matters operationally: long-running actions such as migrations and image operations are not synchronous calls, so tooling built against the API has to handle job state rather than expecting an immediate result. The repository layout backs this up. Top-level directories include longjob/, rest/, core/, compute/, network/, image/, identity/, plugin/, externalservice/, agents/ and sdk/, plus conf/ and configuration/ for settings. The agents/ directory suggests host-side components that the management node talks to, though the README does not describe the agent protocol.

Installing ZSvirt and managing your first VM

The README does not give command-line install steps. It points to the download page at zsvirt.io/download for a qcow2 or OVA image, and to the Quick Start documentation at zsvirt.io/en/docs/quick-start. The stated procedure is to boot that image as a VM on VMware, VirtualBox, KVM or a cloud host with nested virtualization, set an IP, and the management node is ready. The README links a dedicated page for running ZSvirt inside a VM, so nested virtualization is a supported evaluation path rather than a workaround. If you would rather not install anything, the project hosts a live demo at demo.zsvirt.io where the README says you click Demo Login and start exploring without sign-up. Once the management node is reachable, the workflow the README describes is to attach KVM-based hosts and then manage VMs, clusters, storage and networks through the UI, the REST API or the CLI. The repository has an sdk/ directory, but the README does not include SDK install commands, so treat the API and CLI as the documented entry points and read the docs site for the exact calls. This is the honest limit of what the repository files show: the install path is an image plus documentation, not a package you install with a package manager.

VMware migration is the feature that separates it from generic KVM panels

The README names three built-in VMware migration capabilities: online migration, OVF import and VMDK upload. That is a narrower and more specific claim than the usual "migration support" bullet. Online migration implies moving a running workload rather than requiring a maintenance window, OVF import covers the standard virtual appliance format, and VMDK upload covers the disk format most VMware estates already have on disk. For a team leaving vSphere, those three paths cover the common cases without a third-party conversion tool. The trade-off is that migration is listed as an extension service, alongside disaster recovery, monitoring and quota management, so it is part of the platform rather than a separate product you can adopt on its own. The README does not document migration prerequisites, supported guest operating systems, or what happens to snapshots and thin-provisioned disks during conversion. The migration management screenshot in the README shows a workload migration view, but the repository does not publish the underlying constraints. Test a representative VM before you plan a migration wave around it.

Where ZSvirt is the wrong tool

Three cases stand out. First, if you are not already running KVM hosts, ZSvirt does not remove that requirement; it attaches to KVM-based hosts, so the hypervisor layer is still yours to build and operate. Second, if you need a documented upgrade path, the README is silent. There is a VERSION file and a build/ directory, and the repository carries a premium/ directory alongside the open source modules, but nothing in the README explains how to move a management node from one version to the next or how the premium modules are licensed relative to the GPL-3.0 core. That is a real operational gap for anyone planning a production rollout. Third, if your requirement is a large ecosystem of third-party plugins, ZSvirt is not that. Its extension surface is its own plugin/ and externalservice/ directories, and the README does not describe a public plugin marketplace or a compatibility contract for external modules. A team that needs a hypervisor with a wide module ecosystem will find ZSvirt narrower. The README also does not state minimum hardware requirements for the management node, which you will want before sizing a pilot.

How it compares with Proxmox VE

Proxmox VE is the obvious alternative and the repository's own topics list it. Both manage KVM-based virtual machines and both ship a web interface. The difference is in the control plane's shape. Proxmox is a node-centric product: each host runs the full stack and clusters are formed between peers, so a single host is useful on its own. ZSvirt is management-node centric: you install a management node and attach hosts to it, so the control plane is a distinct component with its own lifecycle. That has consequences. A ZSvirt deployment has a component whose availability matters separately from the hosts, and it has an API framework, permission model, events and auditing described as a management plane, which is the kind of structure a Proxmox cluster does not present in the same way. The REST API plus Terraform and Go, Python and Java SDKs also point at automation-first workflows. Proxmox's advantage is maturity of packaging and a long history of community documentation. ZSvirt's advantage, on the evidence here, is the VMware migration tooling and the enterprise-oriented management plane inherited from ZStack. Pick based on whether you want a per-host product or a separate control plane.

Licence, maintenance and what upgrades will cost you

The repository is licensed GPL-3.0, and the LICENSE file sits at the top level. The practical consequence is the usual copyleft one: if you distribute a modified management node, the GPL-3.0 terms apply to that distribution. Running it inside your own organisation is not distribution. The repository also contains a premium/ directory next to the open source modules, and a platforms/ directory, but the README does not explain how those relate to the GPL-3.0 core or what licence they carry. That is worth confirming with the project before you build a product on top of it. On maintenance, the last push to the default branch was on 2026-09-16, and the repository is not archived, so the codebase is receiving commits. There are no retrieved releases, which means there is no published release history to plan upgrades against. Combined with the README's silence on upgrade procedure, the cost of staying current is currently unknown. Budget time to read the docs site and the repository's VERSION file, and to test an upgrade on a throwaway management node, before you commit to a version you cannot easily move off.

Editorial conclusion

ZSvirt fits teams that already run KVM and want a web UI, REST API and CLI over the same hosts, plus a documented path for VMware migration. It is a poor fit if you need a documented upgrade procedure today, because the README does not describe one, or if you want a hypervisor with a large third-party module ecosystem, because ZSvirt's extension surface is the plugin/ and externalservice/ directories in its own tree. Verify first that your hardware and storage backends appear in the ZSvirt docs, that the GPL-3.0 terms work for how you plan to distribute the management node, and that you can run the platform/ and premium/ modules under whatever licence they carry.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. ZSvirt/zsvirt on GitHub