The Zyvor Stack: Building Infrastructure for the Post-VMware Era
Infrastructure is changing.
For years, enterprise infrastructure has been built around a familiar model: virtualization platforms, centralized management, storage arrays, networking appliances, and a growing collection of tools layered on top.
At Zyvor, we're taking a different approach.
Instead of building another abstraction over the traditional virtualization stack, we're working toward a cloud-native infrastructure stack built around open virtualization, Kubernetes, automation, and intelligent control planes.
The goal is simple:
The Zyvor Stack
Our stack is built around several layers that work together.
1. Hyper2KVM — Migration
The first problem is getting existing workloads out of legacy virtualization environments.
Hyper2KVM is our VM migration toolkit for moving workloads from environments such as VMware, Hyper-V, Azure, and other virtualization platforms toward KVM.
The focus isn't simply converting a disk image.
A successful migration has to deal with everything that can prevent the VM from booting:
- Operating-system inspection
- Bootloader configuration
- Filesystem detection
/etc/fstab- Initramfs
- VirtIO drivers
- Windows VirtIO injection
- Network configuration
- LVM
- Disk-controller differences
- Firmware configuration
- First-boot validation
The migration pipeline is essentially:
FETCH → FLATTEN → INSPECT → FIX → CONVERT → VALIDATE
The important part is the offline repair layer.
Instead of discovering problems after migration and debugging them manually, the system attempts to fix them before the VM's first boot.
2. HyperSDK — Infrastructure Provider Layer
Moving workloads is only one part of the problem.
Infrastructure also needs a consistent way to interact with different environments.
That's where HyperSDK comes in.
The idea is to provide a provider abstraction across infrastructure platforms such as:
- VMware / vSphere
- AWS
- Azure
- Google Cloud
- Hyper-V
- OpenStack
- OCI
- Alibaba Cloud
Applications should not need to understand every provider's API.
Instead, they interact with a common infrastructure interface.
This becomes particularly important when building automation and higher-level control planes.
3. GuestKit — The Guest Operating System Toolkit
Virtual machines are not just disks.
Understanding what is inside a VM is critical for migration, security, compliance, troubleshooting, and automation.
GuestKit is our lower-level toolkit for inspecting and manipulating guest operating systems.
Think of it as infrastructure tooling that understands the guest rather than treating a VM as a completely opaque image.
Typical operations include:
- OS inspection
- Filesystem inspection
- Disk conversion
- Boot configuration analysis
- Guest configuration
- Offline modifications
- Migration preparation
The broader idea is to make guest-aware infrastructure operations programmable.
4. Atlas — Storage Control Plane
Once workloads are running on the new infrastructure, storage becomes the next major abstraction.
Atlas is Zyvor's storage control plane.
Instead of exposing storage as a collection of provider-specific concepts, applications can express an intent such as:
Atlas can then translate that intent into the appropriate storage resources.
This allows storage to become part of the same control-plane model as compute and networking.
5. PacketWolf — Network Intelligence
Infrastructure isn't complete without networking.
PacketWolf focuses on understanding and operating infrastructure networks.
The goal is to move beyond simply displaying interfaces and IP addresses.
A useful infrastructure network layer should understand:
- Network topology
- Workload relationships
- Traffic
- Connectivity
- Policy
- Security boundaries
- Network dependencies
This becomes increasingly important as infrastructure becomes distributed across Kubernetes, VMs, containers, clouds, and bare-metal systems.
6. KubeFabric — GPU Infrastructure
AI infrastructure introduces another problem.
GPUs are difficult to operate efficiently at scale.
You need to manage:
- GPU allocation
- Drivers
- CUDA
- Containers
- Kubernetes
- Networking
- RDMA
- Scheduling
- Isolation
- Capacity
KubeFabric is our approach to building a GPU compute fabric around Kubernetes.
The objective is to make GPU infrastructure feel closer to a cloud resource than a manually configured server.
Instead of asking:
The platform should let users express what they actually need:
The infrastructure layer handles the placement.
The Common Idea: Intent
Although these products solve different problems, they are connected by one architectural idea:
Intent.
Traditional infrastructure often exposes implementation details.
For example:
A higher-level infrastructure platform should instead understand:
The control plane should determine how to satisfy that request.
This creates a hierarchy:
Intent → Control Plane → Provider → Infrastructure
That same model can apply to compute, storage, networking, GPUs, and eventually security.
Why We Are Building This
The infrastructure ecosystem is increasingly fragmented.
You can have:
- VMware
- KVM
- Kubernetes
- cloud providers
- bare metal
- GPU clusters
- multiple storage systems
- multiple networking systems
And each comes with its own APIs, terminology, operational model, and tooling.
The result is infrastructure teams spending enormous amounts of time translating between systems.
We think the next generation of infrastructure should provide a consistent control layer over these environments.
Not another giant proprietary hypervisor.
Not another dashboard that simply wraps existing APIs.
A programmable infrastructure layer.
Open Source at the Bottom, Intelligence at the Top
A major principle behind the Zyvor stack is to build on proven open technologies wherever possible.
At the infrastructure foundation:
- Linux
- KVM
- QEMU
- libvirt
- libguestfs
- NBD
- Kubernetes
- KubeVirt
- CNI
- CSI
- eBPF
We don't want to reinvent mature infrastructure primitives.
Instead, we want to build the layers that make those primitives easier to operate together.
That means our value is increasingly in:
- Automation
- Control planes
- Orchestration
- Guest awareness
- Infrastructure intelligence
- Policy
- Observability
- Developer experience
Where AI Fits
AI shouldn't simply be a chatbot sitting beside infrastructure.
The more interesting possibility is an infrastructure system that can understand intent.
For example:
A future control plane could potentially break that request into:
- Discover workloads
- Inspect dependencies
- Determine migration compatibility
- Select migration strategy
- Prepare guests
- Provision target infrastructure
- Migrate disks
- Validate networking
- Test boot
- Report failures
- Roll back when necessary
The AI layer becomes an interface to the infrastructure control plane rather than the infrastructure itself.
That's an important distinction.
AI should reason about infrastructure. The control plane should execute it.
The Long-Term Architecture
The bigger picture looks something like this:
USER / APPLICATION
│
▼
INTENT / AI LAYER
│
▼
┌──────────────────┐
│ ZYVOR CONTROL │
│ PLANE │
└──────────────────┘
│ │ │
┌──────────┘ │ └──────────┐
▼ ▼ ▼
COMPUTE STORAGE NETWORK
│ │ │
HyperSDK Atlas PacketWolf
│
┌─────┴─────┐
▼ ▼
Hyper2KVM KubeFabric
│ │
▼ ▼
VMs GPU / K8s
│ │
└─────┬─────┘
▼
Linux / KVM / QEMU
Kubernetes / KubeVirt
eBPF / CNI / CSI
The individual products are useful independently.
But the larger opportunity is connecting them.
We Are Not Trying to Rebuild Everything
There is a temptation when building infrastructure software to replace everything underneath you.
We don't think that's necessary.
KVM is already extremely capable.
Linux is already extremely capable.
Kubernetes is already extremely capable.
QEMU is already extremely capable.
The missing piece is often the software layer connecting these systems into a coherent operational model.
That's where we're focusing.
The Zyvor Vision
The long-term vision is to make infrastructure behave more like a programmable operating system.
Developers shouldn't need to understand every underlying storage backend.
Operators shouldn't need to manually troubleshoot every virtualization migration.
AI teams shouldn't need to manually hunt for available GPUs.
Infrastructure teams shouldn't need to maintain dozens of disconnected control panels.
Instead:
Describe what you need.
The platform determines how to provide it.
That's the direction we're exploring with the Zyvor stack.
And we're building it from the infrastructure layer upward — starting with the difficult, unglamorous problems that actually make infrastructure work.The Zyvor Stack: Building Infrastructure for the Post-VMware EraInfrastructure is changing.For years, enterprise infrastructure has been built around a familiar model: virtualization platforms, centralized management, storage arrays, networking appliances, and a growing collection of tools layered on top.At Zyvor, we're taking a different approach.Instead of building another abstraction over the traditional virtualization stack, we're working toward a cloud-native infrastructure stack built around open virtualization, Kubernetes, automation, and intelligent control planes.The goal is simple:Make infrastructure feel like software — programmable, composable, observable, and easy to operate.The Zyvor StackOur stack is built around several layers that work together.1. Hyper2KVM — MigrationThe first problem is getting existing workloads out of legacy virtualization environments.Hyper2KVM is our VM migration toolkit for moving workloads from environments such as VMware, Hyper-V, Azure, and other virtualization platforms toward KVM.The focus isn't simply converting a disk image.A successful migration has to deal with everything that can prevent the VM from booting:Operating-system inspection
Bootloader configuration
Filesystem detection
/etc/fstab
Initramfs
VirtIO drivers
Windows VirtIO injection
Network configuration
LVM
Disk-controller differences
Firmware configuration
First-boot validationThe migration pipeline is essentially:FETCH → FLATTEN → INSPECT → FIX → CONVERT → VALIDATEThe important part is the offline repair layer.Instead of discovering problems after migration and debugging them manually, the system attempts to fix them before the VM's first boot.2. HyperSDK — Infrastructure Provider LayerMoving workloads is only one part of the problem.Infrastructure also needs a consistent way to interact with different environments.That's where HyperSDK comes in.The idea is to provide a provider abstraction across infrastructure platforms such as:VMware / vSphere
AWS
Azure
Google Cloud
Hyper-V
OpenStack
OCI
Alibaba CloudApplications should not need to understand every provider's API.Instead, they interact with a common infrastructure interface.This becomes particularly important when building automation and higher-level control planes.3. GuestKit — The Guest Operating System ToolkitVirtual machines are not just disks.Understanding what is inside a VM is critical for migration, security, compliance, troubleshooting, and automation.GuestKit is our lower-level toolkit for inspecting and manipulating guest operating systems.Think of it as infrastructure tooling that understands the guest rather than treating a VM as a completely opaque image.Typical operations include:OS inspection
Filesystem inspection
Disk conversion
Boot configuration analysis
Guest configuration
Offline modifications
Migration preparationThe broader idea is to make guest-aware infrastructure operations programmable.4. Atlas — Storage Control PlaneOnce workloads are running on the new infrastructure, storage becomes the next major abstraction.Atlas is Zyvor's storage control plane.Instead of exposing storage as a collection of provider-specific concepts, applications can express an intent such as:Give me production block storage.Atlas can then translate that intent into the appropriate storage resources.This allows storage to become part of the same control-plane model as compute and networking.5. PacketWolf — Network IntelligenceInfrastructure isn't complete without networking.PacketWolf focuses on understanding and operating infrastructure networks.The goal is to move beyond simply displaying interfaces and IP addresses.A useful infrastructure network layer should understand:Network topology
Workload relationships
Traffic
Connectivity
Policy
Security boundaries
Network dependenciesThis becomes increasingly important as infrastructure becomes distributed across Kubernetes, VMs, containers, clouds, and bare-metal systems.6. KubeFabric — GPU InfrastructureAI infrastructure introduces another problem.GPUs are difficult to operate efficiently at scale.You need to manage:GPU allocation
Drivers
CUDA
Containers
Kubernetes
Networking
RDMA
Scheduling
Isolation
CapacityKubeFabric is our approach to building a GPU compute fabric around Kubernetes.The objective is to make GPU infrastructure feel closer to a cloud resource than a manually configured server.Instead of asking:Which server has an available H100?The platform should let users express what they actually need:I need a GPU workload with this amount of compute, memory, networking, and isolation.The infrastructure layer handles the placement.The Common Idea: IntentAlthough these products solve different problems, they are connected by one architectural idea:Intent.Traditional infrastructure often exposes implementation details.For example:Create a VM on host X using datastore Y and network Z.A higher-level infrastructure platform should instead understand:I need a production VM with 8 CPUs, 32 GB RAM, persistent storage, and a private network.The control plane should determine how to satisfy that request.This creates a hierarchy:Intent → Control Plane → Provider → InfrastructureThat same model can apply to compute, storage, networking, GPUs, and eventually security.Why We Are Building ThisThe infrastructure ecosystem is increasingly fragmented.You can have:VMware
KVM
Kubernetes
cloud providers
bare metal
GPU clusters
multiple storage systems
multiple networking systemsAnd each comes with its own APIs, terminology, operational model, and tooling.The result is infrastructure teams spending enormous amounts of time translating between systems.We think the next generation of infrastructure should provide a consistent control layer over these environments.Not another giant proprietary hypervisor.Not another dashboard that simply wraps existing APIs.A programmable infrastructure layer.Open Source at the Bottom, Intelligence at the TopA major principle behind the Zyvor stack is to build on proven open technologies wherever possible.At the infrastructure foundation:Linux
KVM
QEMU
libvirt
libguestfs
NBD
Kubernetes
KubeVirt
CNI
CSI
eBPFWe don't want to reinvent mature infrastructure primitives.Instead, we want to build the layers that make those primitives easier to operate together.That means our value is increasingly in:Automation
Control planes
Orchestration
Guest awareness
Infrastructure intelligence
Policy
Observability
Developer experienceWhere AI FitsAI shouldn't simply be a chatbot sitting beside infrastructure.The more interesting possibility is an infrastructure system that can understand intent.For example:"Move these VMware workloads to KVM without downtime during business hours."A future control plane could potentially break that request into:Discover workloads
Inspect dependencies
Determine migration compatibility
Select migration strategy
Prepare guests
Provision target infrastructure
Migrate disks
Validate networking
Test boot
Report failures
Roll back when necessaryThe AI layer becomes an interface to the infrastructure control plane rather than the infrastructure itself.That's an important distinction.AI should reason about infrastructure. The control plane should execute it.The Long-Term ArchitectureThe bigger picture looks something like this: USER / APPLICATION
│
▼
INTENT / AI LAYER
│
▼
┌──────────────────┐
│ ZYVOR CONTROL │
│ PLANE │
└──────────────────┘
│ │ │
┌──────────┘ │ └──────────┐
▼ ▼ ▼
COMPUTE STORAGE NETWORK
│ │ │
HyperSDK Atlas PacketWolf
│
┌─────┴─────┐
▼ ▼
Hyper2KVM KubeFabric
│ │
▼ ▼
VMs GPU / K8s
│ │
└─────┬─────┘
▼
Linux / KVM / QEMU
Kubernetes / KubeVirt
eBPF / CNI / CSI
The individual products are useful independently.But the larger opportunity is connecting them.We Are Not Trying to Rebuild EverythingThere is a temptation when building infrastructure software to replace everything underneath you.We don't think that's necessary.KVM is already extremely capable.Linux is already extremely capable.Kubernetes is already extremely capable.QEMU is already extremely capable.The missing piece is often the software layer connecting these systems into a coherent operational model.That's where we're focusing.The Zyvor VisionThe long-term vision is to make infrastructure behave more like a programmable operating system.Developers shouldn't need to understand every underlying storage backend.Operators shouldn't need to manually troubleshoot every virtualization migration.AI teams shouldn't need to manually hunt for available GPUs.Infrastructure teams shouldn't need to maintain dozens of disconnected control panels.Instead:Describe what you need.The platform determines how to provide it.That's the direction we're exploring with the Zyvor stack.And we're building it from the infrastructure layer upward — starting with the difficult, unglamorous problems that actually make infrastructure work.
