DEV Community

Susant Sahani
Susant Sahani

Posted on

Zeus OS: Building a Kubernetes-Native Operating Layer for Virtual Machines

#kubernetes #kubevirt #virtualization #devops

Kubernetes transformed how organizations operate containers.

But enterprise infrastructure isn't made entirely of containers.

There are still thousands of workloads running as virtual machines:

  • Windows Server
  • Enterprise databases
  • Legacy applications
  • Commercial software
  • Stateful middleware
  • Network appliances
  • Internal business applications

For many organizations, replacing every VM with a container isn't realistic.

The more practical question is:

Can we operate virtual machines and containers through the same infrastructure control plane?

That's the problem we're working on with Zeus OS at Zyvor AI Labs.

What is Zeus OS?

Zeus OS is a visual infrastructure operating layer built around Kubernetes and KubeVirt.

Its purpose is to make Kubernetes-native virtualization practical for infrastructure teams.

Instead of maintaining one operational model for Kubernetes and another for traditional virtualization, Zeus OS works toward a unified model:

Applications
     │
     ├── Containers
     │
     └── Virtual Machines
              │
              ▼
        Kubernetes + KubeVirt
              │
              ▼
           Zeus OS
              │
              ▼
   Compute · Network · Storage
Enter fullscreen mode Exit fullscreen mode

The objective isn't to pretend virtual machines are containers.

They aren't.

The objective is to use Kubernetes as an infrastructure control plane while preserving VM semantics where they are required.

Why KubeVirt?

KubeVirt extends Kubernetes so virtual machines can become first-class Kubernetes-managed workloads.

A simplified VM definition might look conceptually like:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: windows-server
spec:
  running: true
  template:
    metadata:
      labels:
        app: windows-server
    spec:
      domain:
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
Enter fullscreen mode Exit fullscreen mode

Now infrastructure objects can participate in the Kubernetes API model.

That gives us interesting possibilities around:

  • Declarative VM definitions
  • API-driven provisioning
  • RBAC
  • Scheduling
  • Automation
  • Policies
  • Observability
  • Infrastructure-as-code

But exposing raw Kubernetes resources isn't enough for most virtualization teams.

That's where an operating layer becomes important.

Kubernetes APIs are powerful — but infrastructure teams need workflows

A virtualization administrator usually thinks in terms such as:

Create VM
Start VM
Stop VM
Clone VM
Take snapshot
Attach disk
Configure network
Migrate VM
Open console
Check health
Enter fullscreen mode Exit fullscreen mode

They shouldn't have to translate every operation into several Kubernetes manifests and controllers.

The infrastructure platform needs to convert familiar operational intent into Kubernetes-native actions.

Conceptually:

Infrastructure intent
        ↓
      Zeus OS
        ↓
 Kubernetes APIs
        ↓
     KubeVirt
        ↓
       KVM
Enter fullscreen mode Exit fullscreen mode

That abstraction is important.

The goal isn't to hide Kubernetes completely.

It's to make Kubernetes usable as infrastructure.

Virtual machines become declarative infrastructure

Traditional virtualization platforms are often heavily state-driven.

An administrator clicks:

Create VM
Enter fullscreen mode Exit fullscreen mode

and the platform creates something.

Kubernetes introduces a different model.

You describe the state you want.

For example:

VM should exist
VM should have 8 CPUs
VM should have 16 GB RAM
VM should use this disk
VM should connect to this network
VM should be running
Enter fullscreen mode Exit fullscreen mode

Controllers continuously reconcile reality with that desired state.

This means the infrastructure model becomes:

Desired state
      ↓
Reconciliation
      ↓
Actual infrastructure
Enter fullscreen mode Exit fullscreen mode

That is one of the most important advantages of applying Kubernetes principles to virtualization.

VMs and containers under one API

Consider an enterprise application with:

Frontend
   ↓
Containers

API
   ↓
Containers

Legacy service
   ↓
Windows VM

Database
   ↓
Linux VM
Enter fullscreen mode Exit fullscreen mode

Traditionally, these workloads might be operated through entirely separate systems.

With Kubernetes and KubeVirt, the potential architecture becomes:

             Kubernetes API
                   │
          ┌────────┴────────┐
          │                 │
     Containers             VMs
          │                 │
      containerd        KubeVirt
                            │
                           KVM
