DEV Community: ZSvirt

Virtualization Watch Issue 003: Citrix NetScaler Zero-Days Hit Over a Weekend; Sidero Builds a Hypervisor into Talos Linux

ZSvirt — Wed, 30 Sep 2026 08:16:01 +0000

September 28, 2026 · Biweekly · Coverage window: 9/14–9/27

From the Editor

This issue opens with a severe vulnerability chain disclosed over a weekend.

On Saturday (9/26), the security firm watchTowr issued a sudden public warning: two NetScaler remote code execution flaws with no patches yet were already being exploited in the wild. The Dutch national cyber security center (NCSC-NL) went further, privately telling some organizations to take their appliances offline. On Sunday (9/27), Citrix published advisory CTX697096, fixing eight CVEs at once — two of them zero-days rated CVSS v4 9.5. CISA added both to its Known Exploited Vulnerabilities catalog the same day, leaving federal agencies three days to patch.

The same week, Sidero Labs put a hypervisor directly into Talos Linux, managing containers and virtual machines through one operating system and one API. Incident response and the evolution of the hypervisor itself are this issue's two threads.

In This Issue

Citrix NetScaler: Two Zero-Days Land Over a Weekend, with a 3-Day KEV Deadline

On September 27 (Sunday), Citrix published advisory CTX697096, fixing eight vulnerabilities in NetScaler ADC and NetScaler Gateway. Two of them were confirmed to be exploited in the wild:

CVE-2026-88771 (CVSS v4 9.5): improper input validation lets an unauthenticated attacker execute arbitrary commands. Every deployment model is affected, including default configurations — no optional feature has to be enabled.
CVE-2026-88772 (CVSS v4 9.5): memory overflow leading to remote code execution or denial of service. The trigger is DTLS, and DTLS is on by default for VPN virtual servers.

The fixes are in 14.1-73.37 and later, or 13.1-64.23 and later; 13.0 and 12.1 are end-of-support and need to be migrated. The same advisory covers six further flaws (CVE-2026-88773 through 88778), including a request-smuggling issue rated 9.3.

On September 26, watchTowr issued its public warning (official FAQ), saying the vulnerabilities came out of a forensic investigation and that the information was credible. That same day, some administrators reported receiving "take the appliance offline" advice relayed by vendors and security teams, tracing back to an NCSC-NL private pre-notification. On September 27, the day the advisory landed, CISA added both CVEs to the KEV catalog, giving federal agencies until September 30 — three days.

For context, this is the third time NetScaler has entered the KEV catalog this year: CVE-2026-8452 in August, then CVE-2026-19490 on September 9. NetScaler appliances sit at the enterprise network edge, handling VPN, load balancing, and authentication — once compromised, they serve as a pivot into the internal network.

Sources: The Hacker News (9/27), Citrix CTX697096, watchTowr FAQ

Sidero Ships Talos Hypervisor: a Hypervisor Built into the Kubernetes Operating System

On September 14, Sidero Labs announced native hypervisor capability in Talos Linux (official press release): enterprises can manage containers and virtual machines with one operating system and one API, without running Kubernetes for one job and a virtualization stack for another, and without having to learn KubeVirt first to run VMs. The same release adds direct container scheduling without Kubernetes, aimed at single-node edge deployments.

The essentials:

Fully open source, still under MPL-2.0. The alpha and a public demo arrive at TalosCon 2026 (Amsterdam, October 15–16), with general availability targeted for December 2026.
A second announcement the same day explains where the resources come from: Sidero Labs is being acquired by Yardi, a real-estate software company (official blog 9/14). Yardi was already running Talos in production; the company says the team will keep operating independently and that the open-source roadmap is unchanged.
The next day (9/15), Sidero rolled out a commercial edition, Talos Enterprise Linux: 24/7 support SLAs, FIPS builds, SBOM/VEX artifacts, and CVE-response SLAs — covering what a compliance-driven buyer normally has to assemble from several vendors.

Talos's positioning is distinct: rather than building another vSphere, it makes the hypervisor a native capability of an immutable infrastructure operating system.

ZSvirt Community News: First Open-Source Monthly Report and Roadmap

This publication is produced by the ZSvirt community. This section covers the publisher's own news.

On September 15, ZSvirt published the first issue of its open-source monthly report, Around the World). It looks back at the first month since the full open-source release on August 12 (GPL-3.0) and publishes the product roadmap for the first time.

Second-Half 2026 Roadmap (First Public Release)

On hardware and release process: aarch64 support is under evaluation, and GPU components are on the plan; a formal release process (GitHub releases and tags) will follow, making version history traceable. Product work spans five areas:

Area	Planned work
Security	VM disk encryption, VM migration encryption
DRS and migration	Data-disk-only migration; live and cold migration for SAN, cold migration for NFS
ZMigrate 2.1	Pre-migration checks to head off complex migration risk, with a simpler, smarter flow
Operations	New metrics: VM CPU ready time, disk read/write latency, network packet loss, host CPU ready time; finer-grained external syslog forwarding; NVMe and FC IOPS/latency monitoring; a bundled QXL driver in VMTools
Inventory	Storage and VM registration extended to same-site scenarios

A reminder: Storytellers Phase 1 (the YouTube challenge) closes tomorrow, 9/28. Creators interested in taking part should sign up at GitHub Discussion #8 before the deadline.

Sources: ZSvirt open-source monthly report issue 1 (9/15), GitHub: ZSvirt/zsvirt

Product & Version News

Incus 7.5 / 7.5.1: Eleven Security Fixes, OVN Child Networks, GPU P2P (September 25)

Incus 7.5 landed on September 25 with a dense changelog:

Security: eleven fixes at once, including a serious btrfs path traversal (CVE-2026-85185 / CVE-2026-85526) and arbitrary writes through symlinks in the migration data stream. This was a coordinated disclosure with Canonical, whose LXD 5.21.8 / 5.0.10 / 4.0.14 shipped the matching fixes on September 23; the same fixes are in LXD 6.9.
Networking: OVN child networks, for more flexible logical topologies.
Operations: instances can move across projects, and live migration is stronger.
GPU: NVIDIA GPUDirect P2P support (nvidia.clique 0–15), so multi-GPU passthrough no longer takes a detour.
Platform: a new NetBSD guest agent.

The 7.5.1 that followed is not a follow-up fix release — it is a re-release, after 7.5.0 failed to produce release artifacts.

VirtualBox 7.2.18 → 7.2.20: Two Maintenance Updates in a Week (September 15, September 22)

Oracle shipped VirtualBox 7.2.18 on September 15 with eleven fixes: a blue screen after saving state on Windows 11 on ARM guests, VDI image corruption, and adaptation for the RHEL 10.3 kernel, among others. That month's Oracle Critical Patch Update also fixed CVE-2026-87279. On September 22 came 7.2.20, an urgent release targeting a regression 7.2.18 introduced (GitHub issue gh-870, VERR_SUP_VP_FOUND_EXEC_MEMORY at startup). With two releases in one week, desktop virtualization users should go straight to 7.2.20. Source: VirtualBox News

Kata Containers 4.2.0: 80-Plus Changes (September 15)

Kata Containers 4.2.0 arrived on September 15 with more than 80 changes: the guest rootfs moves to Ubuntu 26.04; the toolchain moves to Go 1.26.7 / Rust 1.96; the Rust runtime (runtime-rs) gains fd-passing block-device and VFIO device support for QEMU; and the Dragonball sandbox gains virtio-rng. Worth a look for confidential-container and lightweight-sandbox users.

