DEV Community: ZSvirt

Evaluating ZSvirt as a VMware Alternative: A PoC Guide from Deployment to Migration

ZSvirt — Wed, 09 Sep 2026 07:19:12 +0000

Over the past few weeks, we announced ZSvirt’s open-source release, shared the reasoning behind it, walked you through creating your first VM, broke down the architecture of the production-proven engine, and covered the full workflow of migrating VMs from VMware. Today, we zoom back out to the evaluation itself: when you’re seriously considering ZSvirt as a replacement for your current virtualization environment, where should you start validating?

When you’re looking for a VMware alternative, creating and booting a single VM only verifies the most basic compute path.

A complete evaluation also needs to cover the operations ecosystem that wraps around VMs: how hosts and clusters are managed, how storage and networking are attached, how permissions are assigned, how failed tasks are recovered, and how existing VMware workloads get migrated.

This post lays out a PoC path that you can actually execute in your environment. When you’re done, you should be able to answer one specific question:

Can ZSvirt take over our current virtualization environment given our hardware, network, storage, and workloads?

Before You Start: Define What You’re Replacing

“Replacing VMware” involves a whole set of infrastructure capabilities.

For teams running only a handful of VMs, the evaluation may center on the Linux and Windows workloads on their existing servers. For larger infrastructure teams, it also means cluster management, shared storage, distributed networking, access control, automation interfaces, high availability, and migration flows.

So a PoC can start by documenting your current environment.

At minimum, gather the following:

The number of vCenters, clusters, hosts, and VMs;
CPU architecture, generations, and your hardware retention plan;
Virtual disk sizes, snapshots, and sustained write patterns;
VLANs, address allocation, security policies, and external network dependencies;
Linux, Windows, and special OS versions;
How backup, monitoring, audit, and automation systems connect;
Workloads that can tolerate downtime, and those that need a shorter cutover window.

This checklist will determine the scope of everything that follows. Every VMware environment has a different resource structure and set of business dependencies, so the migration decision has to be made in the context of your actual situation.

Step 1: Stand Up the Minimal Resource Path

The most direct way to start evaluating ZSvirt is to stand up a minimal environment by following the first-VM deployment guide.

For testing, a single server can act as both the management node and a compute node. After the ISO install, create a datacenter and cluster in sequence, add hosts, data storage, image storage, a distributed switch and port groups, and finally create your first VM.

Once the VM is “Running”, keep checking that all the pieces cooperate:

Can the host stay connected to the management node?
Can images be uploaded and used to create VMs?
Can virtual disks be created, attached, and deleted?
Does the VM get the expected address?
Are the gateway, external address, and DNS resolution working?
Does the console open?
Do shutdown, start, reboot, and delete operations leave clear task records?

Only after you confirm that the compute, storage, network, image, and VM paths all work should you move on to cluster and migration tests. That way, when something goes wrong later, you can tell faster whether the problem is platform configuration, infrastructure conditions, or the migration process.

Step 2: Verify Day-to-Day Operations

The long-term experience of a virtualization platform shows up in the day-to-day changes you make over years.

In your PoC environment, keep doing the following:

Expand a virtual disk;
Add and remove data disks;
Create, restore, and delete snapshots;
Modify a VM’s compute spec;
Adjust network configuration;
Migrate a VM to another host;
Simulate an operation failing halfway through;
Inspect the rollback and error messages of a failed task.

ZSvirt handles long-running operations with async tasks, stateless services, and a workflow engine. Take creating a VM: underneath, it may involve scheduling a compute node, preparing an image, creating disks, configuring networking, and generating the VM config. If any step fails, it can leave behind resources that were created but are no longer needed.

The workflow engine breaks such operations into executable, rollback-able steps. For more on these mechanisms, see ZSvirt Architecture Explained and the workflow engine design.

In your PoC, deliberately cause a controlled failure — for example, an unavailable storage path or wrong network parameters — and observe:

Which step the task stops at;
What error the UI and API return;
Whether completed steps are cleaned up;
Whether orphaned disks or leftover config are produced;
Whether you can re-run after fixing the issue.

This test shows you directly how the platform handles and recovers from abnormal situations.

Step 3: Validate Storage and Networking Separately

In a virtualization replacement project, storage and networking often decide the final stability and operational complexity.

Storage Validation

Seeing a storage type in the config page only means the platform offers that integration entry. Real validation should also include:

mporting images and creating VMs from them;
Creating and attaching system and data disks;
Snapshots and recovery;
Cross-host migration on shared storage;
State after a host or storage path failure;
Latency and throughput under typical workload;
Time required for backup and recovery.

If your production environment uses SAN, NFS, Ceph, or another storage system, test with the devices you plan to keep. Local disks are fine for standing up a minimal environment, but results there don’t directly represent how shared storage will behave.

Networking Validation

Pick a VLAN and address range close to production and verify:

Distributed switch and port group configuration;
DHCP or static address allocation;
Whether VLAN and physical switch config match;
Network connectivity after a VM migrates across hosts;
Where security rules apply and their effective scope;
The traffic path after a host or network component state change.

When a network fault occurs, administrators should be able to answer three questions: where traffic enters, where rules are enforced, and which layer to start troubleshooting from.

If the traffic path and rule locations are still unclear, the validation isn’t done yet.

Step 4: Verify Permissions, Auditing, and Automation

For environments managed by multiple people, in addition to the Web UI experience, verify permission boundaries, audit records, and automation APIs.

Create at least two kinds of test accounts:

A day-to-day operator with basic VM permissions;
An administrator who can manage hosts, storage, networking, and accounts.

Check what each account type can view and execute in both the UI and API, and confirm that denied operations leave a record.

Then run a minimal automation path through the API:

Query hosts, storage, networking, and images;
Create a VM;
Query the async task status;
Tag a resource;
Read operation results and audit records;
Deliberately submit a bad parameter and check the response.

ZSvirt provides RESTful/OpenAPI endpoints plus a Terraform provider and Go, Python, and Java SDKs. Your PoC should confirm that existing portals, scripts, ITSM, monitoring, or asset systems can reliably call these interfaces. For the capabilities and open-source scope, see Why We Open Sourced ZSvirt.

Step 5: Start Migration with a Single Non-Critical VM

Once the base platform validation is done, start testing VMware migration.

ZSvirt currently offers three common migration paths:

Migration path	Best for	What to validate
ZMigrate online migration	Keeping the source VM running and cutting over in a planned window	Full and incremental sync, network mapping, target validation, and final cutover
OVF import	You already have a standard OVF/OVA export	Virtual hardware config, disks, boot mode, and network adapters
VMDK image upload	You already have the VMware virtual disk files	Disk format, OS boot, drivers, and virtual NIC

For the full procedures, see ZSvirt Migration in Practice: Three Ways to Migrate VMs from VMware.

For the first test, avoid critical production systems — but also avoid a completely idle demo VM. A better candidate is a Linux or Windows VM that runs real services, has sustained disk writes, and can be rolled back.

A complete migration should at least record:

Initial data volume and sync duration;
Source VM load during incremental sync;
The final cutover window;
Target VM first boot time;
Whether IP, routing, and security policies are correct;
Application services, file system, and database consistency;
Retry and rollback options after a failed migration;
Final confirmation from the application owner.

Even after a migration task hits 100%, you still need to validate the business on the target platform and confirm your team can roll back in an abnormal situation.

