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