Harvester v1.9.0: a Whole-Stack Upgrade (September 16)

SUSE's hyperconverged platform Harvester v1.9.0 shipped on September 16: the foundation moves to RKE2 v1.36, Longhorn v1.12, Rancher v2.15, and Kube-OVN v1.16, on an SLE Micro 6.2 base, with a preview of the Longhorn v2 storage engine. Fix releases are moving fast — v1.9.1-rc1 on September 17 and rc2 on September 23 — so GA should not be far off.

Cloud Vendors: AWS T8i and Google X5 Both Reach GA

AWS EC2 T8i is generally available (9/17): the burstable line gets a generational refresh, with up to 1.25x the network bandwidth, up to 2.4x the EBS bandwidth, and up to 30 percent better price-performance than T3. It launches in 16 regions, in sizes from nano to medium. Sources: AWS What's New, AWS blog
Google Cloud X5 is generally available (9/25): per-instance memory rises from 32 TB on X4 to 48 TB, aimed at very large-scale SAP HANA scale-up and RISE with SAP. Source: Compute Engine release notes

Gartner Publishes Its First Server Virtualization Platforms Magic Quadrant (9/14)

On September 14, Gartner published the Magic Quadrant for Server Virtualization Platforms (analysts: Tony Harvey, Daniel Bowers, Paul Delory, Tony Iams, Owen Marino), evaluating 17 vendors on Ability to Execute and Completeness of Vision — the first industry-wide assessment since Broadcom acquired VMware and licensing models were upended. Per Virtualization Review's reading of the report, Gartner holds that Broadcom's acquisition of VMware has "reinvigorated" the server virtualization market (Virtualization Review, 9/23).

Teasers and Snapshots

QEMU 11.1.2 entered freeze on September 26 with 92 patches queued; the release is planned for September 28, just past this window.
OpenStack 2026.2 "Hibiscus" is on schedule for September 30.
Linux 7.3-rc5 shipped on September 27 with KVM fixes (rc4 was September 20).
An "Orphaned VMs" RFC from the KVM community (9/20, authored by Pasha Tatashin) would let virtual machines keep running while the host kernel is updated in place, pushing downtime toward zero.
KVM Forum 2026 is set for November 12–13 in Vancouver.

Community Buzz

HN: virtio-nvgpu Reaches 98–100 Percent of Native GPU Performance Inside a KVM Guest (154 points / 65 comments)

Nestri Labs' open-source virtio-nvgpu hit Hacker News on September 24: a purpose-built virtio GPU protocol gives KVM guests close to native (98–100 percent) NVIDIA GPU performance, and a single GPU can be shared across multiple VMs. The trade-offs: isolation is weak (no IOMMU isolation, no seccomp), which suits single-tenant and gaming/streaming workloads but not multi-tenant production. The comment thread's consensus: the direction is compelling, but it is still far from a vGPU replacement.

Security Advisories

[Critical] Arista VeloCloud Orchestrator Zero-Day: CVSS 10.0, Already Exploited (September 22)

Arista published SA0183: on-premises VeloCloud Orchestrator (VCO, formerly the VMware SD-WAN orchestrator) carries an improper input validation flaw, CVE-2026-93952 (CVSS 3.1 10.0 / 4.0 9.5), affecting versions 5.2.0–5.2.3.15, 6.1.0–6.1.3.7, 6.4.0–6.4.2.7, and 7.0.0–7.0.0.2. At disclosure there was active exploitation and published indicators of compromise; CISA added it to the KEV catalog the same day, giving federal agencies three days (until 9/25). The fixes are in 5.2.3.16+ and 6.4.2.8+, and the 6.1.x and 7.0.x trains had no patch on disclosure day. Arista's guidance is to limit access to the VCO web interface to trusted administrative networks and to watch for unexpected outbound traffic and backdoor processes; note that exploitation requires certificate-based Edge-to-VCO authentication to be configured and network reachability to the web interface. Hosted instances have already been patched by Arista.

QEMU 9pfs Guest Escape: CVE-2026-93834 (Disclosed September 22)

QEMU's 9p filesystem (virtio-9p) has a use-after-free race, CVE-2026-93834 (CVSS 8.8): a guest can race Tlcreate/Twalk messages to escape a shared directory and read, write, and execute on the host with the QEMU process's privileges. A public proof of concept exists. Mitigation: disable 9pfs and use virtio-fs instead. Red Hat published its advisory page on September 25. Anyone using 9p shared directories for desktop virtualization or development environments should check their setup.

Cloudflare Containers: Cross-Tenant Data Residue (Disclosed September 24)

Cloudflare published a detailed technical post-mortem: the shared storage pool behind its Containers and Sandboxes products had skip_block_zeroing enabled, so reclaimed 64 KiB disk blocks were handed to new tenants without being zeroed. Writing 4 KiB was enough to read 60 KiB of another tenant's leftover data (reproduced in 18 of 24 deployments and on 20 of 22 nodes). The researcher Oren Yomtov (Accomplish) reported it through HackerOne on September 4; the core fix was deployed on September 7, and cleanup of existing disks and image caches completed on September 19. Reviewing historical disk I/O telemetry, Cloudflare found no evidence of malicious exploitation, and because scheduling is automatic, an attacker could not target a specific victim. The root cause sits in the storage layer, not in container escape.

vCenter CVE-2026-59310 Follow-Up: CISA Confirms Ransomware Gangs Are Using It (September 15)

According to BleepingComputer, CISA has confirmed that ransomware gangs are exploiting the vCenter flaw CVE-2026-59310; Shadowserver data shows 450-plus vCenter instances still exposed to the internet, and the official FIRST EPSS score is 2.6 percent (84.5th percentile, data dated 2026-09-27). The federal patch deadline (8/21) has passed; unpatched instances are overdue.

Other Security News

Three Linux kernel flaws entered the KEV catalog (9/18): CVE-2025-39682 (kTLS, 9.8), CVE-2026-53266 (8.8), and CVE-2025-39964 (7.8).
libvirt flaw CVE-2026-18917 (7.8), fixed by Red Hat in RHSA-2026:68510 (9/17).
No new VMware VMSA advisories were published within this window.

Tools & Good Reads

virtio-nvgpu: the headline HN post of this issue — near-native NVIDIA GPU performance in KVM guests, with one card shared across VMs (mind the weak-isolation caveat).
pve-meta: declarative, YAML-based management of Proxmox cluster configuration; a well-received community project this fortnight.
Drop: a rootless container sandbox, positioned against gVisor and sysbox but without requiring privileges.
Floci / Fakecloud: new local AWS emulation options beyond LocalStack; both hit HN this fortnight.
William Lam: "Multi-Tenant Model Sharing in VCF 9.1.1 GA" — essential reading for private-AI scenarios.
A community-rewritten VCF 9.1.x deployment guide: a more down-to-earth companion to the official docs, full of field notes.

Number of the Week: 3 (days)

CISA twice squeezed the federal patch deadline down to three days this fortnight: Arista VeloCloud (listed 9/22, due 9/25) and the Citrix NetScaler zero-days (listed 9/27, due 9/30).

The patch window for edge-device vulnerabilities has moved from weeks to days.

Next Issue Preview

QEMU 11.1.2 stable release (frozen, 92 patches).
OpenStack 2026.2 "Hibiscus" (9/30).
VMware Explore on Tour: Mumbai (9/29–30) and Singapore (10/1–2); the Frankfurt stop (10/13–14) is expected to bring more detail on the returning vSphere Standard.
TalosCon 2026 (Amsterdam, 10/15–16): the public Talos Hypervisor alpha demo.
Harvester v1.9.1 GA.
Azure NVv4 series retirement (9/30).
KVM Forum 2026 (Vancouver, 11/12–13).

