DEV Community: Susant Sahani

PacketWolf: Bringing eBPF Network Intelligence to Kubernetes and Virtual Machines

Susant Sahani — Mon, 10 Aug 2026 08:46:04 +0000

Modern infrastructure networking has a visibility problem.

We can usually answer questions like:

Which IP talked to which IP?
Which port was used?
How many bytes were transferred?
Which Kubernetes service received traffic?

Those answers are useful.

But when something goes wrong, infrastructure teams usually need much more context.

They need to know:

Which workload initiated the connection?

Which process caused it?

Was that communication expected?

Which policy allowed it?

Should this flow exist at all?

That is the problem we're working on with PacketWolf at Zyvor AI Labs.

What is PacketWolf?

PacketWolf is a network intelligence and policy platform designed around modern Linux networking technologies including:

eBPF
Cilium
Hubble
Kubernetes
KubeVirt
Linux networking

The objective is to move infrastructure visibility beyond raw packets and IP addresses.

We want to connect:

```text id="7jv7ec"
Process
↓
Workload
↓
Network connection
↓
Destination
↓
Policy




That context changes how networking can be operated.

## Traditional network visibility stops too early

Consider a flow:



```text id="c1oq4j"
10.20.3.14:49218
        ↓
10.20.8.22:5432

Traditional tooling might tell us:

```text id="l09e65"
Source: 10.20.3.14
Destination: 10.20.8.22
Port: 5432
Protocol: TCP




But an engineer still needs to determine:



```text id="xry3ti"
What is 10.20.3.14?

Which application owns it?

Which process created the connection?

Why is it talking to PostgreSQL?

Is this expected behavior?

In a dynamic Kubernetes environment, even the IP address itself may be temporary.

Network intelligence therefore needs workload context.

Kubernetes changed network identity

Traditional infrastructure often treated IP addresses as relatively stable identities.

Kubernetes changed that assumption.

Pods are created and destroyed continuously.

An application might move from:

```text id="eey6h2"
10.0.1.18




to:



```text id="o2vzto"
10.0.7.43

without the application logically changing at all.

The meaningful identity isn't necessarily:

```text id="5rtylz"
10.0.7.43




It may be:



```text id="hwje0e"
namespace: payments
service: checkout
workload: checkout-api
pod: checkout-api-7f7c8

This is one reason identity-aware networking becomes so important in Kubernetes.

Cilium and eBPF

Cilium uses eBPF to provide networking, observability, and security capabilities in Linux and Kubernetes environments.

eBPF allows programs to run safely inside the Linux kernel at strategic points.

That creates powerful possibilities for observing network behavior without relying entirely on traditional packet capture.

Conceptually:

```text id="e78wsp"
Application
│
▼
Linux socket
│
▼
eBPF
│
▼
Network stack
│
▼
Network




Instead of only observing packets after the fact, we can gain context much closer to where communication originates.

## Hubble provides flow visibility

Hubble adds network observability on top of Cilium.

It can provide visibility into flows such as:



```text id="aavkxc"
frontend
    │
    ▼
checkout-api
    │
    ▼
payment-service
    │
    ▼
database

This is extremely valuable.

But we think there is another layer of intelligence that can be built on top.

PacketWolf focuses on turning observed network behavior into operational answers.

From flows to relationships

A raw network flow is an event.

Infrastructure teams need relationships.

Instead of displaying thousands of entries like:

```text id="nzec31"
A → B
A → C
B → D
A → B
C → D




we want to build a model like:



```text id="meuv2z"
                  frontend
                     │
                     ▼
                checkout-api
                  /       \
                 ▼         ▼
          payment-api   inventory
                 │
                 ▼
             postgres

Now the network becomes understandable as an application system rather than a stream of packet metadata.

Service maps

One of PacketWolf's core ideas is automatically building service relationships from observed communication.

A useful service map should help answer:

Which services communicate?
Which dependencies are new?
Which workloads are unexpectedly exposed?
Which destinations are external?
Which communications disappeared?
Which flows violate the expected architecture?

The map becomes particularly useful during incidents.

Instead of manually correlating logs across multiple systems, an operator can begin from the communication graph.

Process-to-network attribution