Enter fullscreen mode Exit fullscreen mode

Zeus OS sits above this environment to provide infrastructure-focused workflows and visibility.

The VMware migration question

A major reason organizations are evaluating KubeVirt today is infrastructure modernization.

When leaving a traditional virtualization stack, organizations face two decisions.

First:

Where do we move the virtual machines?

Second:

What should operate them afterward?

KVM solves the hypervisor question.

KubeVirt can solve part of the orchestration question.

But enterprises still need an operational experience around the resulting infrastructure.

At Zyvor, we're building the migration path and the target operating environment together.

Conceptually:

VMware
   │
   ▼
Guest inspection
   │
   ▼
hyper2kvm
   │
   ▼
KVM / KubeVirt
   │
   ▼
Zeus OS
Enter fullscreen mode Exit fullscreen mode

This matters because migration without day-two operations is only half a solution.

VM lifecycle

Once VMs are running, infrastructure teams need normal lifecycle operations.

That includes:

  • Create
  • Start
  • Stop
  • Restart
  • Delete
  • Clone
  • Resize
  • Attach storage
  • Configure networking
  • Access console
  • Inspect health

These operations need to feel like infrastructure operations even when Kubernetes is underneath them.

Storage matters

Virtual machines are often much more storage-sensitive than stateless container workloads.

A useful VM platform needs to understand concepts such as:

VirtualMachine
      │
      ▼
DataVolume / PVC
      │
      ▼
StorageClass
      │
      ▼
CSI
      │
      ▼
Underlying storage
Enter fullscreen mode Exit fullscreen mode

Kubernetes storage primitives are powerful, but VM users care about outcomes:

  • Create a disk
  • Import an image
  • Expand a disk
  • Clone a disk
  • Snapshot a VM
  • Restore a VM

The platform should expose the outcome while using Kubernetes storage primitives underneath.

Windows is critical

Any serious enterprise virtualization platform must treat Windows as a first-class workload.

Enterprise estates contain enormous numbers of:

  • Windows Server workloads
  • Active Directory-connected applications
  • Microsoft SQL Server
  • .NET applications
  • Vendor appliances
  • Internal Windows services

A Kubernetes-native virtualization platform therefore needs workflows around:

  • Windows installation
  • VirtIO drivers
  • Disk preparation
  • Networking
  • VM templates
  • Console access
  • Migration preparation

KubeVirt cannot be positioned only as a Linux virtualization technology if the goal is enterprise VM modernization.

Networking becomes interesting

Virtual machine networking inside Kubernetes opens up powerful possibilities.

You now have multiple layers:

Application
    │
   VM
    │
KubeVirt
    │
Pod network / secondary network
    │
CNI
    │
Physical network
Enter fullscreen mode Exit fullscreen mode

Technologies such as Cilium and eBPF make this even more interesting.

Instead of viewing networking only as:

VM → vSwitch → VLAN
Enter fullscreen mode Exit fullscreen mode

we can begin thinking about workload identity, policy, observability, and infrastructure networking through a common programmable layer.

This is also where Zeus OS connects naturally with another Zyvor project: PacketWolf.

Infrastructure topology

One of the problems with increasingly distributed infrastructure is understanding relationships.

Operators need to understand:

Cluster
 ├── Node
 │    ├── VM
 │    ├── VM
 │    └── Pod
 │
 ├── Node
 │    ├── VM
 │    └── Pod
 │
 └── Network
      ├── Services
      └── Policies
Enter fullscreen mode Exit fullscreen mode

A useful infrastructure UI shouldn't just display independent tables.

It should help operators understand:

  • Where a workload runs
  • Which network it uses
  • Which storage backs it
  • What services depend on it
  • Whether it is healthy
  • What changed recently

Infrastructure operations are ultimately about relationships.

Observability should cross the VM boundary

Traditional VM monitoring often stops at:

CPU
Memory
Disk
Network
Enter fullscreen mode Exit fullscreen mode

Useful, but incomplete.

Modern infrastructure should be able to correlate:

VM
 ↓
Process
 ↓
Connection
 ↓
Service
 ↓
Network policy
Enter fullscreen mode Exit fullscreen mode