About this publication: Virtualization Watch (VirtWatch Weekly) is a biweekly virtualization industry publication produced by the ZSvirt community, covering product news, security advisories, and community discussion across VMware/Broadcom, Proxmox, KVM/QEMU, Hyper-V, KubeVirt, Nutanix, and more. It is compiled with AI-cluster assistance; every fact is linked to its source; we aim for balanced viewpoints and welcome corrections. All factual content in this issue was verified against primary sources (official press releases, official blogs, GitHub release pages, original HN posts, etc.), with key source pages captured by the editors. News window: September 14–27, 2026; editorial deadline: September 27, 2026. Visit zsvirt.io for past issues and the video edition.

10 Reasons You Must Install ZSvirt VMTools

ZSvirt — Fri, 18 Sep 2026 07:56:35 +0000

On both Windows and Linux, ZSvirt VMTools is not an optional utility. It is the link that brings a virtual machine into the platform's management loop.

10 Reasons You Must Install ZSvirt VMTools

A virtual machine that boots and answers on the network is merely running. It becomes an operational resource only when the platform can see what is happening inside the guest, deliver management actions reliably, and keep that control through backups, migrations, and network failures.

VMTools is what makes that possible. Without it, the platform manages a black box that happens to consume CPU and memory.

What VMTools Actually Consists Of

ZSvirt VMTools bundles four components. It is worth knowing which is which, because some capabilities come from VMTools and others already ship with the operating system.

ZSvirt monitoring agent — collects runtime metrics from inside the guest and feeds the platform's monitoring charts and alerts.
QEMU Guest Agent (QGA) — establishes a management channel between the platform and the guest that does not depend on the VM's business network.
VirtIO drivers — provide virtual disk, network adapter, memory balloon, and guest-communication devices.
Cloudbase-Init (cloud-init on Linux) — applies first-boot configuration: users, passwords, hostname, network, and User Data.

Mainstream Linux distributions include VirtIO drivers natively, so on Linux the driver component often needs no installation.

Installing VMTools is not about displaying a few extra charts. It is what makes observability, control, recoverability, and automation work as one system.

Ten Reasons VMTools Is Not Optional

01. See what is actually happening inside the VM

An application starts slowing down while the host-level resource charts look perfectly normal. Allocation data alone cannot tell you whether the guest is short on memory, running out of disk space, or hitting an internal workload spike.

The ZSvirt monitoring agent collects CPU, memory, disk capacity, and other metrics from inside the guest and ships them to the management platform. That gives you both current diagnosis and historical trend: recurring peaks, capacity growth, and the evidence you need to resize a workload before it becomes an incident.

Capability boundary: Host monitoring remains useful, but it cannot replace guest-level visibility.

02. Quiesce the file system for consistent snapshots and backups

Databases, file services, and applications write continuously. When the platform needs to create an online backup or snapshot, taking a raw point-in-time image of a disk that is still changing produces a crash-consistent result at best.

VMTools provides guest quiescing: before the snapshot forms, the file system is brought to a controlled, consistent state, and writes resume once it completes.

On Windows, QGA coordinates through VSS — the backup requestor, application writers, and the snapshot provider. Applications commit transactions, roll logs, and flush caches; VSS briefly freezes write I/O; the platform captures the point-in-time snapshot; VSS then tells applications to resume. As long as the workload ships a functioning VSS writer, you get application-aware consistency rather than merely crash consistency.

On Linux, QGA can run a pre-freeze hook, then syncs and freezes freezable local file systems. The kernel lets in-flight transactions complete, writes dirty data, metadata, and journal entries to disk, and blocks new modifications. After the snapshot, QGA thaws writes and can invoke a post-thaw hook. Network file systems are not frozen by default.

Capability boundary: File-system consistency is guaranteed by default. Database-level consistency still requires a VSS writer, a freeze hook, or the database's own backup tooling.

03. Shut down and restart guests cleanly

Before host maintenance, a cluster upgrade, or a power drill, you may need to shut down or restart VMs in bulk. Doing it by hand means logging into each one, and the maintenance window disappears into repetitive work. Cutting power instead risks data that never reached disk.

Through QGA, the platform can ask the guest operating system for a normal shutdown or restart: services stop in order, applications finish their work, and cached data is flushed. The platform then continues with migration or maintenance based on the VM's actual state, which makes bulk power operations predictable.

Capability boundary: If a guest is genuinely hung, the request can still fail. Plan for timeouts and a fallback.

04. Get accurate IP, NIC, and guest information

A VM changes its static IP, gains a NIC, adjusts routes, or grows a file system — and the platform still shows the old values. Remote connections, automated audits, and downstream deployment steps then target the wrong address, or flag a healthy VM as unreachable.

QGA queries NICs, IP addresses, hostname, and file systems from inside the guest, and the platform surfaces that data. Compared with inferring from DHCP, switch tables, or the host, what the guest reports directly reflects the operating system's current state — a far more reliable input for automation.

Without it: Guest information may be empty, stale, or inconsistent with reality.

05. Do day-two operations without logging in

VMs in production still need their login password reset, hostname changed, IP, DNS, or MTU adjusted — or the same inspection and remediation run across a batch. Logging into each one is slow and easy to get subtly wrong.

QGA provides a runtime channel from the platform into the guest operating system. Within what the current version supports, the platform can push configuration, execute commands or scripts, and read or write files. Routine changes and bulk remediation become platform-initiated actions rather than a queue of individual sessions.

Capability boundary: Reason 05 covers runtime operations. Reason 10 covers first-boot deployment.

06. Keep a rescue path when the network fails

A single bad IP, route, firewall rule, or NIC configuration can cut off remote access and business traffic at the same time. Every conventional way into the guest is now gone, and a small misconfiguration becomes an extended outage.

QGA typically communicates over a virtio-serial channel that does not depend on the VM's business IP. Within the platform's supported scope, operators can still read guest information, push a corrected configuration, or run a repair script — turning what would have been a console session or a disk-attach-and-repair into an online fix.

Capability boundary: This is not hardware-level out-of-band management. The guest kernel, QGA, and the communication device all have to be working.

07. Keep guest and host time in sync

After a long pause, a save-state restore, or a migration, a VM can drift noticeably in time. A few minutes of skew is enough to break domain authentication, fail certificate validation, miss scheduled jobs, and scramble the ordering of logs across systems.

QGA exposes interfaces for reading and setting guest time, so the platform can correct drift after exactly these lifecycle events. Continuous day-to-day synchronization stays with the guest's native time service — a combination of "correct quickly after an event, stay synced while running."

Implementation note: Standardize on one time source and one sync strategy. Multiple continuous correction mechanisms can fight each other.

08. Unlock the performance of virtual devices

Databases push heavy disk I/O. Application servers need network throughput. Resource pools need to reclaim and rebalance VM memory dynamically. Generic emulated devices may work, but they add overhead and cannot expose the platform's full set of virtualization features.

VirtIO uses a paravirtualized device model designed for virtual environments, providing efficient paths for virtual disks, network adapters, balloon memory, and guest communication. Correct drivers shorten the data path and underpin both QGA communication and dynamic memory adjustment — performance and management capability arriving together.

Risk note: These drivers sit on the boot disk and the network path. Validate version compatibility and a rollback procedure before upgrading them.