One of the areas we're particularly interested in is connecting network flows back to processes.

Imagine observing:

```text id="15mfvg"
VM: finance-app-04
Process: java
PID: 4821
Destination: 172.20.8.15
Port: 5432
Protocol: TCP




That is significantly more useful than:



```text id="cf3pi1"
172.20.2.41 → 172.20.8.15:5432

Now an operator has immediate application context.

This becomes valuable for:

Incident investigation
Security analysis
Dependency discovery
Migration validation
Network policy generation
Application modernization

What about virtual machines?

Network intelligence shouldn't stop at Kubernetes pods.

Enterprise environments contain both:

```text id="3ypdjf"
Containers
+
Virtual Machines




KubeVirt makes this especially interesting because VMs can operate alongside container workloads inside Kubernetes-managed infrastructure.

A topology could look like:



```text id="3nvl1m"
                Kubernetes
                    │
        ┌───────────┴───────────┐
        │                       │
       Pods                    VMs
        │                       │
        └───────────┬───────────┘
                    │
                 Cilium
                    │
                  eBPF
                    │
              Network fabric

The operational challenge is creating a consistent network view across both workload types.

That is one of PacketWolf's goals.

Why this matters for VM migration

Imagine migrating a VMware VM to KVM or KubeVirt.

The disk conversion succeeds.

The VM boots.

The network interface is online.

Is the migration successful?

Not necessarily.

The application might depend on:

```text id="ftzq40"
Database
LDAP
DNS
NTP
License server
Internal APIs
Message queue
External SaaS endpoint




If even one dependency is broken, the VM may be technically alive but operationally unusable.

Network intelligence can make post-migration validation much stronger.

Instead of checking only:



```text id="b8lo3m"
VM booted ✓

we can check:

```text id="vmtzbf"
VM booted ✓
Expected services reached ✓
Database dependency ✓
DNS ✓
External endpoint ✓
Unexpected traffic none




This turns networking into part of migration assurance.

## Observe first, then create policy

Network policy is powerful.

But writing policies before understanding application behavior can be dangerous.

A better workflow is:



```text id="4el8wa"
Observe
   ↓
Learn
   ↓
Model dependencies
   ↓
Recommend policy
   ↓
Review
   ↓
Enforce

That is much safer than immediately denying traffic based on assumptions.

AutoPolicy

PacketWolf's AutoPolicy concept is based on observed communication.

Suppose an application consistently communicates only with:

```text id="a01yb5"
frontend → api
api → postgres
api → redis




PacketWolf can use those relationships as input for a proposed network policy.

Conceptually:



```yaml id="4t9ynp"
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
spec:
  endpointSelector:
    matchLabels:
      app: api
  egress:
    - toEndpoints:
        - matchLabels:
            app: postgres
    - toEndpoints:
        - matchLabels:
            app: redis

The important point isn't automatically generating YAML.

The useful part is understanding why those rules should exist.

Policy should be based on observed workload behavior and explicit operator review.

Unexpected communication is often the interesting communication

Suppose a service normally communicates with:

```text id="f1wfer"
database
redis
internal-api




Then suddenly it starts communicating with:



```text id="cbow0j"
unknown external IP

That difference can be more useful than another dashboard showing total network throughput.

PacketWolf can conceptually compare:

```text id="9jds8b"
Expected graph
vs
Observed graph




and surface deviations.

This becomes useful for both reliability and security.

## Network health

Network troubleshooting often begins with a vague symptom:

> The application is slow.

The cause might be:

* Packet loss
* DNS failures
* Policy drops
* Connection retries
* Service availability
* Latency
* Routing changes
* Backend instability

A network intelligence platform should connect infrastructure signals together rather than force engineers to inspect them individually.

For example:



```text id="yp5v3w"
checkout-api degraded
        │
        ├── latency increased
        │
        ├── postgres retries increased
        │
        └── network policy unchanged

That is closer to an operational answer.

Policy visibility matters too

Having a network policy does not automatically mean operators understand it.

A workload may be affected by multiple layers of policy.

What infrastructure teams often want to know is:

```text id="95csh9"
Can workload A talk to workload B?




And if not:



```text id="0xy6s1"
Why not?