A Suggested PoC Checklist

Before discussing production replacement, complete at least these ten tests:

Deploy the ZSvirt management node from the ISO;
Create a datacenter and cluster, and add hosts;
Configure images, data storage, and virtual networking;
Create and run both Linux and Windows VMs;
Verify the console, address allocation, and external networking;
Test disk attach, expansion, snapshots, and recovery;
Migrate a VM across hosts on shared storage;
Verify role permissions, operation records, and audit logs;
Create a VM via the API and track the async task;
Use ZMigrate to sync, validate, cut over, and rehearse rollback for one VMware VM. Every item should have a clear expected result, actual result, and owner. For failed items, also record where the logs are, how to recover, and whether the item blocks production migration.

How to Judge Your PoC Results

Different virtualization scenarios place different demands on a platform.

If you only need to manage one server and a few experimental VMs, a full cluster control plane may be more than you need. If your team already runs a Kubernetes-native infrastructure model, you may also want to compare Kubernetes-based virtualization options. If your environment depends on specific VMware plugins or proprietary integrations, you’ll need to validate the replacement path separately.

ZSvirt is for teams that want to keep an operations model centered on clusters, hosts, VMs, storage, and networking, while also needing open source, an open API, and a path to migrate from VMware.

After the PoC, form an internal conclusion around these questions:

Can the existing hardware keep being used;
Can critical workloads run stably;
Can operators understand and troubleshoot the platform’s behavior;
Can automation and external systems integrate;
Do the migration windows and rollback flows meet business requirements.

Once these validations are done, your team has a migration conclusion it can review internally, reproduce, and keep moving forward with.

VirtWatch Weekly 001: ZSvirt Core IaaS Engine Goes Open Source, VMware Explore 2026 Kicks Off, Proxmox VE 8 Reaches EOL

ZSvirt — Wed, 02 Sep 2026 06:57:34 +0000

Virtualization Watch — Issue 001

August 31, 2026 · Weekly · Coverage window: 8/26–8/31 (with August backfill)

From the Editor

Issue 001 goes to print at the confluence of several timelines: two weeks ago (August 14), this publication's producer ZSvirt fully open-sourced its core IaaS engine, and this week it launched the Storytellers program aimed at creators — a "house matter" we'd like to explain to readers first; today (August 31), VMware Explore 2026 opens in Las Vegas, where Broadcom-era VMware will tell the "private AI cloud" story for another year; on the same day, Proxmox VE 8 officially reaches end of life, closing the book on one of the most widely deployed generations in the open-source camp. The enterprise giant's annual show and the community distribution's version transition each turn a new page on the same Monday.

Over the past two weeks, vCenter's CVE-2026-59310 escalated from a "just-patched" advisory into an in-the-wild attack campaign spanning 47 countries — a reminder that security debt on the management plane always gets called in at the least convenient moment. Meanwhile in the community, vphone-cli — a tool that boots a virtual iPhone with a single command — hit the Hacker News front page, as virtualization keeps breaking out in small, elegant ways.

This week we chase no hype, only verified facts and sources. On to the stories.

In This Issue

ZSvirt's Core IaaS Engine Goes Open Source (GPL-3.0)

On August 14, ZSvirt imported the full source code of its main repository to GitHub (ZSvirt/zsvirt) and open-sourced it under the GPL-3.0 license. It's a "core IaaS engine and cloud infrastructure foundation": the repo includes complete modules for compute, storage, network, identity, image, console, and portal; the primary languages are Java (78.2%) and Groovy (19.4%); and the repository topic tags span KVM, Proxmox, VMware/vSphere and more — positioning it directly against mainstream virtualization management stacks.

A little over two weeks after open-sourcing, the repository has gained 1.5k Stars, 290 Forks, and 103 Watches. There is no formal Release yet — it's in the "full code public, release cadence yet to start" phase, suitable for readers who want to follow the architecture and source code early by watching the repository.