Combining KubeVirt, Kubernetes observability, eBPF, and infrastructure intelligence creates the possibility of much deeper operational context.

Instead of asking:

Why is this VM using network bandwidth?

we want to eventually answer:

Which process inside which workload is communicating with which service, through which policy path?

That is a much more useful infrastructure question.

Policy becomes API-driven

Once infrastructure is represented through APIs, policy becomes much easier to automate.

Imagine rules such as:

Production VMs require backups.

Internet-facing workloads require approved network policies.

Windows templates require VirtIO drivers.

VMs above a resource threshold require approval.

Migration candidates must pass readiness validation.
Enter fullscreen mode Exit fullscreen mode

Instead of documenting these requirements in a spreadsheet, the platform can eventually enforce them as infrastructure policy.

Multi-cluster infrastructure

Enterprise infrastructure rarely stays inside one cluster.

Organizations may have:

Datacenter A
     │
 Kubernetes cluster

Datacenter B
     │
 Kubernetes cluster

Edge location
     │
 Kubernetes cluster
Enter fullscreen mode Exit fullscreen mode

Infrastructure teams need visibility across those environments.

The long-term operating model becomes less about managing individual hypervisor hosts and more about managing fleets of infrastructure clusters.

                Zeus OS
                   │
       ┌───────────┼───────────┐
       │           │           │
   Cluster A   Cluster B   Edge Cluster
       │           │           │
      VMs          VMs       VMs + Pods
Enter fullscreen mode Exit fullscreen mode

That changes the abstraction level of virtualization management.

Kubernetes should not make virtualization harder

Kubernetes provides powerful primitives.

But power without usability creates another form of complexity.

We don't believe virtualization administrators should need to become Kubernetes API experts before they can create or troubleshoot a VM.

Likewise, Kubernetes engineers shouldn't need a completely separate infrastructure stack simply because a workload still requires a VM.

The goal should be convergence.

Traditional virtualization
          +
      Kubernetes
          ↓
Unified infrastructure operations
Enter fullscreen mode Exit fullscreen mode

What Zeus OS is trying to become

We're building Zeus OS around a simple idea:

Kubernetes can become an infrastructure operating layer, not just a container orchestrator.

That means bringing together:

  • Kubernetes
  • KubeVirt
  • KVM
  • VM lifecycle
  • Storage
  • Networking
  • Migration
  • Observability
  • Security
  • Automation

into an operational experience designed for infrastructure teams.

The larger Zyvor architecture

Zeus OS isn't being developed in isolation.

Across the Zyvor platform:

GuestKit helps understand virtual machines before migration.

hyper2kvm handles VMware-to-KVM conversion and remediation workflows.

Machina provides KVM and libvirt operations.

PacketWolf focuses on network intelligence.

HyperCluster manages Kubernetes cluster lifecycle.

And Zeus OS provides the visual operating layer for the resulting Kubernetes and KubeVirt infrastructure.

Conceptually:

                 HyperSDK
                    │
       ┌────────────┼────────────┐
       │            │            │
   Migration     Operations   Intelligence
       │            │            │
 hyper2kvm      Zeus OS      PacketWolf
 GuestKit       Machina
                    │
                    ▼
           Kubernetes + KubeVirt
                    │
                    ▼
                   KVM
Enter fullscreen mode Exit fullscreen mode

The post-VMware opportunity

The VMware discussion shouldn't end with:

Which hypervisor replaces VMware?

The bigger question is:

What should enterprise virtualization look like for the next decade?

We think the answer will increasingly involve open infrastructure built around technologies such as:

  • Linux
  • KVM
  • Kubernetes
  • KubeVirt
  • Cilium
  • eBPF
  • CSI
  • Open APIs

But the open-source components alone aren't the complete product.

Enterprises still need lifecycle management, migration workflows, policies, observability, security, and an operational experience.

That's the layer we're working on with Zeus OS.

If you're currently experimenting with KubeVirt or planning a VMware exit, we'd love to hear what's missing from today's Kubernetes virtualization experience.

What would your infrastructure team need before it could operate production VMs on Kubernetes?

Zyvor AI Labs
https://zyvor.dev

HyperSDK Platform
https://zyvor.dev

Top comments (0)