09. Personalize VMs created from a template

A standard template has to produce many VMs, each with its own hostname, network configuration, and system identity. If an administrator still logs in to change those by hand, the template has copied a disk without delivering an automated service.

When creating VMs from a template, a Customization Spec passes structured system configuration into the guest, and Cloudbase-Init — cloud-init on Linux — applies it at first boot. QGA then reports the runtime IP and guest state back to the platform, closing the loop from template to configured instance.

Implementation note: What you can actually configure depends on the fields the current Customization Spec exposes and on the guest version. Check both.

10. Close the last mile of VM delivery

You create a VM in ZSvirt, the operating system is ready — and then someone still has to install software, write application configuration, and register the instance with existing management systems. If that means logging in and running scripts, your automation stopped at VM creation.

User Data lets a new VM receive declarative configuration or a startup script and execute it during first boot. One base image stays generic while each instance gets its own deployment logic. Typical uses:

Install and start a web server, runtime, database client, or container component
Write package repository, NTP, DNS, application parameter, and environment variable settings
Create users and directories, inject SSH public keys, mount data disks, or expand file systems
Download an application, start its services, and register the instance with configuration or asset management systems

Implementation note: Scripts should be idempotent, and should handle network dependencies, retries, and the protection of sensitive data.

Operations Checklist

For every ZSvirt VM, verify at least these four things:

Check the VMTools packages you installed against the component boundaries above — some capabilities come from VMTools, others from the OS.
Confirm advanced monitoring, guest information, time synchronization, and agent health alerts are all working.
Test shutdown, guest customization, configuration delivery, and network-loss recovery in a non-production environment.
Validate backups by proving applications and data can actually be restored — not merely that the job reported success.

What You Are Actually Installing

ZSvirt VMTools installs more than a monitoring agent, a communication channel, and a set of drivers. It installs the complete management capability that every virtual machine needs — the difference between a VM that runs and a VM you can operate.

Open Source, Month One: 106 Countries & Regions Downloaded

ZSvirt — Fri, 18 Sep 2026 06:02:45 +0000

Data as of 2026-09-11
Coverage window: 2026-08-12 – 2026-09-11 (first month of open source)

One month ago, we open-sourced ZSvirt.

Over the past month we kept building, kept learning, and kept connecting with people around the world. The first month brought new users, new ideas, new content, and plenty of moments worth sharing.

This is the first issue of ZSvirt Open Source Monthly. Let's look back at ZSvirt's first month — what happened around the world, and where we go from here.

01 — Product & Releases

ZSvirt Goes Open Source Worldwide

On 2026-08-14 we open-sourced ZSvirt's core IaaS engine under GPL-3.0. A month later, that code has reached 106 countries and regions (unique downloads, counted by ISO 3166) — further than we expected for an engine that has been public for a single month.

Open-sourcing also meant more than publishing code. In the same month we kept lowering the barrier to running ZSvirt: new OVA and QCOW2 images, an open-source MCP Server, and fuller documentation, so it can be brought up on VMware, VirtualBox, KVM, or any cloud host.

OVA & QCOW2 Packages

We added OVA and QCOW2 images for more flexible installation across different environments, further lowering the barrier to deploying ZSvirt. Importing an OVA or QCOW2 image into an existing vSphere or KVM environment brings up a complete ZSvirt environment in about five minutes.

The download center now offers four package types — ISO (5.41 GB), OVA (17.02 GB), QCOW2 (24.02 GB), and ZMigrate — each with a SHA256 checksum.

MCP Server Open-Sourced

We open-sourced the companion ZSvirt MCP Server, letting AI assistants dynamically discover and call ZSvirt's 2,000+ OpenAPI endpoints. Only read-only APIs are exposed by default, supporting AI-driven interaction with and monitoring of virtualized environments. Install it from PyPI: pip install zsvirt-mcp-server.

Project Data

GitHub: ZSvirt/zsvirt — 1,664 stars / 303 forks (as of 2026-09-11)
Trendshift: reached #1 Java Repository of the Day (2026-08-16, #21 across all languages) and #2 Java Repository of the Week for week 34
Media coverage: Open Source For You, GlobeNewswire, and others
Download reach: 106 countries and regions, counted by ISO 3166

02 — Official Content

Over the past month we published a run of practical content covering installation, deployment, migration, and real-world use cases.

Best Practices

★ Evaluating ZSvirt as a VMware Alternative: A PoC Guide from Deployment to Migration (2026-08-27) — a complete evaluation guide: how to deploy ZSvirt, verify key capabilities, and plan a migration path away from VMware.
★ ZSvirt Migration in Practice: Three Ways to Migrate VMs from VMware (2026-08-19) — ZMigrate live migration (about five minutes per VM switch, up to 50 concurrent), OVF import, and VMDK upload — three approaches for different migration scenarios.
★ ZSvirt Architecture Explained: How a Production-Proven Virtualization Engine Is Built (2026-08-17) — a breakdown of ZSvirt's architecture: one control plane supporting 10,000+ hosts, 768 vCPUs per VM, and the engineering trade-offs behind it.
ZSvirt Quick Start: From ISO to Your First VM, Step by Step — deploy in 30–40 minutes with All-in-One mode and create your first VM.

★ marks this month's editor's picks.

Official Videos

As of 2026-09-11, the official ZSvirt YouTube channel has published 10 videos:

Type	Count	Content
Launch video	1	ZSvirt goes open source
Hands-on tutorials	2	Installing from scratch, migrating from VMware
VirtWatch Weekly	1	Episode 1
ZSvirt Episode feature tutorials	6	Datacenter/cluster/hosts, data storage, distributed switches and port groups, VMTools, and more

03 — Community & Creators

ZSvirt Community Discord

The ZSvirt Community Discord is now open — a place for users and community members to talk, ask questions, share experience, and help each other out.

Join ZSvirt Community →

You can also find us on GitHub Discussions, LinkedIn (ZSvirt Community), and X (@ZSvirt) — or email us at community@zsvirt.io.

ZSvirt Storytellers — Phase 1: YouTube Challenge

We launched ZSvirt Storytellers, inviting creators and community members to share their stories, hands-on experience, and perspectives on ZSvirt.

The challenge is still running. As of 2026-09-11, 3 participants have submitted videos and 5 more are in progress:



	#01 vikas9452-git (India) — the first participant from India, publishing ZSvirt vs VMware vs Proxmox on the Labs Hands On channel (72.2k subscribers), with 10k views.
	#02 Profe Carlos Leal (Nicaragua) — the first participant from Nicaragua, publishing the Spanish-language ZSvirt: ¿Rival de Proxmox VE y sucesor de VMware?, with 19k views.
	#03 sriramya11 (India) — published What is ZSvirt? VMware Alternative? on 2026-09-07.