Alongside the open-source release, the community operations side has kicked off the "ZSvirt Storytellers — Phase 1: YouTube Challenge" (published August 28 in GitHub Discussion #8): record one ZSvirt-themed YouTube video and earn rewards tiered by views — $100 for ≥500 views, $150 for ≥1,000 views, $200 for ≥2,000 views, plus a +$20 bonus for the first creator from each region; limited to 20 participants, with submissions due September 28 and settlement on September 30. The baseline requirement is to fully demonstrate "from ISO install to dashboard up and running"; there are three optional advanced directions: comparison with Proxmox/VMware, migrating existing VMs from VMware/Proxmox, and a snapshot create-break-restore drill. One video per person; view inflation disqualifies entries. Interested readers can sign up directly at Discussion #8.

Sources: GitHub: ZSvirt/zsvirt · Discussion #8: ZSvirt Storytellers — Phase 1: YouTube Challenge

VMware Explore 2026 Opens Today in Las Vegas (8/31–9/3)

VMware's annual conference, Explore 2026, opens today at the Venetian in Las Vegas for a four-day run. Based on Broadcom's official disclosure and VMware's pre-show blog posts:

Scale: more than 400 breakout sessions, plus Hands-on Labs and certification courses;
Keynote: the opening keynote is "Shaping the Future of Private AI Cloud and Agentic Innovation" (session PLE1837LV, 4:00 PM Pacific on 8/31), led by Ram Velaga, president of Broadcom's Infrastructure Software Group, joined by Paul Turner, VP of Products for the VCF division, and Purnima Padmanabhan, GM of the Tanzu division — private AI cloud and agentic applications are the definitive through-line of this show. The general session is open only to Full Event Pass holders on a first-come, first-served basis, with overflow simulcasts at The Hub and Bellini 2103;
Certification incentive: the Full Event Pass includes a VCAP exam voucher — a real subsidy for anyone pursuing certifications;
Global tour: after Las Vegas, Explore on Tour heads to Mumbai (9/29–30), Singapore (10/1–2), Frankfurt (10/13–14), Tokyo (10/20–21), London (11/18–19), and Washington (12/8), wrapping up in Sydney on March 3–4, 2027.

We will keep tracking VCF (VMware Cloud Foundation) releases and product announcements during the show and consolidate them in the next issue.

Sources: Broadcom IR: VMware Explore 2026 press release · VMware Explore 2026 official site

Proxmox VE 8 Reaches End of Life Today

Also on August 31, Proxmox VE 8 reaches the end of its official lifecycle. This generation, based on Debian 12 (Bookworm), was released in June 2023 and has been the workhorse platform for countless home labs and SMBs. Per Proxmox's official support matrix, VE 8 support ends in August 2026 — today. Nodes still running 8.x should already be seeing the EOL banner in their web management UI.

The upgrade path isn't complicated, but both official and community guidance stress "check first, then act":

Confirm backups are in place (PBS or offline copies);
Run the pve8to9 checker on every 8.x node, clearing blocking items one by one;
Follow the official upgrade documentation to roll each node up to VE 9 (based on Debian 13) — for clusters, upgrade standby nodes first, migrate workloads, then upgrade primary nodes.

Virtualization Howto's Brandon Lee reminded readers in his August 19 guide: don't treat EOL as a countdown to immediate downtime, but don't keep putting it off either — after EOL there are no more security updates, and the exposure surface only grows over time.

Sources: Virtualization Howto upgrade guide · Proxmox VE lifecycle

Product & Version News

QEMU 11.1.1 / 11.0.4 / 10.0.13 Released on Three Lines in Sync (8/26)

On August 26, QEMU shipped maintenance releases for three stable branches in sync: 11.1.1, 11.0.4, and 10.0.13 — all fix-oriented point releases, with source packages up on qemu.org signed with GPG. Shipping three lines on the same day is uncommon in QEMU's release history; distributions and cloud platforms running multiple concurrent versions should check their changelogs and assess whether to adopt them.

Source: QEMU official download page

Nutanix FY2026 Q4 Earnings: ARR $2.55B, Up 16% YoY (8/26)

Nutanix reported its fiscal Q4 (quarter ended July 31) and full-year FY2026 results: Q4 ARR of $2.55 billion (+16% YoY), quarterly revenue of $757.1 million (+16%), non-GAAP operating margin of 26.2% (up 790 basis points YoY), and free cash flow of $277.6 million; more than 3,000 net-new customers added during the year. CEO Rajiv Ramaswami called out new or deepened partnerships with AMD, Lenovo, NetApp, and NVIDIA, with AI and external storage support as key platform investment areas. With Broadcom's channel policy tightening, Nutanix's report is one of the most direct footnotes to the "VMware replacement" narrative.

Source: Nutanix IR press release

Backfill

Proxmox VE 9.2 debuts official Arm64 support (8/5): in early August, Proxmox announced PVE officially landing on 64-bit ARM, delivered on VE 9.2, bringing ARM servers and edge devices into the official support matrix. The announcement was still pinned on r/Proxmox this week.
VirtualBox 7.2.16 (mid-August): Oracle shipped a 7.2-series maintenance update fixing multiple guest and network-stack issues.
VMware Workstation 26H1 / Fusion 26H1 GA: r/vmware's pinned announcement this week shows both desktop virtualization products reached GA with the 26H1 releases.

Sources: Proxmox press release list · r/vmware pinned announcement

Community Buzz

HN Front Page: Boot a Virtual iPhone with One Command (vphone-cli, 406 points / 111 comments)

This week's hottest virtualization-related post on Hacker News is "Boot a Virtual iPhone via Apple's Virtualization.framework": the open-source project vphone-cli uses the iOS kernel Apple ships in PCC (Private Cloud Compute)/cloudOS images, combined with the iOS userland and patches, to boot a "virtual iPhone" on Apple Silicon Macs via direct virtualization. The technical consensus in the HN thread: this isn't a Corellium-style emulator — it's real virtualization, and apps can easily tell it apart from a real device. Commenters also remind: don't pick Japan or the EU region during setup (the VM can't pass third-party app-store compliance checks). The repo has reached 9.7k Stars and 1.3k Forks, primarily in Swift.

Sources: Hacker News discussion · GitHub: Lakr233/vphone-cli

Reddit This Week

r/Proxmox: the pinned post is indeed "Proxmox VE now available for 64-bit ARM (arm64)!" (551 votes / 119 comments) — community enthusiasm for ARM support exceeded expectations, with discussion focused on ARM server form factors beyond the Raspberry Pi and how to obtain images;
r/vmware: the VMSA-2026-0006 patch discussion thread (88 votes / 148 comments) has effectively become the "patch exchange center," with upgrade ordering and VCF-environment considerations as the main topics; two hands-on threads also ranked high — 100 GbE NIC tuning (a ConnectX-6 Dx only reaching 43 Gbit/s) and vCPU:pCPU oversubscription ratios.

Sources: r/Proxmox weekly top · r/vmware weekly top

Security Advisories

Tracking VMSA-2026-0006: Timeline of CVE-2026-59310 Exploitation

On July 29, Broadcom published VMSA-2026-0006 (updated to .2 on August 19), fixing five vulnerabilities across ESX / vCenter / Workstation / Fusion. Two of the vCenter flaws are both CVSS 9.8:

CVE-2026-59310: a directory-traversal vulnerability in the vCenter Syslog service that can be used for unauthenticated remote code execution;
CVE-2026-59309: an authentication-bypass vulnerability in VMware Directory Service.

In-the-wild exploitation: German incident-response firm QUIRSO confirmed the attacks began on August 3 — just five days after disclosure. As of its August 10 report, 361 distinct victim IPs had been recorded across 47 countries, with Germany (55), the United States (41), Turkey (38), Iran (26), and France (25) accounting for about half. The attack chain: directory traversal to write and execute arbitrary code → plant cron jobs → launch the open-source reverse-shell framework reverse_ssh to establish outbound C2, bypassing defenses focused on inbound detection. The Cloud Security Alliance's analysis note points out that because vCenter is the control plane of the entire virtualization environment, compromise means control over all managed hosts, VMs, and snapshots.

Ransomware follow-up: The Hacker News reports that some attackers deployed Babuk-derived ransomware (.babyk) on compromised vCenters. QUIRSO attributes the campaign to Chinese-language-context attackers with "medium confidence" (based on Chinese traces in scripts, tool reuse, and UTC+8 operating rhythms). We'd note: attribution carries uncertainty, and 361 victim IPs do not equal 361 organizations.

Remediation advice: the CVE has been added to CISA's KEV catalog. Broadcom confirms there is no workaround — the only effective option is to upgrade to fixed versions: vCenter 9.1.0.0300, 9.0.2.0100, or 8.0 U3k/U2f. Security teams can prioritize hunting for: anomalous cron jobs, outbound reverse_ssh connections, and abnormal Syslog-service writes.

Sources: Broadcom VMSA-2026-0006 · The Hacker News · CSA research note

Tools & Good Reads

vphone-cli: boot iOS on Apple Silicon via virtualization with one command — this week's most talked-about open-source project (see Community Buzz);
ixui: a pre-alpha Incus web UI — "Proxmox's skin, ESXi's bones," with hand-written React components, a cluster-aware instance tree, and a working SPICE console; fine for tinkering, not for production;
Virtualization Howto's PVE 8 EOL guide: the pre-EOL checklist and pve8to9 usage essentials;
LWN: multikernel patch series: a proposal to run multiple Linux kernels simultaneously on one bare-metal machine hit the HN hot list, adding a new variable to the old "kernel-level isolation vs. virtualization" debate.

Sources: GitHub: vphone-cli · GitHub: ixui · Virtualization Howto

Number of the Week

47 — the number of countries hit by the in-the-wild exploitation of CVE-2026-59310 (per QUIRSO's August 10 report, 361 victim IPs). Only five days separated patch release from weaponization: the management-plane patch window is narrowing to days.

Next Issue Preview

A recap of announcements from VMware Explore 2026 (VCF version developments, private-AI-cloud products), feedback on Proxmox VE 9 upgrades, and more voices from the community frontline. See you next issue.

About this publication: Virtualization Watch (VirtWatch Weekly) is a virtualization industry weekly produced by the ZSvirt community, published every Sunday, covering product news, security advisories, and community discussion across global virtualization and cloud infrastructure. It is compiled with AI-cluster assistance; every fact is linked to its source; we aim for balanced viewpoints and welcome corrections. Visit zsvirt.io for past issues and the video edition.

Introduces three ways to migrate VMs with ZSvirt — ZMigrate online migration, OVF import, and VMDK image upload — with a full hands-on walkthrough of ZMigrate from download and deployment through to a successful cutover.

ZSvirt — Thu, 27 Aug 2026 08:37:42 +0000

ZSvirt

Aug 27

ZSvirt Migration in Practice: Three Ways to Migrate VMs from VMware

#cloudnative #virtualmachine #vmware #cloudcomputing

10 min read

ZSvirt Migration in Practice: Three Ways to Migrate VMs from VMware

ZSvirt — Thu, 27 Aug 2026 07:39:19 +0000

Over the past few days, we announced ZSvirt’s open-source release, shared the reasoning behind that decision, walked you through creating your first VM, and broke down the architecture of the production-proven engine. In this final post of the series, we turn our attention to migration — how to move your existing VMware VMs into ZSvirt smoothly.

VM migration is an unavoidable part of building or replacing a virtualization platform. ZSvirt offers a complete migration capability matrix, with three ways to migrate depending on your migration scale, business continuity requirements, and data shape:

ZMigrate migration service: an online migration option. Deploy the migration service and a data gateway to connect directly to source platforms such as VMware vSphere, fully syncing each VM's OS and data to the target platform. It supports incremental sync, test-VM verification, and smooth cutover — a good fit for batch migration and scenarios with high business-continuity requirements.
Import a VM: an offline import option. Export the source VM as an OVF template (OVF, VMDK, and MF files), then on the target platform use "New VM > Import VM" to upload the template files and complete the import. Suited to a small number of VMs where a brief outage for export is acceptable.
Upload a VMDK image: a disk-level migration option. Simply upload the VM's VMDK disk file as a platform image (automatically converted to qcow2/raw), then create a VM from that image. It's the lightest option, suited to scenarios that only need the disk data migrated.

To help you choose, here's a quick comparison:

Dimension	ZMigrate migration service	Import VM (OVF)	Upload VMDK image
Approach	Online sync + cutover	Offline export/import	Offline disk upload
Business downtime	Short (cutover window only)	Longer (VM must be off during export)	Longer (VM must be off during copy)
Configuration preserved	Fully preserved; can clone network config/MAC	Based on the OVF descriptor	Not preserved; reconfigure needed
Scale	Batch migration	A few VMs	A few VMs, disk data only
Prerequisites	Deploy migration service, data gateway, VDDK	Export the OVF template	Prepare the VMDK disk file

Let's walk through each of the three approaches below.

1. ZMigrate Migration Service

ZMigrate is ZSvirt's online migration service. Its core idea is "sync first, cut over later": while a migration task runs, the source VM keeps serving traffic as usual and its data is continuously synced to the target platform, until a cutover window switches the business over and downtime is compressed to the absolute minimum.

Before you can use ZMigrate, you first need to install the migration service. Go to "Operations > Migration Service" to see the full workflow guide plus the basic and configuration info. The whole migration workflow can be summarized in six steps: download the installer from the official website → deploy ZMigrate → upload VDDK → add a data gateway → create the source platform → create the migration task, followed by the data sync and cutover stages.

1.1 Download the Installer from the Official Website

The migration journey starts on the official website. Go to the ZSvirt Resource Center, find ZMigrate for ZSvirt under the "Migration Tools" category, and download the installer for the version you need. The open-source version requires no license — download and go. Just confirm that the platform already has image storage configured, and that the image store has enough free space.

Once the installer is downloaded, you can start deploying it in the platform.

1.2 Deploy ZMigrate

Deploying the migration service takes two steps: upload the installer package, then install.

Upload the package: On the migration service page, click "Upload". Both URL and local upload are supported, and you need to specify a storage path for the package and its extracted files. Make sure this directory has enough free space, and avoid system directories such as /, /dev, /proc, /sys, /usr/bin, /bin, and /opt — otherwise the install may fail or the server may behave abnormally.

Install: After the upload finishes, click "Install" and choose an appropriate spec based on your needs. Key configuration items include:

Datacenter / Running location: ZMigrate is deployed as a VM-based data gateway; choose its datacenter and running location;
CPU / Memory: 8 vCPU / 8 GB by default; the number of CPUs directly affects migration concurrency;
Storage location / Disk: 100 GB system disk by default; specify a storage pool when the storage location is distributed storage;
Migration network / IPv4 address: specify a distributed port group as the migration network; it must be reachable from both the source and target platform networks. When DHCP is enabled on the network, an IP is assigned automatically; otherwise specify one manually.

Confirm and click OK; deployment of the migration service begins.

Deployment takes about 5–10 minutes. The page shows a "Deploying" status, so just wait.

1.3 Upload VDDK

If the source platform is VMware, you also need to upload the VDDK (Virtual Disk Development Kit) package. ZMigrate reads disk data from VMware source VMs through the VDDK interface — an essential part of the VMware migration path. Click "Upload" on the migration service page and upload your prepared VDDK archive; the system loads it automatically once the upload succeeds.

1.4 Add a Data Gateway

A data gateway is the relay between the source and target platforms and plays the key role in data transfer. It usually runs as a VM in the platform to provide gateway services, and you need to make sure it has network connectivity to the source platform, the target platform, and the migration service.

When you deploy ZMigrate, the platform creates a default data gateway. If you need to migrate VMs in batches, you can create additional data gateways to increase migration concurrency.

In the navigation bar, go to "Operations > Migration Resources > Data Gateways" and click "Add Data Gateway". There are two ways to add one:

Create a new VM: the platform creates a VM to act as the data gateway. Key settings include:
- Datacenter / Running location: choose the datacenter and running location for the VM;
- CPU / Memory: 8 vCPU / 8 GB by default; adjust based on migration concurrency needs;
- Storage location / Disk: 100 GB system disk by default;
- Network / IPv4 address: specify a distributed port group; it must be reachable from the source and target platform networks. When DHCP is enabled, an IP is assigned automatically; otherwise specify one manually. When IP address management is enabled, a manually specified address must be within the selected network segment.
Existing IP: if you already have a gateway VM, just enter its IP address. Once connected, the system automatically fetches the host name; click "Test" to check reachability.

Confirm and click OK; the data gateway is created.

1.5 Create the Source Platform

The source platform is the business platform to be migrated. When adding it, configure the following:

Name: set a name for the source platform;
Data gateway: select a created data gateway, or directly enter a new gateway IP address;
Platform type: VMware;
vCenter/ESXi address: enter the VMware environment address;
Username / Password: enter login credentials.

After filling these in, click "Test" to run a connectivity check. Once the source platform and data gateway are both ready, you can start creating a migration task.

After creation, the source platform list shows the platform type, vCenter/ESXi address, associated data gateway, and connection status. A "Connected" status means the source platform is successfully integrated.

1.6 Create a Migration Task

Creating a migration task has two steps:

Step 1: select the source platform and tick the source VMs you want to migrate.
Step 2: configure the parameters of the migrated VMs — target datacenter, cluster, host, storage location, bus type, CPU mode, target network port group, and more — then fill in the cutover settings.

Cutover is the key step in the whole migration flow — once data sync completes, it stops the business on the old platform and smoothly switches it over to the new one. The cutover settings offer several practical options:

Cut over immediately: automatically cut over once the initial data sync completes;
Create a rollback snapshot: create a snapshot of the target VM before cutover so you can roll back if anything goes wrong;
Power off the source VM automatically: shut down the source VM before cutover to avoid IP conflicts;
Install VMTools automatically: install VMTools automatically after the OS conversion completes.

Confirm and click OK; the migration task is created and its status enters "Syncing".

1.7 Sync and Cutover

After the task is created, the system automatically syncs the source VM's data to the target platform. You can see the task status "Syncing" in the task list.

When the status changes to "Ready for cutover", the data sync phase is complete and the flow enters the final cutover stage.

Click "Cut Over", read and confirm the risk notice, and the cutover begins, switching the VM's business to the target platform.

After a successful cutover, you can see that the VM from the original VMware platform has been migrated to this platform.

2. Importing a VM (OVF)

If you only have a few VMs to migrate and the business can tolerate a short outage for export, you can skip ZMigrate and migrate by importing an OVF template instead. The overall idea: export the VM as an OVF template on the source platform, then upload and import it on the target platform.

Step 1: Export the OVF template. On the source platform (such as VMware vSphere), shut down the target VM and export it as an OVF template. You usually end up with three kinds of files:

OVF file: the VM's descriptor file that defines its hardware configuration;
VMDK file: the VM's disk data file;
MF file: the manifest file used to verify file integrity.

Step 2: Import on the target platform. In the navigation bar, right-click the target cluster, host, or image, click "New VM", and choose "Import VM" as the creation method:

Then complete two parts of the configuration:

Upload info: choose an image store (used to temporarily hold the uploaded template files and deleted automatically once the VM is created), set the template type to OVF, and upload the OVF, VMDK, and MF files in order. Note that the VMDK file must match the configuration defined in the OVF file, including the number and content of the files.
Basic info: set the VM name, group, running location (host or cluster), and storage location (auto-allocated if not set); optionally configure high availability, VM/disk encryption, and whether to power on the VM automatically after import.

Confirm and click OK; the VM import completes. After import, it's recommended to install VMTools so some of the VM's configurations take effect.

3. Uploading a VMDK Image

Besides OVF template import, there's an even more direct approach: upload only the VM's disk files. If you already have the VM's VMDK disk file (for example, exported from VMware), you can upload it as an image to the image server, and the platform handles the format conversion automatically — uploaded to an ImageStore server, it's converted to qcow2; uploaded to a Ceph server, it's converted to raw. Then create a VM from that image and the migration is done.

The steps are:

In the main menu, go to "Resource Center > Cloud Resource Pools > Compute Configuration > Images", open the image page, and click "Add Image".
Configure it with these points in mind:
- Image type: choose system image;
- Image format: choose vmdk;
- Platform / VirtIO: choose the platform type based on the OS inside the image, and decide whether to enable VirtIO (when enabled, the guest OS loads VirtIO disk and NIC drivers for better performance; for a few older OSes that don't support VirtIO, you can leave it disabled);
- OS / CPU architecture / BIOS mode: choose settings that match the image; the BIOS mode must match how the image was packaged (Legacy or UEFI), otherwise the VM may not work properly;
- Image server: choose a created image server;
- Image path: supports URL (HTTP/HTTPS, FTP, SFTP) or local file upload; ImageStore servers support resumable uploads.

Confirm and click OK; wait for the image upload and format conversion to complete.

After the upload, you can open the image details page and check the image's MD5 value to verify integrity (note: VMDK uploads go through format conversion, so the MD5 value can't be used as an integrity check afterward). Then use the image to "Create VM", configuring CPU, memory, network, and other parameters as needed — once the VM is created, the migration is complete. Installing VMTools is recommended here as well.

In Conclusion

There's no absolute winner among the three migration methods — it all depends on your scenario: batch migration where business can't stop, choose ZMigrate; a few VMs that can tolerate a brief outage for export, choose OVF import; only disk files and you want to recover data quickly, choose VMDK image upload.

If you're planning a migration from VMware to ZSvirt, we suggest running through the full flow with one or two non-critical VMs first, getting familiar with the rhythm of sync, testing, and cutover, and then rolling out in batches. If you run into issues during migration, feel free to reach out to the ZSvirt open-source community for more details.

Join the Community

Issue reports: GitHub Issues
Community discussions: GitHub Discussions
Social media:
- YouTube: https://youtube.com/@ZSvirt
- LinkedIn: https://www.linkedin.com/in/zsvirt-community/
- X/Twitter: https://x.com/ZSvirt
- Email: community@zsvirt.io
- Discord: https://discord.gg/KHsw63z9xA

ZSvirt Architecture Explained: How a Production-Proven Virtualization Engine Is Built

ZSvirt — Thu, 20 Aug 2026 15:55:00 +0000

Over the past three days, we announced ZSvirt's open-source release, shared the reasoning behind that decision, and walked you through creating your first VM. Today, we're zooming in on the engine itself — not a blueprint for a new project, but a real architecture that has been running in production for years.

In an enterprise virtualization environment, the real challenge has never been just "can you create a VM." A mature virtualization engine has to face far more complex production problems: how to manage large numbers of physical servers uniformly, how to coordinate compute, storage, and network resources, how to recover automatically when a task fails, how to keep scaling as demand grows, and how to let different kinds of infrastructure capabilities plug in.

ZSvirt is built on the open-source ZSphere architecture. Its core value isn't just offering VM lifecycle management — it inherits a virtualization control architecture that has been validated in production. It lowers complexity through unified resource abstraction, ensures reliable task execution through async mechanisms and workflows, supports growth in resource scale through a message bus and modular design, and adapts to different infrastructure environments through a plugin architecture.

From an architectural standpoint, ZSvirt can be summed up in three keywords: ease of use, stability and performance, and extensibility and openness.

1. Ease of Use: Unified Abstraction That Hides Underlying Complexity

The underlying resources in a virtualization environment are highly complex. Compute nodes, storage pools, image repositories, physical networks, virtual switching, VMs, virtual disks, and snapshots — there are many dependencies between all of them. If you exposed that complexity directly to users and operators, the system would become hard to manage and hard to maintain over the long term.

The first thing ZSvirt's architecture solves is resource abstraction. It unifies the underlying infrastructure into standard resource objects — compute resources, storage resources, network resources, image resources, and VM resources. What users see in the UI or API is a clean resource model, not a scattering of low-level commands, config files, and host states.

Take creating a VM as an example. On the surface it looks like a single operation, but underneath it involves many steps: choosing an appropriate compute node, checking CPU and memory resources, preparing an image, creating a virtual disk, connecting to a virtual network, generating the VM configuration, and finally launching the instance on the target compute node. ZSvirt wraps all of these steps into a unified backend flow. Users don't need to care about each step — they just operate on the VM as a resource object.

This unified abstraction also makes operations simpler. Onboarding resources, syncing node state, querying VM state, mounting storage, configuring networks, and deploying and upgrading agents can all be done through a single management entry point. For users, ZSvirt is not a collection of scattered tools but a complete virtualization control engine — one that converges complex infrastructure relationships into a unified model, wraps multi-step resource operations into standard flows, and hides underlying differences behind a consistent management interface.

2. Stability and Performance: An Async, Stateless, and Lock-Free Architecture for Production-Grade Operation

Many operations in a virtualization system are long-running tasks. Creating a VM, migrating a VM, taking a snapshot, attaching a disk, expanding storage, and configuring networks can all involve multiple components and long execution times. If the management node handled these tasks in a synchronous, blocking way, a single slow operation could easily drag down the responsiveness of the whole system.

ZSvirt is designed to be fully async. Services inside the management node collaborate through asynchronous messages, tasks within a service are organized through async methods, and the management node communicates with compute, storage, and network components asynchronously as well. As a result, a long-running virtualization task never blocks the entire management process, and the system can handle a large number of resource operations at the same time. The async mechanism not only improves throughput, but also gives task execution more room for fault tolerance.

Another key design for stability is stateless services. Management services avoid relying on local state wherever possible, keeping critical state in the database, task contexts, and resource state records instead. That way, when a management node restarts, fails over, or scales out, the system won't become unrecoverable because some node's local state was lost. This matters a lot in production, because maintenance, upgrades, and crash recovery of the management service all need to minimize impact on business VMs.

Behind stateless services lies routing design such as a consistent hash ring. The system routes requests to a relatively fixed processing path based on the resource identifier, so that related operations on the same resource are dispatched and handled stably. For example, start, stop, migrate, and reboot operations on the same VM need to be ordered, while operations on different VMs can run in parallel. This reduces the need for shared state between management nodes and lowers the risk of concurrency conflicts.

For service organization, ZSvirt follows an in-process microservice approach. VM management, storage management, network management, image management, identity and authentication, and other capabilities are split into separate service modules, but they run inside a single unified management process and collaborate through a message mechanism. This keeps module boundaries clear without mixing all the logic together, while avoiding the heavy complexity of multi-process deployment. For a virtualization management system, that's a design that balances stability and engineering efficiency.

The workflow engine solves the problem of reliable execution of complex tasks. Virtualization operations are rarely done in one step — they're made up of many stages. For example, when creating a VM, the virtual disk may already have been created when the network configuration step fails. Without workflows and rollback, the system could be left with orphaned disks, inconsistent configs, or half-finished states. ZSvirt uses workflows to break complex operations into executable steps, each with clear execution logic and failure-handling logic. When a step fails, the system can roll back or clean up along the flow, reducing leftover inconsistent state.

From a performance perspective, the fully async architecture, stateless services, and lock-free design are the three defining traits of ZSvirt. The system doesn't rely on a sea of locks for safety — it manages concurrency through message routing, resource ownership, and task queues. Operations on the same resource are processed in order; operations on different resources run in parallel whenever possible. This raises overall throughput and keeps behavior more predictable under large-scale concurrency.

3. Extensibility and Openness: A Message Bus and Plugins That Adapt to Scale and Difference

As virtualization scale grows, the number of resources the system manages increases quickly: more compute nodes, more VMs, more virtual disks, more network configurations, and more concurrent tasks. At the same time, different enterprises have very different infrastructure environments — some use local storage, others shared or distributed storage; some networks are VLAN-based, others need more complex virtual network models; and different customers have different requirements for security, monitoring, backup, and image management.

ZSvirt's extensibility starts with the message bus. Management services communicate through a message bus instead of calling each other directly. This decouples the services, keeping VM management, storage management, network management, image management, and identity and authentication logically independent. Each service focuses on its own resource domain and collaborates with others through messaging.

ZSvirt also offers extensibility through a plugin architecture. Compute, storage, network, security, and monitoring capabilities can be extended as modules or plugins. The upper layer keeps a unified resource model and operation interface, while the lower layer can adapt to different implementations. For example, storage appears to the upper layer as virtual disks and storage pools, but underneath it can connect to different kinds of storage systems; networking appears as virtual networks and address configuration, but underneath it can adapt to different network schemes based on the environment.

The value of the plugin architecture is that it keeps the core system stable while allowing peripheral capabilities to evolve continuously. That matters especially for a virtualization engine like ZSvirt, because infrastructure environments keep changing — new hardware, new storage solutions, new networking modes, and new security capabilities keep appearing. Only an architecture that is open enough can keep adapting to different production environments.

Openness is also reflected at the API layer. Through standardized interfaces, ZSvirt can integrate with monitoring systems, operations tools, resource management systems, and automation tooling. So ZSvirt isn't just a standalone virtualization management product — it can also serve as the virtualization capability foundation within an enterprise's broader infrastructure.

4. In Conclusion

This architecture is not a blueprint drawn up for a new project — it's the result of the same engine running for years across more than 1,000 production environments. Today it's fully open as ZSvirt. Every mechanism described above — the message bus, the async framework, the workflow engine, consistent hashing, the agent layer — you can find the corresponding implementation in the repository.

Join the Community

Issue reports: GitHub Issues
Community discussions: GitHub Discussions
Social media:
- YouTube: https://youtube.com/@ZSvirt
- LinkedIn: https://www.linkedin.com/in/zsvirt-community/
- X/Twitter: https://x.com/ZSvirt
- Email: community@zsvirt.io

ZSvirt Quick Start: From ISO to Your First VM, Step by Step

ZSvirt — Wed, 19 Aug 2026 14:55:00 +0000

Over the past two days, we announced ZSvirt's open-source release and explained why we made this decision. Today, let's get hands-on.

If you're evaluating ZSvirt, the fastest way to learn it isn't reading the entire user manual — it's getting a VM running with your own hands.

This tutorial walks you through a minimal end-to-end path: install the management node → initialize the platform → add hosts, storage, networks, and images → create your first VM and log in to it. When you're done, you'll have a VM that can reach the internet and open a console — which means every core platform link is working.

Note: low-level command and API names still use legacy fields such as zstack-ctl, zstack-cli, PrimaryStorage, and BackupStorage, and the built-in test image is named ZStack-image-1.4. These are command-layer names and don't affect platform operations.

Before You Start: One Server Is Enough

The minimal setup is All-in-One: a single server acts as both the management node and a compute node. The hardware bar is low:

Item	Minimum	Recommended
CPU	Intel VT or AMD-V, at least 8 cores	24 cores or more
Memory	8 GB	24 GB or more
System disk	100 GB	200 GB or more
NIC	1 management NIC	Separate management, storage, and service networks
IP	Static IP	Static IP with DNS/NTP configured in advance

Two easily overlooked points:

Don't use DHCP. The management node IP is written into the platform configuration during installation, and changing it later is painful.
Sync the system time. If the management node's clock is earlier than the installation package's build time, the installer will fail outright — this is the first pit most newcomers hit.

Also prepare the ISO installation media: ZSvirt-x86_64-DVD-<version>.iso. You can boot from a physical optical drive, a USB stick, or an ISO mounted via the server's remote console. For USB creation we recommend Rufus or Fedora Media Writer — both support Legacy and UEFI boot.

Step 1: Install the Management Node from the ISO

Boot from the ISO and the installer enters Install ZSvirt by default — no manual selection needed. You'll land on the INSTALLATION SUMMARY screen:

Complete the four configuration items in order:

1. Installation Destination (system disk): select a disk as the system disk and click Done.

2. Software Selection (installation mode): choose ZSvirt Management Node and click Done.

3. Network & Host Name: click Configure... to open the NIC settings, switch IPv4 Settings > Method to Manual, click Add, and fill in your planned IP, netmask, and gateway:

Don't forget to enable Connect automatically with priority (0) on the General tab — otherwise the NIC won't come up after reboot:

4. Root Password: enter the root password twice and click Done.

Once all four items are ready, click Begin Installation. The system then reboots automatically and continues installing the ZSvirt management node service:

When the system enters the TUI and both MN and UI show Running, the management node is ready:

If you want extra assurance, log in and run two quick checks:

zstack-ctl status
zstack-ctl show_configuration | grep management.server.ip

If the installation fails, check /tmp/zstack_installation-*.log first; for Web UI issues, look at /usr/local/zstack/zstack-ui/logs/ui-install.log.

Step 2: Initialize the Platform

Point your browser at the management node IP and log in with the default credentials admin/password:

⚠️ In production, always change the default password immediately after your first login. It's a good habit even in test environments.

On first login, the platform guides you through creating a datacenter and a cluster. QuickStart only needs one of each: name the datacenter Datacenter-1 and the cluster Cluster-1:

Conceptually, a datacenter hosts a group of compute, storage, and network resources, while a cluster organizes hosts, datastores, and distributed switches. Create them first — everything else attaches underneath.

Step 3: Add the Management Node as a Host

The All-in-One trick is to add the management node itself as a host. Enter a name, the IP address (the management node IP), and the root password, click OK, and wait until the host shows as connected:

If this step fails, nine times out of ten it's SSH connectivity or a wrong root password — test manually with ssh root@<host IP> first.

Step 4: Add a Datastore and Image Storage

VM disks live on datastores; system images live on image storage. You need both.

Datastore: for testing, a local datastore is fine. Enter a name and a mount path (don't reuse the system root or a temp directory), then click OK:

Note: local datastores work for single-host verification but can't do cross-host migration. To try live migration later, switch to shared storage that all hosts can access.

Image storage: enter a name, the image storage IP (again the management node IP), and the password, click Test Connection, select Local Directory, and click OK:

Then add a system image (qcow2 or raw). For testing, the defaults are fine — just click OK. The system automatically provisions a test image, ZStack-image-1.4, which you can use right away to verify VM creation:

Import speed depends on the network path between the image storage, management node, hosts, and datastores, so be patient with large images. If it fails, first confirm the platform can read the image URL or local path (curl -I <image URL> or qemu-img info <image file> are handy).

Step 5: Create the Network

Create a distributed switch and a distributed port group. Using vlan-2344 as an example, configure the VLAN ID, IP allocation method, and DNS, then click OK:

A few tips:

For quick verification, enable IP address management and DHCP so VMs get IPs automatically.
Don't let the network segment overlap the gateway, DHCP service IP, or existing service addresses — this is the second most common pit, and it's why most "VM got no IP" reports happen.
All hosts in the cluster need a physical interface or bond with the same name; when using VLANs, the switch-side trunk/access configuration must match the platform.

Step 6: Create Your First VM

Click Create VM, enter a name, select the system image you just imported for disk 1, pick NIC 1, and confirm:

When the VM shows as Running and the console reaches a login screen, you're most of the way there.

ip addr
ip route
ping -c 4 <gateway IP>
ping -c 4 1.1.1.1
ping -c 4 example.com

Reading the results is simple:

Gateway reachable → distributed switch, port group, DHCP, and VLAN are all working;
External IP reachable → upstream routing works;
Domain resolves and responds → DNS works.

Step 7: Double-Check via CLI (Optional)

If you prefer the command line, run a full-chain health check on the management node:

zstack-cli

LogInByAccount accountName=admin password=<admin password>

QueryHost fields=uuid,name,managementIp,state,status
QueryPrimaryStorage fields=uuid,name,type,state,status,availableCapacity,totalCapacity
QueryBackupStorage fields=uuid,name,type,state,status,availableCapacity,totalCapacity
QueryL3Network fields=uuid,name,type
QueryImage fields=uuid,name,state,status
QueryVmInstance name=vm-test-01 fields=uuid,name,state,hostUuid,vmNics

Expected output:

Host state=Enabled status=Connected
PrimaryStorage state=Enabled status=Connected
BackupStorage state=Enabled status=Connected
Image state=Enabled status=Ready
VmInstance state=Running

If everything matches, the compute-storage-network-image-VM chain is fully working.

Troubleshooting Cheat Sheet

Symptom	Check first
Installation script exits	System time, root privileges, `/tmp/zstack_installation-*.log`
Failed to add host	SSH connectivity, root password, time sync, firewall
Failed to add image	Image URL readability, image format, free image storage capacity
VM gets no IP	Segment overlapping gateway/reserved addresses, DHCP enabled
Console won't open	`zstack-ctl status`, browser certificate

For a more complete list, see the documentation.

What's Next

Once the minimal environment works, continue in this order:

Change the default password and create individual admin accounts;
Configure NTP so the management node, hosts, and storage share the same time;
Switch the local datastore to shared storage and try cross-host live migration;
Build standard Linux/Windows template images and install VMTools for complete in-guest monitoring;
When you need dual-node high availability, see the HA chapter of the documentation.

A fully illustrated step-by-step reference is also available on the documentation site.

If you run into issues during deployment, feel free to open an issue on GitHub Issues or join the technical discussion on GitHub Discussions.

Source code: https://github.com/zsvirt/zsvirt
Download Center: https://zsvirt.io/download
Documentation Center: https://zsvirt.io/docs

Join the Community

Issue reports: GitHub Issues
Community discussions: GitHub Discussions
Social media:
- YouTube: https://youtube.com/@ZSvirt
- LinkedIn: https://www.linkedin.com/in/zsvirt-community/
- X/Twitter: https://x.com/ZSvirt
- Email: community@zsvirt.io

Why We Open-Sourced ZSvirt?

ZSvirt — Tue, 18 Aug 2026 14:00:00 +0000

Yesterday, we open-sourced ZSvirt. Today, we want to talk about why.

ZSvirt didn't start life as an open-source project. Its commercial counterpart, ZStack ZSphere, is a virtualization platform built by ZStack's engineering team over years of large-scale VMware replacement work — continuously developed, validated in real production environments, and deeply optimized.

The codebase now released as ZSvirt v1.0.0 has been running in demanding production environments for a long time. In these environments, the control plane manages more than 10,000 hosts, and a single VM can carry up to 768 vCPUs. For workloads this critical, makeshift maintenance is simply not an option.

That history matters to us, because virtualization is not a field where a demo alone proves long-term value.

A hypervisor's real worth is proven in critical moments and under pressure: when a disk fails, when you live-migrate during peak hours, when an audit deadline lands.

We've been through enough of these moments to believe that ZSvirt is ready for scrutiny from a wider community.

Why Now? Why Open Source?

Two years ago, this decision wouldn't have felt as urgent.

Since Broadcom acquired VMware, the way we talk to infrastructure administrators has changed. Teams running vSphere — and teams also running Hyper-V, Proxmox VE, or Nutanix — are re-evaluating their virtualization strategy, often under cost and budget pressure.

In these conversations, the questions we keep hearing are not about features. They are:

"Can we read the code?" "Can we audit it?" "If the vendor's strategy changes down the road, how do we protect ourselves?"

We could have answered these questions with promises. Instead, we chose to answer with a public repository. ZSvirt v1.0.0 is the first release to open the complete source code, build scripts, a signed installation ISO, and the accompanying documentation.

More importantly, in our view, "zero vendor lock-in" should live in the license and the code itself — not as a tagline in a product brochure. The virtualization layer carries a large share of an enterprise's business-critical workloads. If users can't read, audit, or build from the code themselves, a critical part of their infrastructure remains a dependency they don't fully control. Our belief is simple: infrastructure this important should not be subject to any single vendor's commercial decisions — including our own.

We understand that people may have questions about this decision, because we'd ask the same ones. An infrastructure open-source project launched by a commercial company naturally raises legitimate concerns: will the license change as the project grows? Is this an open-core play that keeps the real capabilities hidden?

So we want to state our commitments publicly.

A Transparent Business Model

We will clearly define the boundary between the community edition and the commercial offering.

What stays open, always:

The virtualization platform itself, including compute, storage, and network virtualization;
The full API surface;
ZMigrate, our free and unlimited migration tool;
The Terraform Provider and Go, Python, and Java SDKs.

What's commercial:

Enterprise-grade support services from ZStack;
Capabilities exclusive to the enterprise edition.

We will maintain public documentation that spells out which capabilities belong to the community edition and which to the commercial edition — and we will not move already-open features behind a paywall. That commitment applies to future releases as well.

On the license: ZSvirt will continue to be released under GPL 3.0. The license will not change. We want that to be clear from day one.

Where We Fit

We don't believe ZSvirt is the only right choice for every organization, and we're not here to dismiss approaches the industry has widely adopted. Organizations have different infrastructure needs. ZSvirt is built for teams and individuals who want enterprise-grade capability, openness, and control at the same time.

There are several valid paths in virtualization, each serving different operational needs:

Public cloud managed services: the provider runs operations; you pay per workload.
Hyperconverged infrastructure platforms: integrated hardware and software from a single vendor.
A self-built KVM stack: for teams with deep Linux expertise willing to build their own toolchain.
Kubernetes-native virtualization: for organizations all-in on Kubernetes, managing infrastructure cloud-natively.
Lightweight single-node virtualization: for small deployments and edge scenarios that don't need a full cluster control plane.

Many enterprise teams, though, have a different set of needs. They want to keep the familiar operating model of a traditional virtualization platform while gaining the openness, flexibility, and control that come with an open foundation. These teams typically manage infrastructure around familiar concepts — clusters, hosts, VMs, networks, and datastores — and need production-grade capabilities. At the same time, they want to avoid hardware and platform lock-in, don't want Kubernetes as a prerequisite for managing VMs, and want a fully open API.

For these teams, ZSvirt offers:

Scale: a single control plane managing 10,000+ hosts;
Openness: 2,000+ asynchronous RESTful/OpenAPI endpoints, with Go, Python, and Java SDKs;
Security: native Secure Boot, vTPM 2.0, VM encryption, and built-in key management;
Networking: distributed switches and port groups, plus SR-IOV-accelerated networking with live migration support;
Migration: ZMigrate, an agentless migration tool running at the virtualization layer, cutting over in as little as 5 minutes;
Enterprise capabilities: HA, DRS, snapshots, backup, alerting, and more.

If your organization is looking for that balance, ZSvirt is built for you. If another approach fits your needs better, we respect that — and encourage you to adopt the platform that best suits your environment.

Our Community

For us, open-sourcing ZSvirt is not a one-time launch event. It's the start of a long-term collaboration.

Concretely:

A public roadmap, updated quarterly, so users and contributors can see where the platform is heading;
Fully public contribution guidelines — contributions of every kind are welcome, from docs and testing to code;
A predictable community process: technical discussions happen on GitHub Discussions; bugs and documentation issues are tracked in GitHub Issues, with the engineering team responsible for each module participating directly. We respond to issues on business days.

We look forward to the community shaping where ZSvirt goes next — open collaboration builds stronger software.

Try ZSvirt

Download the ISO — published with checksums and cryptographic signatures — and explore ZSvirt in your own environment:

Source code: https://github.com/zsvirt/zsvirt
Downloads: https://zsvirt.io/download
Documentation: https://zsvirt.io/docs

Star or watch the ZSvirt repository to follow new releases, development progress, and technical discussions.

Join the Community

Issue reports: GitHub Issues
Community discussions: GitHub Discussions
Social media:
- YouTube: https://youtube.com/@ZSvirt
- LinkedIn: https://www.linkedin.com/in/zsvirt-community/
- X/Twitter: https://x.com/ZSvirt
- Reddit: https://www.reddit.com/r/ZSvirt/
- Email: community@zsvirt.io

ZSvirt is Open Source: Enterprise-Grade Virtualization, Now Open to the Community

ZSvirt — Mon, 17 Aug 2026 02:29:17 +0000

ZSvirt is now officially open source under the GPL 3.0 license. The full source code is available on GitHub, and ISO installation images and technical documentation are available on the community site.

KUALA LUMPUR / SHANGHAI, August 12, 2026 — ZSvirt, launched by infrastructure vendor ZStack, today officially announced its open-source release under the GPL 3.0 license. The complete source code, ISO installation images, and technical documentation are now available at:

Source code: https://github.com/zsvirt/zsvirt
Community site: https://zsvirt.io

Since Broadcom's acquisition of VMware and the licensing changes that followed, more organizations are re-evaluating their virtualization strategy around TCO, looking for greater flexibility, transparency, and control over how they run workloads. ZSvirt is going open source at this moment to give teams evaluating alternatives an open, proven option — one that doesn't require changing existing operational habits.

ZSvirt brings the enterprise-proven ZStack ZSphere virtualization engine to the open-source world. As a lightweight, scalable platform, it gives teams full control over their infrastructure — from homelabs to hyperscale production environments — without vendor lock-in. Unlike approaches that require adopting an entirely new operational model, ZSvirt keeps the familiar VM-centric workflows around clusters, hosts, virtual machines, storage, and networking, while letting users evaluate, deploy, and take part in the platform's evolution.

Core Capabilities

Large-scale virtualization: a single control plane manages 10,000+ hosts; a single VM supports up to 768 vCPUs.
Seamless VMware migration: 100% agentless migration. The built-in ZMigrate toolset runs entirely at the virtualization layer, with full-disk block copy and background incremental sync, cutting over in as little as 5 minutes.
Built-in security: native VM Secure Boot, vTPM 2.0, VM encryption, security-group microsegmentation, and immutable audit logs.
Open integration: 2,000+ production-ready RESTful/OpenAPI endpoints, a native Terraform Provider, and Go, Python, and Java SDKs.

Proven in Production

ZSvirt runs the same enterprise-grade engine as ZSphere, validated in more than 1,000 production environments — including VMware replacement projects — across finance, healthcare, education, manufacturing, transportation, and other industries. Today, we're opening that engine to the community under GPL 3.0, helping organizations migrate and upgrade their virtualization platforms without disrupting their business.

Building the Future of Open Virtualization Together

Over the next six to twelve months, the ZSvirt project will focus on accelerating platform maturity, expanding ecosystem compatibility, and improving operational efficiency across diverse infrastructure environments. The project roadmap, contribution guidelines, and governance documents will remain public, so users and contributors can follow where the platform is heading. Technical discussions happen on GitHub Discussions; bugs and documentation issues are tracked in GitHub Issues and handled directly by the engineering teams responsible for each module.

License and Governance

ZSvirt is released under GPL 3.0. This strong copyleft license allows anyone to freely use, modify, and redistribute the source code, while requiring derivative works to be released under GPL 3.0 as well. We'll detail the boundary between the community and commercial editions in a follow-up post.

This ensures that every improvement flows back to the community — and that ZSvirt remains free and open, permanently.

Quick Start

Download Center: https://zsvirt.io/download
Documentation Center: https://zsvirt.io/docs

Join the Community

Issue reports: GitHub Issues
Community discussions: GitHub Discussions
Social media:
- YouTube: https://youtube.com/@ZSvirt
- LinkedIn: https://www.linkedin.com/in/zsvirt-community/
- X/Twitter: https://x.com/ZSvirt
- Email: community@zsvirt.io