The answer should ideally explain:

```text id="p4ehxz"
checkout-api
│
▼
payment-api
│
✕
Blocked by:
CiliumNetworkPolicy/payment-restricted




That is more useful than simply reporting a dropped packet.

## Infrastructure needs explainability

As infrastructure becomes more automated, explainability becomes increasingly important.

Automation shouldn't just say:



```text id="68swl6"
Denied.

It should say:

```text id="k3ma5h"
Connection denied because workload
"checkout-api" attempted TCP/5432 toward
"analytics-db", but the active egress policy
permits only "payments-db".




That turns policy into something operators can reason about.

## Security and operations are converging

Network observability used to be largely an operations concern.

Network security was handled separately.

eBPF makes that boundary much less clear.

The same network context can help answer:

### Operations

Why is the application slow?

### Security

Why is this workload communicating externally?

### Platform engineering

Which services depend on this database?

### Migration

Did the migrated VM restore all required connections?

### Architecture

What does the actual application dependency graph look like?

One source of network intelligence can support all of these workflows.

## PacketWolf and Zeus OS

PacketWolf is designed to complement **Zeus OS**.

Zeus OS answers:



```text id="1gzjgp"
What infrastructure is running?

PacketWolf answers:

```text id="mdsg4u"
How is that infrastructure communicating?




Together, the model becomes:



```text id="y5trzt"
             Zeus OS
                │
     Infrastructure topology
                │
                ▼
           PacketWolf
                │
        Network topology
                │
                ▼
      eBPF + Cilium + Hubble

The combination gives infrastructure operators both resource and communication context.

The broader Zyvor stack

PacketWolf is one part of the HyperSDK platform.

```text id="prm6pa"
HyperSDK
│
┌─────────────┼─────────────┐
│ │ │
Migration Operations Network
│ │ │
hyper2kvm Zeus OS PacketWolf
GuestKit Machina
│ │ │
└─────────────┼─────────────┘
│
Kubernetes / KVM




The idea is that migration, operations, and networking shouldn't live in completely disconnected systems.

## The network should tell a story

Infrastructure produces enormous amounts of telemetry.

The challenge isn't collecting more data.

The challenge is converting it into answers.

Instead of:



```text id="zvsl3g"
2.4 million flows observed

we want infrastructure teams to see:

