DEV Community: ZSvirt

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