ZSvirt Storytellers Phase 1: YouTube Challenge (GitHub Discussion #8)

Third-Party Creators



	★ Byron Xie — a ZSvirt comparison series (including ZSvirt vs Proxmox and three more videos), with hands-on benchmarks.

	★ SoftsWeb — ZSvirt: The Best VMware Alternative You Need to Try, 43k views — among the most-watched third-party ZSvirt videos to date.
	★ Libre-Data — I Tested This New Platform for Virtual Machines, a test on real hardware with 10k views.
	AskGuru — a 44-minute uncut installation walkthrough from a blank machine to a working platform, nothing trimmed and nothing skipped.
	hairong lu — a full feature walkthrough of ZSvirt, stepping through the platform feature by feature.

★ marks this month's editor's picks.

Community Discussion

Hacker News — Show HN: ZSvirt – A lightweight, scalable open source virtualization platform picked up 72 points and 14 comments, sparking discussion about open-source virtualization and vendor lock-in.
GitHub Discussions — installation and usage Q&A stayed busy: an installation thread (11 replies), a ZMigrate deployment discussion (9 replies), an aarch64 image question, a QCOW2 installation issue, and more. Thanks to everyone who asked and answered.

04 — Contributors

The progress of our first month came from everyone who submitted code, reported issues, translated docs, disclosed security findings, and took part in Q&A.

Thanks to Our Community

Thanks to the community members who contributed code, reported issues, and joined the discussion this month (in no particular order):

tllovesxs, chayu163, Jorge Perez, libre-data, shuchaoma, fankejing-just, techknight2020, dawnorigin

Security Disclosure

Thanks to the following two community members, who reported security-related findings to security@zsvirt.io. We're glad to credit them publicly:

Svector Anu
Jorge Perez

If you find a potential security issue in ZSvirt, we'd welcome a note at security@zsvirt.io as well.

05 — What's Next

The first month is only the beginning. From here we'll keep pushing on two fronts: product and community.

Product

Next up is continued work on hardware compatibility and product capabilities: aarch64 support is under evaluation and GPU components are on the roadmap. We'll also establish a formal release process (GitHub Release / Tag) so that version evolution is clearer and traceable.

For the rest of 2026 H2, the roadmap centers on five areas:

Security — add disk encryption and live-migration encryption for virtual machines.
DRS & VM migration — more flexible migration options: data-disk-only migration; hot and cold migration for SAN scenarios, and cold migration for NFS.
ZMigrate — ZMigrate 2.1 adds pre-checks that mitigate risk in complex migrations, alongside simpler and smarter migration workflows.
Operations — more monitoring metrics (VM CPU ready time, VM disk read/write latency, network packet drop rate, host CPU ready time); finer-grained log levels for external syslog forwarding; NVMe and FC device monitoring including IOPS and latency; and built-in QXL drivers in VMTools for better VM console display and resolution.
Inventory management — extend storage and VM registration to cover same-site registration.

Community

VirtWatch Weekly — our virtualization and open-source infrastructure weekly will keep publishing (Episode 1 is on YouTube).
Storytellers Phase 1 and later phases — Phase 1 closes on 2026-09-28, and further phases are in planning. More creators are welcome to join.

06 — Get Involved


Source	github.com/ZSvirt/zsvirt
Download	zsvirt.io/download
Docs	docs.zsvirt.io/en/docs
Community	Discord · GitHub Discussions · LinkedIn · X @ZSvirt
Contact	community@zsvirt.io

Thank you for every download, every install, every video, and every piece of feedback.

One month. One world. More to come.

— ZSvirt Team

Virtualization Watch Issue 002: VMware Explore 2026, Proxmox 24/7 Support

ZSvirt — Tue, 15 Sep 2026 09:14:47 +0000

September 14, 2026 · Biweekly · Coverage window: 9/1–9/13

From the Editor

Hello, readers — welcome to Issue 002 of Virtualization Watch.

The past two weeks were the densest fourteen days of the quarter for virtualization: VMware Explore 2026 opened in Las Vegas on August 31 and wrapped on September 3, with Broadcom pushing "Private AI Cloud" to the very front of the private-cloud narrative; in the same week, Proxmox announced 24/7 enterprise support and a North American subsidiary back to back, then earned Omnissa Horizon certification — the open-source camp's commercialization is visibly accelerating. The security side was heavier: a CVSS 9.3 VM-escape vulnerability hit Workstation/Fusion, and Microsoft's September Patch Tuesday set an all-time record with 974 fixes, five of them in Hyper-V alone.

As AI workloads become the centerpiece of every roadmap, hypervisor competition is shifting from "running VMs" to "running models well on GPUs." Let's begin.

In This Issue: VMware Explore 2026 — AI Factory Debuts, vSphere 9.1 Earns NVIDIA Certification

VMware Explore 2026 ran August 31 – September 3 at The Venetian Convention and Expo Center in Las Vegas (VMware event page). Our news window covers every official announcement from the show; the two weightiest are VMware AI Factory and NVIDIA certification for vSphere 9.1 (VMware official blog, September 3, 2026).

Key points:

VMware AI Factory: positioned as the software-defined foundation of the "VMware Private AI Cloud," aiming to compress the time from bare-metal servers to a first production AI model "from weeks to hours," spanning hardware provisioning, software-stack enablement, and full lifecycle management.
Ecosystem and hardware: works with Dell PowerEdge certified servers and VCF AI ReadyNodes from Cisco, Lenovo, Supermicro, and others; a partnership with AMD delivers zero-touch provisioning of Instinct GPUs with the open ROCm stack; a separate partnership with MetalSoft integrates heterogeneous bare-metal automation directly into the VCF management console.
Model runtime: vLLM is the default model runtime, with 150+ open models; models officially named as tested on VCF include NVIDIA Nemotron 3, Google Gemma 4, NEC cotomi, Alibaba Qwen3.8-27B, and Zhipu GLM 5.2.
NVIDIA certification: NVIDIA recently launched the NVIDIA-Certified Hypervisors program, and vSphere 9.1 (and all subsequent vSphere 9 releases) are among the first certified, with official claims of "near bare-metal" performance for AI/HPC workloads on VCF.
Private AI services ecosystem additions: Appian, ClearML, Eve Security, Solo.io, and TrueFoundry.

Editor's take: this year's Explore barely discussed "virtualization" itself — every announcement targeted the private cloud in the Agentic AI era. Broadcom's logic is straightforward: GPUs are expensive, token costs are spiraling, and data must stay on-premises — all three are the private cloud's home turf. For enterprise users, what truly needs evaluation is not the AI Factory concept, but whether the GPU supply chain works smoothly after upgrading an existing VCF environment to 9.1.

Product & Version News

VMware Cloud Foundation 9.1.1 Reaches GA (September 3)

Timed with Explore 2026, Broadcom announced the general availability of VCF 9.1.1 (official blog) — the first maintenance release of VCF 9.1 (released in May). Highlights:

Multi-tenant model sharing: AI models can be securely shared across tenants/business units, while training data and access controls remain tenant-isolated, cutting duplicate deployment costs;
AI Assistant for VCF: AI-assisted diagnostics (e.g., ESX CPU/memory contention, locating batch vMotion errors) and management-pack building;
vSAN Object Storage (tech preview) and cumulative security fixes.

Note the upgrade-order constraints: William Lam's blog post (analysis published September 10) reminds readers that Fleet LCM must be upgraded to 9.1.1 before all other components, VCFMS must go before Identity Broker and Salt Master/RaaS, and VCF Automation before VCD Migrator (the corresponding pre-checks are built into the release).

VMware Workstation / Fusion 26H1u1 (September 3)

The desktop hypervisor line shipped 26H1u1, whose core purpose is fixing the two vulnerabilities in VMSA-2026-0007 (see "Security Advisories"), while also introducing automated Secure Boot platform key (PK) remediation to address the Microsoft Secure Boot certificate expiration (Fusion 26H1u1 release notes, Broadcom TechDocs).

Proxmox: Two Announcements in One Week — 24/7 Support + North America Subsidiary (September 2), Omnissa Certification (September 4)

On September 2, Proxmox Server Solutions announced (official press release):

Enterprise support expands to 24/7, effective October 19, 2026, covering the PVE, PBS, and PDM product lines; the Premium tier includes 24/7 from day one (unlimited tickets, 2-hour response for critical issues), the Standard tier opens in Q4 2026, and the Basic tier's SLA is unchanged though the global team's cross-timezone shifts will shorten real-world response times;
A new subsidiary, Proxmox North America Inc., headquartered in Kingston, Ontario, Canada, led by CEO Bill Hughes, handling sales, contracts, and business-hours technical support across North American time zones;
Operating figures disclosed alongside: over 2.3 million active PVE servers worldwide, 60,000+ enterprise customers with paid support, and roughly 3,000 integration partners.

On September 4, Proxmox announced (official press release) that Proxmox VE has officially passed Omnissa Horizon Ready Hypervisor certification: interoperating with Omnissa Horizon in Manual Provisioning Mode, enterprises can centrally deliver virtual desktops and applications on existing PVE infrastructure; PVE also appears on the NVIDIA vGPU support list as a certified third-party hypervisor. Verified configurations are in the Omnissa interoperability matrix.

Editor's take: from official Arm64 support on August 5, to this issue's 24/7 support and VDI ecosystem certification, Proxmox's "catch the spillover" playbook under Broadcom's licensing squeeze is becoming systematic — first it caught the migrations, then the services, and now even the VDI desktop cloud.

Nutanix Lands in Two Gartner Magic Quadrants in a Fortnight (September 8 / September 10)

Per the Nutanix newsroom (official Newsroom): on September 10, Nutanix was named a Leader in the 2026 Gartner Magic Quadrant for Distributed Hybrid Infrastructure (on both Ability to Execute and Completeness of Vision); on September 8, it appeared for the second consecutive year in the Gartner Magic Quadrant for Container Management (the official blog headline positions it as a "Challenger").

KubeVirt v1.10.0-alpha.0 Released (September 4)

The KubeVirt community published v1.10.0-alpha.0 on GitHub (release page): about five weeks after v1.9.0 (July 30), this cycle accumulated 824 changes from 72 contributors. Notable changes: the KubevirtSeccompProfile feature gate graduates to GA and is installed by default; ExternalNetResourceInjection graduates to GA, and virt-controller no longer queries NetworkAttachmentDefinition directly; SR-IOV interfaces can no longer be mixed with DRA networking.

Release Footnotes from Outside the Window

No new VirtualBox release this issue; the latest remains 7.2.16 from August 18 (VirtualBox official News);
QEMU 11.1 shipped on August 11 (UFS 4.1 emulation, RISC-V big-endian support) — before this window, for reference.

Community Buzz

ZSvirt on Show HN: Lightweight Open-Source Virtualization Platform Draws 72 Points (September 2)

Editor's disclosure: this newsletter is produced by the ZSvirt team; this item is related-party content and is disclosed as such. All figures below come from live captures of public pages.

On September 2, the open-source virtualization platform ZSvirt appeared on Hacker News' Show HN: "Show HN: ZSvirt – A lightweight, scalable open source virtualization platform" (original HN post). As of our September 13 capture, it had 72 points and 14 comments.

The comment section's questions were strikingly focused, outlining the four things the community cares most about in an emerging virtualization platform:

Performance benchmarks: multiple users asked for benchmarks against Proxmox, standalone KVM, and OpenStack — VM boot time, migration speed, and control-plane overhead;
VMware migration: the VMDK/OVF compatibility experience, and the networking/storage pitfalls when migrating from vSphere, were asked repeatedly;
Networking capabilities: how hard VLAN and NAT configuration is compared with Proxmox;
Lab barrier to entry: the minimum memory for running the OVA image under nested virtualization on a single node, plus the maturity of multi-tenant management and the API ecosystem.

On the repository side (GitHub: ZSvirt/zsvirt): positioned as a "core IaaS engine and cloud infrastructure foundation," built on KVM, written mainly in Java (78.2%), GPL-3.0 licensed, with 1.7k stars and 306 forks as of our September 13 capture. Ready-made qcow2 and OVA images can be tried via nested virtualization on VMware, VirtualBox, KVM, or cloud hosts, and there is an online demo (demo.zsvirt.io). The repository has no formal release yet — worth tracking.

vphone-cli Heats Up Again: iOS 27 RC in the Catalog, HN Post at 421 Points

The open-source project vphone-cli (which boots a "virtual iPhone" on Apple Silicon Macs using Apple's Virtualization.framework and the PCC research-VM infrastructure) saw a second wave of attention in this window:

The Hacker News front-page thread from late August, "Boot a Virtual iPhone via Apple's Virtualization.framework," now sits at 421 points and 113 comments (original HN post), with comments still growing inside our window; the community consensus is that "this isn't Corellium-style emulation — it's real virtualization," alongside a warning not to select Japan or the EU region during initialization (the VM cannot pass third-party app-store compliance checks);
On September 10, a repository commit added the iOS 26.6.2 + iOS 27.0 RC (cloudOS 26.4) pairing, with v1.0.14 released the same day; InfoQ covered the project's full iOS 27 virtualization support on September 12, driving a fresh round of discussion;
As of our September 13 capture, the repository had 11.8k stars and 1.5k forks, primarily Swift (58.6%).

The community's main concerns are worth recording too: Apple does not officially support this usage, and future PCC images may remove necessary components; the host also requires loosening SIP/AMFI security policies — use a dedicated research machine.

Proxmox VE 8 Officially EOL; the Upgrade Wave Continues

Security support for Proxmox VE 8 ended on August 31 (endoflife.date) — one day before this window — and community discussion of the 8-to-9 upgrade kept simmering throughout: the kernel jumps from 6.8 to 7.x, NICs may be renamed, LVM auto-activation defaults change, and PCI passthrough needs re-checking. Readers still on VE 8 can consult VirtualizationHowto's upgrade checklist — run pve8to9 --full first, pin NIC names, and have out-of-band console access ready.

VMSA-2026-0007 Becomes the Fortnight's Must-Do for Desktop Virtualization Users

In the VirtualizationHowto community, the VMSA-2026-0007 discussion thread is among the hottest: VMXNET3 is the default virtual NIC for most users, and "first inventory which dev and test machines have Workstation/Fusion installed" became the thread's consensus — desktop hypervisors are rarely in the enterprise asset inventory, which is exactly what makes this vulnerability tricky in practice.

Security Advisories

[Critical] VMSA-2026-0007: Workstation / Fusion VM Escape (September 3)

Broadcom published VMSA-2026-0007 (VMware Security Blog | Broadcom official advisory), affecting VMware Workstation 25H2/26H1 and Fusion 25H2/26H1 (macOS); ESXi and vCenter are not affected:

CVE	Component	Type	CVSS v3	Impact
CVE-2026-59346	VMXNET3 virtual NIC	Integer overflow	9.3 (Critical)	A local administrator inside the VM can execute code on the host (VM escape)
CVE-2026-59347	HGFS shared folders	Stack buffer overflow	8.1 (Important)	A local administrator inside the VM can execute code with the identity of the host VMX process

Fixed in: 26H1u1 (same version number for Workstation and Fusion); no workarounds — upgrading is the only option;
Both vulnerabilities were reported privately, and Broadcom is not aware of in-the-wild exploitation; reporters include h4urek of secsys lab, Y² and Stan S via Trend Micro ZDI, and Yeonghyeon Choi and Tianchu Chen of Tencent Xuanwu Lab;
CERT-FR issued a corresponding advisory on September 4;
A side note: 26H1u1 also introduces automated Secure Boot platform-key remediation — before upgrading, make sure guests have the July 2026-or-later Windows cumulative update installed (in combination with VMware Tools 13.1.5).

Recommended action: users who frequently run third-party images, analyze samples, or execute untrusted workloads on their machines should upgrade first. If you cannot upgrade immediately, disabling HGFS shared folders and tightening in-VM administrator privileges will shrink the attack surface (unofficial mitigation — reduces risk only).

[Largest Ever] Microsoft September Patch Tuesday: 974 Vulnerabilities, Five in Hyper-V (September 8)

Microsoft's September 2026 Patch Tuesday fixed 974 vulnerabilities (113 Critical, 860 Important), which Qualys calls "Microsoft's largest security update ever" (Qualys analysis, September 9); two additional vulnerabilities are already being exploited in the wild.

Directly virtualization-relevant: five Hyper-V vulnerabilities (Lansweeper roundup):

CVE-2026-80083: Hyper-V remote code execution (untrusted pointer dereference), Critical;
CVE-2026-69603: Hyper-V remote code execution (heap buffer overflow), Critical;
CVE-2026-69910: Hyper-V remote code execution, Critical;
CVE-2026-72961: Hyper-V elevation of privilege (out-of-bounds read);
CVE-2026-69553: Hyper-V elevation of privilege.

Splashtop's patch-priority analysis (September 9) places Hyper-V, Failover Clustering, and Windows Deployment Services in the "patch within 72 hours" tier — once a host is compromised, every guest workload on it is exposed. A VHD Miniport driver denial-of-service flaw (CVE-2026-69384) was fixed alongside; include it in your host patching window.

Tools & Good Reads

vphone-cli (GitHub, MIT license): a single command runs the whole pipeline — download firmware → patch → DFU restore → install the customized firmware → first boot — with SSH/VNC access and five security-bypass variants (from patchless to full jailbreak); the companion vphone-mcp wraps the control socket as an MCP service, letting AI agents take screenshots, drive touch input, and automate UI testing. Once again: SIP/AMFI must be loosened — dedicated research machines only.
"10 Exciting Enhancements in VMware Cloud Foundation 9.1.1" (William Lam, September 10): ten detailed enhancements in VCF 9.1.1 plus upgrade-order caveats, written on-site at Explore by a Broadcom frontline engineer.
"Still Running Proxmox VE 8?" (VirtualizationHowto, August 19): the pre-EOL upgrade checklist and version support matrix — read together with this issue's "Community Buzz."
"Microsoft and Adobe Patch Tuesday, September 2026 Security Update Review" (Qualys, September 9): a panoramic breakdown of the 974 vulnerabilities with tiered patching advice.
Broadcom TechDocs: Workstation / Fusion 26H1u1 release notes (link): official details on the CVE fixes and Secure Boot PK remediation.

Number of the Week: 974

The total number of vulnerabilities fixed in Microsoft's September 2026 Patch Tuesday — 113 Critical, 860 Important, plus two zero-days exploited in the wild. Qualys confirms it is Microsoft's largest single-month security update ever (July had 570, August 400). Six are virtualization-related: five in Hyper-V (three Critical RCEs + two elevation-of-privilege) and one in the VHD Miniport driver.

Next Issue Preview

October 19: Proxmox 24/7 enterprise support goes live — we'll watch the Standard tier's rollout pace and how the SLA lands in practice;
KubeVirt v1.10 stable: alpha.0 froze 824 changes; the stable release is expected to follow the Kubernetes 1.37 cadence — we will keep tracking;
October Patch Tuesday (October 13): will the 974 record be broken? Hyper-V and the VHD components deserve continued attention;
Once VMware AI Factory's follow-up technical documentation and MetalSoft integration details are released, we will publish a hands-on analysis.

About this publication: Virtualization Watch (VirtWatch Weekly) is a biweekly virtualization industry publication produced by the ZSvirt community, covering product news, security advisories, and community discussion across VMware/Broadcom, Proxmox, KVM/QEMU, Hyper-V, KubeVirt, Nutanix, and more. It is compiled with AI-cluster assistance; every fact is linked to its source; we aim for balanced viewpoints and welcome corrections. All factual content in this issue was verified against primary sources (official press releases, official blogs, GitHub release pages, original HN posts, etc.), with key source pages captured by the editors. News window: September 1–13, 2026; editorial deadline: September 13, 2026. Visit zsvirt.io for past issues and the video edition.

Deploy ZSvirt Without Physical Hardware: qcow2 and OVA Images Are Here

ZSvirt — Tue, 15 Sep 2026 09:05:41 +0000

Over the past few weeks, we've covered everything from the open-source announcement to evaluating, deploying, and migrating. Today, we want to share a change that makes evaluating ZSvirt faster: the download center now offers qcow2 and OVA images.

Trying ZSvirt used to mean either provisioning a physical server or mounting the ISO inside a VM and walking through a full installation. For teams that just want to see whether it works, that's a real barrier to entry.

Not anymore. Download a qcow2 or OVA file, create a VM on your VMware, VirtualBox, KVM, or cloud host, boot it, set an IP — and the ZSvirt management node is ready. No physical hardware required.

Head to the download center to see the newly added packages:

Why qcow2 and OVA

The ISO targets a from-scratch install: an installer guides you through selecting the system disk, configuring the network, and setting the root password. qcow2 and OVA are prepackaged VM images — the OS and management-node services are already baked in, so they boot straight into a working state and skip the entire installer interaction.

The two formats complement each other for different runtime environments:

Image format	What it is	Typical environment
qcow2	Standard KVM/QEMU disk format; compact and grows on demand	KVM, cloud hosts
OVA	A packaged VM template; import it and get a complete VM	VMware Workstation / ESXi, VirtualBox

The ISO installer still fits production rollouts and brand-new hardware. qcow2/OVA are the lighter path for evaluation, PoC, and lab environments.

Before You Start: What You'll Need

The bar is low — a single VM can act as the management node. Create it with these settings:

Item	Recommendation
CPU	16 vCPUs (the OVA image's default)
Memory	16 GiB (the OVA image's default)
System disk	The downloaded qcow2 or OVA image
NIC	At least one virtual NIC on the management network
IP	An available management-node IP, netmask, and gateway

One easy pitfall to avoid: running virtualization inside a VM requires nested virtualization support from the hypervisor. On VMware, when creating or importing the VM, check Expose hardware assisted virtualization to the guest OS in the processor settings. VirtualBox, KVM, and cloud hosts each have their own toggle, covered in the scenarios below.

Scenario 1: VMware with OVA

OVA is the most natural format for the VMware ecosystem.

Download the .ova file from the download center;
In VMware Workstation, choose File → Open and select the downloaded OVA to import it;
Edit the VM settings and confirm CPU and memory meet the requirements (the OVA ships with 16 vCPUs / 16 GiB by default; keep or adjust as needed);
Under Processors, check Virtualize Intel VT-x/EPT or AMD-V/RVI (the equivalent ESXi option is Expose hardware assisted virtualization to the guest OS);
Power on, open the console, and proceed to initialization below.

Scenario 2: KVM/QEMU with qcow2

qcow2 is the native KVM/QEMU format — attach it directly as a disk.

When creating a VM in virt-manager, choose Import existing disk image, point to the downloaded qcow2 file, allocate 8 vCPUs / 8 GiB, and boot. The same works from the command line with virt-install:

virt-install \
  --name zsvirt-mn \
  --vcpus 8 \
  --memory 8192 \
  --disk path=/var/lib/libvirt/images/ZSvirt-x86_64-<version>-h84r.qcow2,format=qcow2,device=disk \
  --network network=default \
  --import

If virtualization doesn't work inside the guest, first confirm nested virtualization is enabled on the host:

cat /sys/module/kvm_intel/parameters/nested   # Intel
cat /sys/module/kvm_amd/parameters/nested     # AMD

An output of 1 or Y means it's enabled; otherwise, add nested=1 to the KVM kernel module and reload it.

Scenario 3: VirtualBox and Cloud Hosts

VirtualBox: the easiest path is OVA — File → Import Appliance, then select the downloaded OVA. After importing, enable Nested VT-x/AMD-V under System → Processor.

Cloud hosts: pick an instance type that supports nested virtualization (offerings vary by provider — typically bare-metal or specific performance instance families). Create a cloud host from the qcow2 as its system disk, or upload it to the image service first and create an instance from it.

First Boot and Initialization

Whatever the environment, initialization after first boot is the same.

Step 1: Log in and change the password. Press Ctrl+Alt+F2 in the console to switch to the login terminal and sign in as root. The default password is zsvirt.123 — run passwd right after logging in and change it. That's a habit worth keeping in any environment.

Step 2: Configure the network and start the services. Two cases:

When the management network has DHCP, first check the address the NIC picked up:

ip addr

Write the address into the management-node config and start the services:

zstack-ctl change_ip --ip <management-node-ip>
zstack-ctl start

Without DHCP, create a bond and assign a static address manually:

# Create bond0
zs-bond-ab -c bond0

# Add the management NIC to bond0
zs-nic-to-bond -a bond0

# Assign a static address to bond0 (IP, netmask, gateway, in that order)
zs-network-setting -i bond0 <management-node-ip> <netmask> <gateway>

Once networking is ready, run zstack-ctl change_ip --ip <management-node-ip> and zstack-ctl start to finish initialization.

Step 3: Open the web UI. Point your browser at https://<management-node-ip> and follow the wizard to initialize the platform, then add hosts, storage, and networks and create your first VM. For the full flow, follow the quick-start tutorial.

Going Further: The Same Image Can Act as a Compute Node

If you only need this node as a compute node joining an existing cluster, you can skip the zstack-ctl change_ip and zstack-ctl start steps — the image supports that use case too. A management node, by contrast, runs the full control-plane services.

Troubleshooting Cheat Sheet

Symptom	Check first
UI won't load	Is the VM running? Is the management NIC attached to the right network?
Wrong IP / netmask / gateway	Was `zstack-ctl change_ip --ip <management-node-ip>` run with the correct value?
Services not started	Was `zstack-ctl start` run, and did you wait for startup to finish?
No external access	Can a workstation or another host reach the management-node IP? Is port 443 open in the firewall?
Virtualization unavailable	Is nested virtualization enabled on the hypervisor? (see scenarios above)

More detailed troubleshooting is in the docs: Nested Virtualization Management Node.

What's Next

Download the qcow2 / OVA images
Follow the quick-start tutorial to create your first VM
Migrating from VMware? Read ZSvirt Migration in Practice: Three Ways to Migrate VMs
For a systematic evaluation, work through the PoC guide

We've always believed a good evaluation should start at the lowest possible cost. Now, a single VM is enough.

Join the Community

Issue tracker: 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
- Discord: https://discord.com/invite/KHsw63z9xA
- Email: community@zsvirt.io

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

DEV Community: ZSvirt

Virtualization Watch Issue 003: Citrix NetScaler Zero-Days Hit Over a Weekend; Sidero Builds a Hypervisor into Talos Linux

From the Editor

In This Issue

Citrix NetScaler: Two Zero-Days Land Over a Weekend, with a 3-Day KEV Deadline

Sidero Ships Talos Hypervisor: a Hypervisor Built into the Kubernetes Operating System

ZSvirt Community News: First Open-Source Monthly Report and Roadmap

Second-Half 2026 Roadmap (First Public Release)

Product & Version News

Incus 7.5 / 7.5.1: Eleven Security Fixes, OVN Child Networks, GPU P2P (September 25)

VirtualBox 7.2.18 → 7.2.20: Two Maintenance Updates in a Week (September 15, September 22)

Kata Containers 4.2.0: 80-Plus Changes (September 15)

Harvester v1.9.0: a Whole-Stack Upgrade (September 16)

Cloud Vendors: AWS T8i and Google X5 Both Reach GA

Gartner Publishes Its First Server Virtualization Platforms Magic Quadrant (9/14)

Teasers and Snapshots

Community Buzz

HN: virtio-nvgpu Reaches 98–100 Percent of Native GPU Performance Inside a KVM Guest (154 points / 65 comments)

Other High-Scoring HN Posts This Fortnight

Security Advisories

[Critical] Arista VeloCloud Orchestrator Zero-Day: CVSS 10.0, Already Exploited (September 22)

QEMU 9pfs Guest Escape: CVE-2026-93834 (Disclosed September 22)

Cloudflare Containers: Cross-Tenant Data Residue (Disclosed September 24)

vCenter CVE-2026-59310 Follow-Up: CISA Confirms Ransomware Gangs Are Using It (September 15)

Other Security News

Tools & Good Reads

Number of the Week: 3 (days)

Next Issue Preview

10 Reasons You Must Install ZSvirt VMTools

10 Reasons You Must Install ZSvirt VMTools

What VMTools Actually Consists Of

Ten Reasons VMTools Is Not Optional

01. See what is actually happening inside the VM

02. Quiesce the file system for consistent snapshots and backups

03. Shut down and restart guests cleanly

04. Get accurate IP, NIC, and guest information

05. Do day-two operations without logging in

06. Keep a rescue path when the network fails

07. Keep guest and host time in sync

08. Unlock the performance of virtual devices

09. Personalize VMs created from a template

10. Close the last mile of VM delivery

Operations Checklist

What You Are Actually Installing

Open Source, Month One: 106 Countries & Regions Downloaded

01 — Product & Releases

ZSvirt Goes Open Source Worldwide

OVA & QCOW2 Packages

MCP Server Open-Sourced

Project Data

02 — Official Content

Best Practices

Official Videos

03 — Community & Creators

ZSvirt Community Discord

ZSvirt Storytellers — Phase 1: YouTube Challenge

Third-Party Creators

Community Discussion

04 — Contributors

Thanks to Our Community

Security Disclosure

05 — What's Next

Product

Community

06 — Get Involved

Virtualization Watch Issue 002: VMware Explore 2026, Proxmox 24/7 Support

From the Editor

In This Issue: VMware Explore 2026 — AI Factory Debuts, vSphere 9.1 Earns NVIDIA Certification

Product & Version News

VMware Cloud Foundation 9.1.1 Reaches GA (September 3)

VMware Workstation / Fusion 26H1u1 (September 3)

Proxmox: Two Announcements in One Week — 24/7 Support + North America Subsidiary (September 2), Omnissa Certification (September 4)

Nutanix Lands in Two Gartner Magic Quadrants in a Fortnight (September 8 / September 10)

KubeVirt v1.10.0-alpha.0 Released (September 4)

Release Footnotes from Outside the Window

Community Buzz

ZSvirt on Show HN: Lightweight Open-Source Virtualization Platform Draws 72 Points (September 2)

vphone-cli Heats Up Again: iOS 27 RC in the Catalog, HN Post at 421 Points

Proxmox VE 8 Officially EOL; the Upgrade Wave Continues

VMSA-2026-0007 Becomes the Fortnight's Must-Do for Desktop Virtualization Users