```text id="fakfne"
Payment service created a new external dependency.

Three migrated VMs lost connectivity to DNS.

One production workload is communicating outside its expected policy.

Database latency increased after a network path change.




That is the direction we're taking with PacketWolf.

## What's next?

We're interested in the intersection between:

* eBPF
* Cilium
* Hubble
* Kubernetes
* KubeVirt
* Virtual machines
* Network policy
* Service topology
* Process attribution
* Migration validation

because we think enterprise networking needs to become much more workload-aware.

Packets are useful.

Flows are better.

But the real goal is understanding:

> **Who communicated, why they communicated, whether they should have communicated, and what changed.**

That's the problem **PacketWolf** is being built to solve.

If you're operating Cilium, KubeVirt, or mixed VM/container infrastructure, we'd be interested in hearing what network visibility is still missing for your team.

**What is harder today: discovering dependencies, troubleshooting flows, or building correct network policies?**

**Zyvor AI Labs**
https://zyvor.dev

**HyperSDK Platform**
https://zyvor.dev

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

Susant Sahani — Mon, 10 Aug 2026 08:15:22 +0000

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

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

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

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

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

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

Controllers continuously reconcile reality with that desired state.

This means the infrastructure model becomes:

Desired state
      ↓
Reconciliation
      ↓
Actual infrastructure

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

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

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

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

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

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

Instead of viewing networking only as:

VM → vSwitch → VLAN

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

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

Useful, but incomplete.

Modern infrastructure should be able to correlate:

VM
 ↓
Process
 ↓
Connection
 ↓
Service
 ↓
Network policy

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.

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

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

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

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

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

VMware to KVM Migration: Why Disk Conversion Is Only the Beginning

Susant Sahani — Mon, 10 Aug 2026 07:58:51 +0000

Moving a virtual machine from VMware to KVM sounds simple:

VMDK → QCOW2 → Boot

In practice, that is often the easiest part.

A disk can convert perfectly and still leave you with a virtual machine that:

fails to find its root filesystem,
drops into an initramfs shell,
cannot see its virtual disk,
loses its network configuration,
fails because of firmware differences,
or boots into Windows recovery.

At Zyvor AI Labs, we see VM migration as a guest-operating-system problem as much as a disk-format problem.

That is one of the reasons we built hyper2kvm and GuestKit.

A converted disk is not a migrated VM

Tools such as qemu-img can convert virtual disk formats very effectively.

For example:

qemu-img convert -p \
  -f vmdk \
  -O qcow2 \
  source.vmdk \
  destination.qcow2

At this point you have a QCOW2 image.

You do not necessarily have a bootable KVM virtual machine.

The guest operating system was originally installed against a particular virtual hardware environment.

Changing that environment can affect:

Storage controllers
Network adapters
Firmware
Bootloader configuration
Kernel modules
Device naming
Filesystem references
Windows drivers

Successful migration therefore requires understanding what is inside the disk.

Problem 1: Storage drivers

One of the most common migration issues is storage.

A VMware guest may have been running against VMware virtual storage hardware.

The KVM target may expose disks using VirtIO.

Linux generally has excellent VirtIO support, but the required modules still need to be available at the right point during boot.

Relevant modules can include:

virtio
virtio_pci
virtio_blk
virtio_scsi

If the required storage driver is not available inside the initramfs, the kernel may start successfully but fail to locate the root filesystem.

The migration looks like it failed at KVM.

The real problem is inside the guest.

Problem 2: initramfs

Linux systems frequently depend on an initial RAM filesystem to load storage and filesystem modules before mounting the real root filesystem.

After changing virtual hardware, the existing initramfs may not contain what the new environment requires.

This is why migration tooling needs to inspect and, where required, rebuild the initramfs.

Depending on the distribution, that could involve tools such as:

dracut

or:

update-initramfs

The exact workflow differs across Linux distributions.

A migration system therefore needs to understand the guest rather than blindly apply one repair command.

Problem 3: GRUB and boot paths

The next problem is boot configuration.

A virtual machine may originally have been configured for:

BIOS
UEFI
GPT
MBR

The target environment needs to reproduce a compatible boot path.

GRUB configurations can also reference disks by:

UUID
filesystem label
/dev/sdX
/dev/vdX
LVM paths

Hard-coded device names are particularly fragile.

A VMware disk that appeared as:

/dev/sda

could appear under KVM as:

/dev/vda

if VirtIO block devices are used.

The filesystem still exists.

The operating system simply may not know where to find it.

Problem 4: `/etc/fstab`

Consider an entry like this:

/dev/sda2 / ext4 defaults 0 1

After migration, /dev/sda2 may no longer exist under that name.

A more resilient system may use:

UUID=<filesystem-uuid> / ext4 defaults 0 1

Migration assessment should therefore examine filesystem references before cutover.

Otherwise a perfectly healthy converted disk can fail during boot because one configuration file expects a device name that changed.

Problem 5: Windows is different

Windows migration introduces another set of challenges.

Moving a Windows VM from VMware to KVM may require making VirtIO drivers available before the machine boots on the target hypervisor.

Potential requirements include drivers for:

VirtIO storage
SCSI
Network adapters
Balloon devices

If Windows cannot access the boot disk through the new controller, it may fail long before a user can install the missing driver manually.

That means driver preparation often needs to happen offline, before first boot.

Problem 6: Networking

Even after the operating system boots, networking can still break.

The guest sees different virtual NIC hardware.

That can interact with:

MAC-address-based configuration
interface naming
static IP configuration
udev rules
NetworkManager profiles
netplan
systemd-networkd
legacy Linux network scripts

A machine that successfully reaches a login prompt but has no network connectivity is not a successful enterprise migration.

Validation must extend beyond "did it boot?"

This is why we built GuestKit

GuestKit approaches migration from the other direction.

Instead of first booting a migrated VM and discovering what broke, GuestKit examines the guest disk offline.

The idea is:

Inspect before cutover.

GuestKit can analyze virtual disk formats such as:

VMDK
QCOW2
RAW

and gather information about what is inside the guest.

That can include areas such as:

Operating system identification
Boot configuration
Filesystems
Drivers
initramfs
GRUB
fstab
Potential migration blockers

The objective is to determine whether a guest is migration-ready before putting it into a cutover window.

Fleet migration changes the problem

Testing one virtual machine manually is manageable.

Testing 1,000 is not.

At fleet scale, migration teams need answers such as:

Which VMs are ready?
Which VMs require remediation?
Which Windows guests are missing drivers?
Which Linux guests have risky boot configurations?
Which systems should not enter the current migration wave?

That requires structured inspection.

Instead of:

VM → migrate → boot → debug

we prefer:

VM
 ↓
Offline inspection
 ↓
Readiness assessment
 ↓
Remediation plan
 ↓
Conversion
 ↓
Validation
 ↓
Cutover

This allows infrastructure teams to move failure discovery earlier in the process.

hyper2kvm handles the migration workflow

Where GuestKit focuses on understanding the guest, hyper2kvm focuses on the actual VMware-to-KVM migration workflow.

The migration process can involve:

Source VM
   ↓
Disk acquisition
   ↓
Guest inspection
   ↓
Driver preparation
   ↓
Disk conversion
   ↓
Boot remediation
   ↓
Target configuration
   ↓
Validation
   ↓
KVM

That is much closer to the real problem than treating migration as:

qemu-img convert

Preflight matters

Enterprise migration projects should ideally identify problematic machines before the scheduled cutover.

A preflight system can ask:

Is the disk readable?

If not, stop.

Is the operating system identifiable?

If not, flag it.

Is the boot configuration understood?

If not, investigate.

Are target storage drivers available?

If not, inject or rebuild them.

Are filesystem mounts safe?

If not, remediate them.

Is the firmware configuration compatible?

If not, adjust the target definition.

Can we verify the resulting guest?

If not, do not treat conversion success as migration success.

Validation should be explicit

A migration pipeline should produce a clear result.

For example:

{
  "guest": "finance-db-07",
  "source": "vmware",
  "target": "kvm",
  "disk_conversion": "passed",
  "boot_readiness": "passed",
  "virtio_storage": "present",
  "network_review": "required",
  "migration_status": "ready_with_warning"
}

That is far more useful than:

Conversion completed successfully.

The first result tells an engineer what still needs attention.

The second only tells us that bytes were copied successfully.

The real migration unit is the guest

Hypervisors operate virtual hardware.

Applications run inside operating systems.

That distinction matters during migration.

If we only look at the disk format, we miss the systems responsible for actually starting the workload:

Firmware
   ↓
Bootloader
   ↓
Kernel
   ↓
Initramfs
   ↓
Storage
   ↓
Root filesystem
   ↓
Networking
   ↓
Application

Every layer can introduce a migration failure.

Where we're taking this

At Zyvor, our goal is to make VMware-to-KVM migration more deterministic.

That means moving from:

Convert and hope

to:

Inspect → understand → remediate → convert → validate

hyper2kvm handles the migration path.

GuestKit provides offline intelligence about what is inside the guest.

And HyperSDK provides the broader orchestration layer around discovery, migration, validation, and infrastructure operations.

If you're planning VMware-to-KVM migrations, we're particularly interested in hearing about the failures that are hardest to automate.

What causes the most trouble in your environment: Windows drivers, bootloader issues, Linux initramfs, networking, or application validation?

Zyvor AI Labs
https://zyvor.dev

GuestKit:
https://zyvor.dev/blog/guestkit-offline-disk-intelligence

VMware → KVM migration:
https://zyvor.dev/blog/windows-vm-migration-kvm

Introducing Zyvor AI Labs: Building Open Infrastructure for the Post-VMware Era

Susant Sahani — Mon, 10 Aug 2026 07:56:20 +0000

Enterprise infrastructure is changing.

VMware licensing changes, rising public-cloud costs, Kubernetes adoption, growing AI workloads, and increasing infrastructure complexity are forcing organizations to rethink how they operate compute infrastructure.

At Zyvor AI Labs, we're building an open infrastructure platform for that transition.

Our goal is straightforward:

Give enterprises the freedom to migrate, run, secure, automate, and operate workloads without becoming locked into another infrastructure vendor.

Meet HyperSDK

At the center of Zyvor is HyperSDK, our infrastructure modernization and orchestration platform.

We don't see infrastructure modernization as simply converting a VMware virtual machine into another disk format.

The lifecycle is much bigger:

Discover → Assess → Migrate → Validate → Operate → Secure → Automate

HyperSDK brings together technologies for virtualization, migration, Kubernetes, networking, automation, AI infrastructure, and operational intelligence.

hyper2kvm: VMware to KVM migration

hyper2kvm is focused on migrating virtual machines toward KVM-based infrastructure.

Migration can involve much more than converting a VMDK to QCOW2.

The guest operating system must still boot correctly afterward.

hyper2kvm addresses areas such as:

Disk conversion
VirtIO preparation
Windows migration readiness
Boot-path remediation
initramfs repair
GRUB repair
Post-conversion validation

Our goal is to make VM migration repeatable and automatable rather than treating every VM as a manual project.

GuestKit: Know before you migrate

One of the biggest migration risks is discovering a problem after cutover.

That's why we built GuestKit.

GuestKit provides offline VM disk intelligence so infrastructure teams can inspect guest disks before booting or migrating them.

It can help answer questions such as:

Is this VM likely to boot after migration?
Are the necessary drivers present?
Is the bootloader healthy?
What migration blockers exist?
What should be fixed before cutover?

GuestKit works with common virtual disk formats including QCOW2, VMDK, and RAW.

This becomes especially valuable when assessing hundreds or thousands of machines ahead of a migration wave.

Zeus OS: Virtual machines on Kubernetes

Containers aren't replacing every enterprise VM.

A large number of organizations need to operate both.

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

We're building it to make Kubernetes-based virtualization practical for infrastructure teams managing both traditional VMs and modern containerized workloads.

Machina: KVM operations

After migration, someone still needs to operate the infrastructure.

Machina focuses on KVM and libvirt management, VM lifecycle operations, provisioning, automation, and day-two infrastructure management.

The objective is to make open virtualization infrastructure easier to operate at enterprise scale.

PacketWolf: Network intelligence

Modern infrastructure isn't only about compute.

Understanding how workloads communicate is equally important.

PacketWolf focuses on network intelligence and security, connecting workload and process activity with network behavior.

We're working with technologies including eBPF, Cilium, and Hubble to provide deeper infrastructure-level visibility and policy automation.

HyperCluster: Kubernetes lifecycle

HyperCluster focuses on Kubernetes cluster lifecycle automation.

That includes workflows around:

Preflight validation
Deployment
Scaling
Upgrades
Cluster operations
Infrastructure teardown

Running Kubernetes is easy to demonstrate.

Operating it consistently across real environments is much harder.

That's the problem HyperCluster is intended to address.

Aether: Workload portability

Infrastructure teams shouldn't have to redesign an application every time its runtime changes.

Aether explores a portable model for deploying and operating workloads across environments such as:

Kubernetes
KubeVirt
Podman
Bare metal

The broader principle is simple:

Applications should be portable. Infrastructure should remain a choice.

Forge: AI infrastructure

AI is becoming another major infrastructure workload.

Forge focuses on operating enterprise AI and GPU infrastructure, including areas such as:

GPU placement
Utilization
Governance
Cost visibility
Networking
AI infrastructure operations

AI workloads shouldn't require organizations to abandon everything they already know about infrastructure engineering.

Infrastructure should belong to the customer

One principle influences nearly everything we're building at Zyvor:

Infrastructure should belong to the customer, not the infrastructure vendor.

An enterprise should be able to decide where a workload runs according to its own requirements.

That might be:

KVM
Kubernetes
KubeVirt
Private cloud
Public cloud
Bare metal
Edge infrastructure
Hybrid environments

The infrastructure platform should help organizations make those choices.

It shouldn't remove them.

VMware exit is only the beginning

A lot of conversations today start with:

"How do we move away from VMware?"

That's an important question.

But migration is only the first part.

After migration, organizations still need:

Virtual machine lifecycle management
Networking
Observability
Security
Automation
Disaster recovery
Cost visibility
Windows workload support
Kubernetes integration
AI infrastructure management

Moving a VM solves a migration problem.

Operating the next infrastructure platform solves a much larger one.

That's why we're building Zyvor as an infrastructure platform rather than only a VM conversion utility.

Why open infrastructure?

We believe the next generation of enterprise infrastructure will increasingly be built around open technologies such as:

Linux
KVM
Kubernetes
KubeVirt
libvirt
eBPF
Cilium
Containers
Open APIs

These are already powerful building blocks.

The opportunity is making them easier to deploy, integrate, migrate to, and operate as one coherent infrastructure environment.

That's what we're working on at Zyvor AI Labs.

What we'll publish on DEV

This will not just be a product announcement channel.

We'll share technical engineering content covering topics such as:

VMware to KVM migration
Windows VM migration
KubeVirt
Kubernetes infrastructure
KVM and libvirt
eBPF
Cilium and Hubble
Offline VM inspection
Boot troubleshooting
Infrastructure automation
Network intelligence
AI infrastructure
Architecture deep dives
Lessons learned while building HyperSDK

If you're working on virtualization modernization, VMware migration, Kubernetes infrastructure, or open infrastructure, we'd love to hear about the problems you're running into.

What part of the post-VMware infrastructure stack do you think still needs the most work?

Explore Zyvor AI Labs:
https://zyvor.dev

HyperSDK: Open infrastructure for migration, virtualization, Kubernetes, networking, automation, and AI infrastructure.

api-routerd

Susant Sahani — Mon, 24 Dec 2018 21:31:00 +0000

bit.ly/2Rexr4r

systemd-netlogd

Susant Sahani — Tue, 06 Nov 2018 18:49:51 +0000

Ansible systemd

Susant Sahani — Tue, 06 Nov 2018 18:45:58 +0000

DEV Community: Susant Sahani

PacketWolf: Bringing eBPF Network Intelligence to Kubernetes and Virtual Machines

What is PacketWolf?

Kubernetes changed network identity

Cilium and eBPF

From flows to relationships

Service maps

Process-to-network attribution

What about virtual machines?

Why this matters for VM migration

AutoPolicy

Unexpected communication is often the interesting communication

Policy visibility matters too

The broader Zyvor stack

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

What is Zeus OS?

Why KubeVirt?

Kubernetes APIs are powerful — but infrastructure teams need workflows

Virtual machines become declarative infrastructure

VMs and containers under one API

The VMware migration question

VM lifecycle

Storage matters

Windows is critical

Networking becomes interesting

Infrastructure topology

Observability should cross the VM boundary

Policy becomes API-driven

Multi-cluster infrastructure

Kubernetes should not make virtualization harder

What Zeus OS is trying to become

The larger Zyvor architecture

The post-VMware opportunity

VMware to KVM Migration: Why Disk Conversion Is Only the Beginning

A converted disk is not a migrated VM

Problem 1: Storage drivers

Problem 2: initramfs

Problem 3: GRUB and boot paths

Problem 4: /etc/fstab

Problem 5: Windows is different

Problem 6: Networking

This is why we built GuestKit

Fleet migration changes the problem

hyper2kvm handles the migration workflow

Preflight matters

Is the disk readable?

Is the operating system identifiable?

Is the boot configuration understood?

Are target storage drivers available?

Are filesystem mounts safe?

Is the firmware configuration compatible?

Can we verify the resulting guest?

Validation should be explicit

The real migration unit is the guest

Where we're taking this

Introducing Zyvor AI Labs: Building Open Infrastructure for the Post-VMware Era

Meet HyperSDK

hyper2kvm: VMware to KVM migration

GuestKit: Know before you migrate

Zeus OS: Virtual machines on Kubernetes

Machina: KVM operations

PacketWolf: Network intelligence

HyperCluster: Kubernetes lifecycle

Aether: Workload portability

Forge: AI infrastructure

Infrastructure should belong to the customer

VMware exit is only the beginning

Why open infrastructure?

What we'll publish on DEV

api-routerd

systemd-netlogd

Ansible systemd

Problem 4: `/etc/fstab`