Today we are announcing that the HyperSDK platform has grown to eleven products -- a complete infrastructure lifecycle from export through deployment, observation, and optimization.

The Complete Pipeline​

Export and Convert. HyperSDK Platform and hyper2kvm Engine handle the heavy lifting of extracting VMs from vSphere, AWS, Azure, GCP, Hyper-V, and six other providers. hyper2kvm automates guest OS fixing -- VirtIO driver injection, bootloader repair, network reconfiguration -- so every VM boots on the first try. VMCraft adds format conversion across QCOW2, VMDK, VDI, and raw images.

Build and Deploy. VirtCraft provides 44 OS templates and multi-VM blueprints for KubeVirt. Orchestr8 handles deployment across Podman, Kubernetes, KubeVirt, and bare metal from a single manifest.

Manage and Observe. v9s brings the k9s experience to KubeVirt -- terminal UI and web dashboard for full VM lifecycle management. VirtSpawn does the same for libvirt environments. KubeVM Studio layers AI-driven automation and cost optimization on top of Kubernetes VMs. Cilium Flow provides eBPF-based network observability with ML-powered policy automation. VMSpawn rounds out management with 480+ API endpoints for systemd-vmspawn environments, exposed through five interfaces: CLI, TUI, Web UI, Kubernetes Operator, and Terraform Provider.

Inspect and Repair. GuestKit enables offline disk inspection and repair across QCOW2, VMDK, VDI, and more. AI-powered diagnostics identify boot failures, missing drivers, and configuration drift without ever starting the VM.

GPU Compute for AI. KubeFabric is our second new product: an enterprise GPU compute fabric built for AI/ML workloads. NVIDIA-native GPU orchestration with RDMA networking and parallel filesystem support, deployed on bare metal. It replaces the functionality teams currently cobble together from EKS, OpenShift AI, Databricks, and CoreWeave -- fully self-hosted and enterprise-ready.

One Platform, One API​

Every product in the HyperSDK portfolio shares a common design philosophy: enterprise-grade security (RBAC, audit logging, SOC2 readiness), API-first architecture, and deployment flexibility across on-premises, edge, and cloud environments.

The eleven products map to the natural lifecycle of infrastructure operations:

1. Export -- HyperSDK Platform, hyper2kvm Engine
2. Convert -- VMCraft, GuestKit
3. Build -- VirtCraft
4. Deploy -- Orchestr8, VMSpawn
5. Manage -- v9s, VirtSpawn, KubeVM Studio
6. Observe -- Cilium Flow
7. Compute -- KubeFabric

Teams adopt the products they need today and expand as their infrastructure evolves. No rip-and-replace required.

To learn more about KubeFabric, visit KubeFabric, or schedule a demo with our team.

The Market Is Wide Open​

The VMware ecosystem represents over $50 billion in annual spending, and it is in transition. Broadcom's acquisition triggered license increases of 2x to 12x across the customer base. Organizations that were paying $350,000 per year for 500 VMs are now facing $1.2 million annual bills under VMware Cloud Foundation.

These companies need help. They need a partner who understands migration, who has the tooling, and who can execute.

Here is the part that matters most: 60% of VMware channel partners were dropped by Broadcom. The customers those partners served are still running VMware. They still need support. And they are actively looking for a new partner who can help them exit.

The Economics​

The HyperSDK Partner Program is built on a simple model:

• Competitive partner pricing. Contact us for partner-tier pricing on HyperSDK platform access. No per-VM licensing fees.
• 100% service margin. Every dollar of migration services you deliver is yours. We provide the tools. You provide the expertise.
• Year 1 revenue potential: $550,000. Based on a typical partner engaging 5 to 10 mid-market customers in their first year.
• Year 3 revenue potential: $2.8M+. As your practice matures, recurring migration and managed service contracts compound.

This is not a reseller program. You are not marking up software licenses. You are building a professional services practice around the largest infrastructure transition in a decade.

What You Get​

Partners receive full access to the HyperSDK platform, including the export engine, conversion tools, and enterprise dashboard. You also get:

• Technical enablement and certification
• Co-marketing support and lead sharing
• Priority access to engineering for complex migrations
• A dedicated partner success manager

The platform handles the hard parts -- vSphere export, automated VirtIO driver injection, bootloader repair, and guest OS fixing. Your team focuses on customer relationships, project management, and the high-value consulting that commands premium rates.

Who This Is For​

The program is designed for managed service providers, IT consultancies, and systems integrators who serve mid-market and enterprise customers. If your clients run VMware and are facing renewal increases, you already have the relationships. We give you the tools to act on them.

Get Started​

The application process is straightforward. Contact our partnerships team, and we will schedule a 30-minute call to discuss your practice, your customer base, and how we can support your growth.

The market will not stay this wide open forever. The partners who move now will capture the lion's share of a $50B+ transition.

Join the Partner Program -- competitive pricing, maximum opportunity.

What Air-Gap Means in Practice​

An air-gapped network has no connection to the internet or to any untrusted network. This is not the same as a firewall-restricted network where outbound connections are blocked -- air-gap means there is no physical path for data to traverse. These environments are found in SCIFs (Sensitive Compartmented Information Facilities), classified defense networks, certain financial trading floors, and critical infrastructure control systems.

For VM migration, air-gap creates several immediate challenges. There is no access to package repositories (apt, yum, pip) for installing tools or dependencies. There is no access to driver download sites for VirtIO or guest agent packages. There is no access to cloud APIs for authentication or storage. There is no way to pull container images from registries. Every component needed for migration must be pre-staged on portable media and physically carried across the air gap.

How HyperSDK Handles Air-Gap Migration​

HyperSDK's air-gap migration workflow operates in three stages, each designed for complete offline operation.

Stage 1: Offline Export. On the source network (typically a VMware vSphere environment), HyperSDK connects to vCenter using only local network access. VMs are exported to local storage with full manifest tracking. Each exported artifact -- disk image, configuration file, metadata -- receives a SHA-256 checksum. The export manifest records the operator identity, timestamp, source VM identifier, and hash of every file. No outbound network access is required.

Stage 2: Physical Transfer. Exported VM images are transferred to encrypted portable media. HyperSDK generates a chain-of-custody manifest that tracks every file from source to destination. The manifest includes tamper-evident digital signatures so that any modification during physical transport is detectable. Supported media includes encrypted USB drives, removable NVMe drives, and optical media for smaller workloads.

Stage 3: Offline Import. On the destination network, hyper2kvm reads exported images directly from the portable media. All conversion tools, VirtIO drivers, and guest OS fixup scripts are pre-packaged in the hyper2kvm installation -- nothing is downloaded at runtime. Disk images are converted from VMDK to qcow2, VirtIO drivers are injected, bootloaders are repaired, and the VM is deployed to libvirt. The entire process runs without a single DNS lookup.

FIPS and Compliance Considerations​

Air-gapped environments typically operate under strict compliance frameworks. HyperSDK uses FIPS 140-2 compatible cryptographic modules for all hashing and signature operations. Audit logs are structured JSON, suitable for ingestion into SIEM platforms operating on the same air-gapped network. Every operation is logged with sufficient detail to satisfy NIST SP 800-53 audit requirements, including operator identification, action performed, objects affected, and result status.

Real-World Use Cases​

We have deployed HyperSDK in air-gapped environments across several sectors: defense contractors migrating from VMware to KVM on classified networks, government agencies modernizing infrastructure in SCIF environments, energy companies migrating control systems on isolated OT networks, and maritime organizations operating on vessels with no satellite connectivity.

In each case, the key to success was pre-staging. All tools, drivers, and dependencies must be validated and packaged before they cross the air gap. HyperSDK provides a single self-contained package that includes everything needed for the complete migration pipeline. If your organization operates in a disconnected environment and needs to migrate VM workloads, contact our team to discuss your specific requirements.

The Data Center Carbon Problem​

A typical VM export and conversion job runs for 10-30 minutes depending on disk size. During that time, the host machine draws significant power for sustained sequential reads, compression, format conversion, and network transfer. When you are migrating hundreds of VMs in a fleet-wide transition away from vSphere, the cumulative energy consumption is substantial.

The carbon intensity of that energy depends entirely on when and where you consume it. A kilowatt-hour of electricity at 2 AM in Norway (dominated by hydropower) produces a fraction of the CO2 compared to the same kilowatt-hour at 5 PM in Poland (dominated by coal). By shifting migration jobs to low-carbon windows, you can dramatically reduce your environmental impact with zero changes to the migration itself.

ElectricityMap Integration​

HyperSDK integrates with ElectricityMap, the leading provider of real-time carbon intensity data for electrical grids worldwide. The integration covers 12 global grid zones spanning North America, Europe, and Asia-Pacific. For each zone, HyperSDK receives real-time carbon intensity measurements in grams of CO2 equivalent per kilowatt-hour (gCO2eq/kWh), along with 24-hour forecasts.

The 12 supported grid zones are:

• North America: US-CAL (California), US-TEX (Texas), US-NY (New York), CA-ON (Ontario)
• Europe: DE (Germany), FR (France), GB (Great Britain), NO (Norway), PL (Poland)
• Asia-Pacific: JP-TK (Tokyo), AU-NSW (New South Wales), IN-DL (Delhi)

How It Works​

When you submit a migration job with carbon-aware scheduling enabled, HyperSDK queries the ElectricityMap API for the current carbon intensity and the 24-hour forecast for your grid zone. If the current intensity is below your configured threshold, the job starts immediately. If not, the scheduler holds the job and monitors the forecast, releasing it during the next predicted low-carbon window.

You can configure the carbon threshold per job or set a global default. The scheduler respects your maximum delay tolerance -- if you set a 12-hour window, the job will run within 12 hours regardless of grid conditions, ensuring migrations complete on time even during high-carbon periods.

The scheduling logic runs in the ScheduleManager port interface, which means it works with any job type -- single VM exports, batch migrations, backup jobs, or any custom workflow you build on the API.

Measured Impact: 30-50% CO2 Reduction​

In testing across multiple grid zones, carbon-aware scheduling reduced migration-related CO2 emissions by 30-50% compared to immediate execution. The savings vary by region -- grids with high renewable penetration like France and Norway see smaller absolute reductions (because the baseline is already clean), while coal-heavy grids like Poland and parts of the US see the largest improvements.

The Numbers: 100 VMs, 262 kg CO2, 13 Trees​

Here is a concrete example. Migrating 100 VMs with an average disk size of 50 GB each:

• Total energy consumption: approximately 85 kWh (including disk I/O, conversion, and transfer)
• Without carbon scheduling (US average grid, 400 gCO2eq/kWh): 34 kg CO2
• With carbon scheduling (shifting to low-carbon windows): 14.6 kg CO2
• Annual savings (assuming quarterly migration batches): 262 kg CO2 per year
• Equivalent: planting 13 trees per year

For organizations running thousands of VMs, these numbers scale linearly. A 1,000-VM migration saves over 2.6 metric tons of CO2 annually -- equivalent to taking a car off the road.

ESG Compliance Reporting​

HyperSDK tracks carbon metrics for every migration job and aggregates them into reports suitable for ESG (Environmental, Social, and Governance) compliance. The carbon dashboard in the web interface shows cumulative emissions, emissions avoided through scheduling, and per-job breakdowns. You can export these reports as CSV or JSON for integration with your organization's sustainability reporting tools.

API Endpoints for Carbon Status​

The carbon tracking system is fully accessible through the REST API:

• GET /api/v1/carbon/status -- current grid carbon intensity for your configured zone
• GET /api/v1/carbon/forecast -- 24-hour carbon intensity forecast
• GET /api/v1/carbon/report -- aggregated carbon savings report
• GET /api/v1/carbon/zones -- list of supported grid zones
• POST /api/v1/jobs with carbon_aware: true -- submit a carbon-aware job

Carbon-aware scheduling is optional and off by default. Enable it by setting carbon.enabled: true in your configuration file and providing an ElectricityMap API key. Once enabled, every migration job can opt in to carbon-aware scheduling individually or you can set it as the default for all jobs.

How GPU Passthrough Works on KVM​

GPU passthrough on KVM uses the VFIO (Virtual Function I/O) framework to assign a physical PCI device directly to a virtual machine. The guest VM gets exclusive access to the GPU hardware, bypassing the hypervisor for all GPU operations. This is fundamentally the same approach used by VMware's DirectPath I/O, but with the advantage of being built into the Linux kernel rather than requiring a proprietary hypervisor.

The process involves four steps. First, IOMMU (Intel VT-d or AMD-Vi) must be enabled in the host BIOS and kernel parameters. IOMMU provides the memory isolation that allows a PCI device to be safely assigned to a VM. Second, the GPU must be unbound from the host graphics driver (nouveau or nvidia) and bound to the VFIO-PCI driver. This tells the kernel that the GPU is reserved for VM passthrough. Third, the GPU is assigned to a VM via libvirt XML configuration, specifying the PCI bus, slot, and function addresses. Fourth, NVIDIA drivers are installed inside the guest VM, which then sees the GPU as if it were physically installed.

Performance: Near-Native Results​

We have benchmarked GPU passthrough on KVM against bare-metal across multiple workloads and GPU models. The results are consistently within 2% of bare-metal performance for compute workloads.

On an NVIDIA A100 80GB running PyTorch ResNet-50 training, KVM with VFIO passthrough delivered 98.3% of bare-metal throughput. CUDA memory bandwidth tests showed 99.1% of native performance. For inference workloads using TensorRT on an NVIDIA T4, latency was within 1% of bare-metal at all batch sizes.

The negligible overhead comes from the IOMMU address translation layer, which adds a small fixed cost to DMA operations. For GPU-bound workloads where the vast majority of time is spent on GPU compute, this overhead is effectively invisible.

vGPU for Multi-Tenant Scenarios​

For environments that need multiple VMs to share a single physical GPU -- common in VDI and inference serving -- NVIDIA vGPU provides time-sliced or MIG (Multi-Instance GPU) partitioning. Each VM receives a guaranteed allocation of GPU memory and compute resources.

HyperSDK supports vGPU configuration for NVIDIA GPUs that support it (A100, A30, H100 with MIG; Tesla T4, L40S with time-slicing). The hyper2kvm conversion engine can pre-configure VMs for vGPU profiles during migration, so GPU-accelerated workloads are ready to run immediately after deployment on KVM.

Migrating GPU Workloads from VMware​

When migrating GPU-accelerated VMs from vSphere to KVM, the GPU assignment changes from VMware's DirectPath I/O to KVM's VFIO passthrough. The guest-side NVIDIA drivers remain the same -- a Windows or Linux VM running CUDA workloads needs only the standard NVIDIA driver package, regardless of whether the underlying hypervisor is ESXi or KVM.

HyperSDK handles the infrastructure side automatically. During export from vSphere, the VM's GPU configuration is captured in the migration manifest. During deployment on KVM, HyperSDK generates the correct libvirt XML with VFIO hostdev entries, verifies IOMMU group isolation, and configures the necessary kernel module parameters. For organizations running AI/ML workloads on VMware, the migration to KVM preserves full GPU performance while eliminating VMware licensing costs.

If your organization runs GPU-accelerated workloads on VMware and is evaluating a KVM migration, talk to our team about GPU passthrough configuration and performance validation.

The Problem with Large Uploads​

Standard HTML file uploads use a single multipart/form-data request. This works for megabyte-sized files but breaks down at scale. Most reverse proxies have request body limits (often 10-100 MB). Browser memory usage spikes when loading a multi-gigabyte file into an ArrayBuffer. Network drops at 80% completion mean starting over from zero. And there is no way to show granular progress -- the browser either knows the request is in-flight or it does not.

We needed an approach that works reliably for files up to 50 GB, provides real-time progress feedback, and recovers gracefully from network failures.

Protocol Design​

Our chunked upload protocol uses four API endpoints:

1. POST /upload/init -- Initialize a session. The client sends the filename, total size, and preferred chunk size. The server allocates an upload ID and returns the total chunk count.

2. POST /upload/{id}/chunk/{n} -- Upload a single chunk. The body is raw bytes (application/octet-stream). The server writes the chunk to a temporary file and records it as received.

3. GET /upload/{id}/status -- Query progress. Returns the count of received chunks, bytes received, and overall percentage. This is the key endpoint for resume -- the client checks which chunks are missing and picks up where it left off.

4. POST /upload/{id}/complete -- Finalize the upload. The server reassembles all chunks into the final file, computes a SHA-256 checksum, and returns the file path.

Each chunk upload is idempotent. If the same chunk is uploaded twice (e.g., after a retry where the server received it but the client did not get the acknowledgment), the server simply overwrites the existing chunk data. This eliminates an entire class of duplication bugs.

Client-Side Implementation​

On the browser side, we use the File API's Blob.slice() method to split the file into chunks without loading the entire file into memory. For a 50 GB file with 10 MB chunks, we create 5,000 slice references without allocating any additional memory -- the browser reads each slice from disk on demand.

const CHUNK_SIZE = 10 * 1024 * 1024; // 10 MB
const totalChunks = Math.ceil(file.size / CHUNK_SIZE);

for (let i = 0; i < totalChunks; i++) {
  const start = i * CHUNK_SIZE;
  const end = Math.min(start + CHUNK_SIZE, file.size);
  const chunk = file.slice(start, end);

  await uploadChunk(uploadId, i, chunk);
  onProgress((i + 1) / totalChunks * 100);
}

Each chunk is uploaded using XMLHttpRequest rather than fetch(). The reason is XHR's upload.onprogress event, which fires during the request body transmission and provides bytes-sent granularity. With fetch(), you only know when the response arrives -- for a 10 MB chunk on a slow connection, that could be 30 seconds of silence. XHR gives us a smooth progress bar even within a single chunk.

Resume on Network Failure​

When the network drops mid-upload, the React component catches the XHR error and enters a retry state. Before retrying the failed chunk, it queries the status endpoint to confirm the server's view of progress. This handles the case where the chunk was actually received but the response was lost.

The status response includes the count of received chunks. The client computes the set of missing chunks (which may not be contiguous if earlier retries partially succeeded) and uploads only those. In practice, since we upload sequentially, the missing chunks are always a contiguous range from the last received chunk to the end.

The dashboard UI shows the retry state clearly: a yellow progress bar with a "Resuming..." label and the count of remaining chunks. The user can also manually trigger a resume if they closed and reopened the tab -- the upload ID is persisted in localStorage, and the component checks for incomplete uploads on mount.

Server-Side Handling​

On the server side, each upload session creates a temporary directory with one file per chunk, named by index (e.g., chunk_0000, chunk_0001). The session metadata (filename, total size, expected chunk count, received chunks) is stored in memory and periodically flushed to a JSON file in the temporary directory.

When the client calls the complete endpoint, the server opens the final output file and copies each chunk file in order using io.Copy. After reassembly, it computes the SHA-256 checksum of the final file and compares it to the expected size. If everything checks out, the temporary directory is removed and the upload is marked as ready.

We chose sequential chunk files over a single sparse file because it is simpler to reason about, works on any filesystem, and makes the status endpoint trivial to implement -- just count the files in the directory.

Progress Tracking with CallbackProgressReader​

HyperSDK's pkg/ioutil package provides a CallbackProgressReader that wraps an io.Reader and invokes a callback function on every read. We use this throughout the codebase for tracking progress on both uploads and exports. On the upload path, it feeds the dashboard's progress bar. On the export path, it drives the job progress percentage that appears in the Jobs Table view.

The callback receives the number of bytes read so far and the total expected bytes. The dashboard component uses this to compute transfer rate (bytes per second), estimated time remaining, and a percentage for the progress bar. All of this updates in real time as chunks flow through the reader.

What We Would Do Differently​

If we were starting over, we would add parallel chunk uploads. Currently, chunks are uploaded sequentially because it simplifies the server-side reassembly and avoids complications with upload ordering. But for high-bandwidth connections, uploading 3-4 chunks in parallel would significantly reduce total upload time for large files. The protocol already supports it -- chunks can arrive in any order since they are written to separate files -- but the client currently does not take advantage of this.

We would also add server-side resumability across daemon restarts. Currently, the in-memory session state is lost when the daemon restarts. The chunk files survive on disk, but the metadata needs to be reconstructed. Adding a simple JSON metadata file (which we partially do for crash recovery) and a scan-on-startup routine would make the upload truly durable.

Even without these improvements, the current implementation handles the common case well: upload large files through the browser with progress feedback and automatic recovery from transient network failures.

Collecting Metrics from /proc and /sys​

Linux exposes virtually everything about system state through its pseudo-filesystems. CPU utilization comes from /proc/stat, memory from /proc/meminfo, disk I/O from /proc/diskstats, and network throughput from /proc/net/dev. We parse these files at a configurable interval (default 15 seconds) and compute derived metrics like CPU percentage, memory pressure, and I/O wait.

The key insight is that most /proc files report cumulative counters, not instantaneous values. CPU times in /proc/stat are monotonically increasing tick counts. To compute utilization percentage, you need two readings and some arithmetic: usage = (active_delta / total_delta) * 100. We store the previous reading in memory and compute deltas on each collection cycle. The same pattern applies to disk I/O (sectors read/written) and network (bytes received/transmitted).

One subtlety we discovered early: /proc/meminfo reports MemAvailable on modern kernels (3.14+), which is a much better indicator of actual available memory than MemFree. The latter ignores buffers, caches, and reclaimable slab memory that the kernel will happily give back under pressure. We use MemAvailable when present and fall back to MemFree + Buffers + Cached on older kernels.

For per-process metrics, we read /proc/[pid]/stat and /proc/[pid]/status for each process. This gives us per-process CPU time, resident set size, virtual memory size, and thread count. We sort by CPU and memory usage and expose the top N processes through the API and dashboard.

The Health Score Algorithm​

Raw metrics are useful for monitoring tools, but operators want a quick answer: is this system healthy? We distill all collected metrics into a single health score from 0 to 100.

The algorithm applies weighted penalties for resource exhaustion. Each resource category (CPU, memory, disk, network) has a threshold and a penalty function. If CPU usage exceeds 90%, the penalty is proportional to how far above the threshold it is. If disk usage exceeds 90%, the penalty is higher because disk exhaustion is harder to recover from.

The formula is straightforward: start at 100, subtract penalties. A system running at 95% CPU, 60% memory, 40% disk, and normal network gets a penalty of roughly 10 points for CPU, resulting in a score of 90. A system at 95% CPU and 92% disk gets penalties from both, dropping to around 70. The score naturally reflects the severity and breadth of resource pressure.

We also track which resources are bottlenecks and expose them in the API response. When the health score drops, the operator immediately knows whether the problem is CPU, memory, disk, or network without digging into charts.

Explain Mode: Why Is CPU High?​

The most interesting feature we built is the explain mode. Instead of just showing that CPU is at 95%, explain mode answers why. It identifies the top contributing processes, correlates them with known patterns (e.g., "qemu-img process suggests a disk conversion is running"), and generates actionable recommendations.

The explain engine works in three stages. First, it collects current and recent metrics. Second, it ranks contributing factors by impact -- for CPU, this means listing processes sorted by CPU usage with context about what they are doing. Third, it applies a rules engine that matches patterns and generates recommendations. If the top CPU consumer is a qemu-img process, the recommendation might be to schedule disk conversions during off-peak hours or to use carbon-aware scheduling to shift the workload.

Explain mode is available for CPU, memory, disk, and network, each with its own set of patterns and recommendations. The rules are implemented as a simple Go slice of rule structs with match functions and response templates. Adding new rules is a matter of adding a struct to the slice.

Time-Series Storage: The Ring Buffer​

We store 24 hours of metric history in a ring buffer. The implementation is a fixed-size slice with a write pointer that wraps around. Each data point is a timestamp-value pair. With a 15-second collection interval, we store approximately 5,760 points per metric per day, consuming roughly 92 KB per metric (16 bytes per point).

The ring buffer has several advantages over a database. It requires no external dependencies, has O(1) insert and O(n) scan performance, naturally evicts old data without cleanup jobs, and uses a fixed, predictable amount of memory. For a system that stores 10 metrics, the total memory footprint is under 1 MB.

Time-series queries support a step parameter for downsampling. When querying with step=5m, the API averages all data points within each 5-minute window and returns one point per window. This keeps response sizes manageable when graphing 24 hours of data in the dashboard.

Smart Alerts​

The alert engine evaluates rules against collected metrics on each collection cycle. Default rules cover common failure modes: CPU above 90% for 2 minutes, memory above 85%, disk above 90%, swap above 50%, and OOM kills. Each alert has a severity (info, warning, critical) and a suppression window to prevent duplicate alerts from flooding the notification system.

Alerts are delivered through two channels: the REST API (polled by the dashboard) and webhooks (pushed to external systems). Webhook delivery is resilient to transient failures with exponential backoff retry. The webhook payload includes the alert details, current metric values, and a link to the explain mode endpoint for the affected resource.

Lessons Learned​

Building observability from scratch taught us several things. First, /proc parsing is cheap -- reading and parsing all system metrics takes under a millisecond on modern hardware. There is no reason to rely on external agents for basic system metrics. Second, a ring buffer is an excellent data structure for bounded time-series storage when you do not need persistence across restarts. Third, the explain mode concept -- turning raw metrics into structured diagnostics with recommendations -- is far more useful to operators than raw dashboards. It eliminates the step where someone has to look at five charts and reason about what they mean together.

The observability layer now serves as the foundation for carbon-aware scheduling (which needs to know current system load), the health check endpoint (which powers the dashboard home page), and the alert system (which drives webhook notifications). Building it self-contained means the entire stack deploys as a single binary with zero runtime dependencies.

Five Navigation Groups​

The dashboard organizes its 46 views into five top-level navigation groups. Each group maps to a distinct phase or concern in the migration workflow, so you always know where to find what you need.

Migration Views (20 views)​

The Migration group is the largest, with 20 views dedicated to the core workflow of moving VMs between providers. The VM browser displays all discovered virtual machines with OS-specific icons -- Windows, Linux distributions, BSD variants -- so you can visually identify workloads at a glance. Each VM row shows CPU, memory, disk size, and provider-specific metadata.

From the VM browser you can trigger single-click exports. The export workflow view guides you through selecting a target format (qcow2, VMDK, raw, VHD), choosing a destination provider, and configuring conversion options. For vSphere sources, a dedicated VSphere Export Workflow view handles vCenter authentication, datacenter selection, and datastore browsing.

Upload and download views let you push disk images directly through the browser or pull exported artifacts to your local machine. A readiness check view scans source VMs for compatibility issues -- unsupported disk controllers, snapshots that need consolidation, or guest tools that should be removed before migration.

The jobs table shows all active, queued, completed, and failed migration jobs with real-time progress bars, elapsed time, and estimated completion. You can filter by provider, status, or date range, and drill into any job for detailed logs.

Observability Views (8 views)​

The Observability group provides system-wide visibility into HyperSDK's health and performance. The health score view displays a single 0-100 number that aggregates metrics from all connected providers, storage backends, and internal services. When the score drops, color-coded indicators show which component is degraded.

The explain mode view is one of the most powerful debugging tools in the dashboard. Select any failed or degraded component and the explain view walks you through the root cause using structured diagnostic data. Instead of dumping raw logs, it presents a chain of causation: which API call failed, what the provider returned, and what you can do to fix it.

Additional observability views include an alerts list with configurable severity thresholds, a metrics dashboard with time-series charts for throughput and latency, a provider status matrix showing connectivity to all 10 supported providers, and debug tools for inspecting internal state.

Infrastructure Views (4 views)​

The Infrastructure group covers resources that exist outside the migration workflow but are essential to it. The snapshots view lets you manage VM snapshots across providers -- create, delete, revert, and compare. The storage view shows disk utilization across all configured storage backends with capacity forecasting.

The ISO manager view handles boot media for target VMs, letting you upload, catalog, and attach ISO images. The VM create view provides a form-driven interface for provisioning new virtual machines on any supported provider, useful for testing migration targets before committing to a full cutover.

Tools Views (11 views)​

The Tools group contains utility views that support the migration process. The cost estimator lets you compare running costs across providers before migrating -- enter your VM specifications and see monthly estimates for AWS, Azure, GCP, OCI, and others side by side.

The backup scheduler view lets you configure recurring backup jobs with cron-like scheduling. The manifest builder provides a visual editor for creating migration manifests that describe multi-VM migration plans as structured YAML. The API playground is a built-in HTTP client that lets you test any of the 205 API endpoints directly from the browser with auto-populated authentication headers.

Additional tools include a carbon emissions tracker, a webhook manager for configuring notification endpoints, an audit log viewer, a secrets manager for storing provider credentials securely, and an RBAC configuration view for managing user roles and permissions.

System Views (2 views)​

The System group includes the login view with session management and a settings view for configuring global preferences like theme, default provider, and notification channels.

Keyboard Shortcuts and Theming​

Every major action in the dashboard has a keyboard shortcut. Press ? to see the full shortcut reference. Common shortcuts include n for new migration, j/k for navigating lists, Enter to drill into details, and Escape to go back.

The dashboard supports both dark and light themes with a toggle in the top navigation bar. Theme preference is persisted in local storage and respects the operating system's color scheme preference on first visit.

Built with React 18 and Tailwind CSS​

The dashboard is built with React 18, using functional components and hooks throughout. Styling is handled entirely by Tailwind CSS utility classes, which keeps the design consistent and makes customization straightforward. The chart components use a dedicated ChartContainer wrapper that handles responsive sizing and loading states. State management uses React's built-in context and reducer patterns -- no external state library is required.

The entire dashboard builds to a single static bundle that is embedded in the HyperSDK binary, so there is no separate frontend server to deploy. Just start the daemon and open your browser.

The libguestfs Problem​

libguestfs works by booting a lightweight virtual machine (the "appliance") every time you need to access a disk image. This appliance contains a Linux kernel, a minimal userspace, and filesystem drivers. Your application communicates with the appliance over a socket, sending commands to read files, write data, or modify configurations inside the disk image.

This architecture has three fundamental problems that became deal-breakers for hyper2kvm.

Startup latency. Every time you open a disk image, libguestfs boots the appliance. This takes 15-30 seconds depending on hardware. For a migration pipeline that processes hundreds of VMs, this adds hours of idle waiting. We measured 22 seconds average appliance boot time on our reference hardware -- multiplied by 200 VMs, that is 73 minutes spent doing nothing but waiting for appliances to start.

Memory consumption. The appliance requires 512 MB or more of memory per instance. Running parallel conversions -- essential for large-scale migrations -- means allocating gigabytes of memory just for the disk manipulation layer, before you account for the actual conversion work.

Deployment complexity. The appliance depends on supermin, a specific kernel version, and /dev/kvm access on the host. In containerized deployments, this means running privileged containers with device access -- a non-starter for many enterprise security policies. In air-gapped environments, pre-staging the appliance kernel and initrd adds another layer of complexity to an already constrained deployment process.

The VMCraft Architecture​

VMCraft replaces the appliance with direct block device access. The architecture is simple: Python application code calls VMCraft APIs, which use qemu-nbd to expose the disk image as a block device, then parse filesystem structures (ext4, NTFS, XFS, FAT32) directly in Python.

This sounds like it should be slower -- Python parsing filesystem metadata instead of a native kernel driver. In practice, it is dramatically faster for the operations that matter in a migration pipeline, because there is no 22-second appliance boot. VMCraft opens a disk image in under one second.

For bulk operations (read a registry key, inject a driver file, modify fstab), the per-operation overhead of Python parsing versus kernel drivers is negligible compared to the I/O time. The bottleneck is always disk I/O, not CPU time spent parsing superblock structures.

480+ API Functions​

VMCraft provides 480+ functions organized across six categories that cover every operation needed for VM migration.

Disk image operations handle format support (QCOW2, VMDK, VHD, VHDX, RAW), partition table parsing (MBR and GPT), and image manipulation (resize, compact, convert, snapshot).

Filesystem access provides read/write access to ext2/3/4, XFS, NTFS, and FAT32 filesystems. You can list directories, copy files in and out, modify permissions, and create or delete entries -- all without mounting the filesystem on the host.

Windows-specific operations include full Windows registry hive read/write, VirtIO driver injection into the driver store, BCD (Boot Configuration Data) editing for bootloader repair, service configuration, and Sysprep/unattend.xml generation.

Linux-specific operations cover fstab modification, GRUB and systemd-boot configuration, kernel module injection, network configuration across NetworkManager and systemd-networkd, and cloud-init seed injection.

Guest OS detection automatically identifies the operating system type, version, installed applications, hardware drivers, network configuration, and boot method (BIOS vs. UEFI) -- critical metadata for migration planning.

Security and integrity functions provide SHA-256 checksum generation and verification, disk image encryption, secure wipe of free space, and certificate injection.

Performance Numbers​

We benchmarked VMCraft against libguestfs across the operations most common in our migration pipeline.

Opening a disk image and reading a single file: libguestfs averaged 23.4 seconds (dominated by appliance boot), VMCraft averaged 0.8 seconds -- a 29x improvement. Injecting VirtIO drivers into a Windows VM: libguestfs took 31.2 seconds, VMCraft took 4.6 seconds -- 6.8x faster. Modifying fstab and GRUB configuration in a Linux VM: libguestfs took 24.1 seconds, VMCraft took 3.2 seconds -- 7.5x faster.

For batch processing of 200 VMs (the common enterprise migration scenario), the cumulative time savings exceeded 90 minutes. More importantly, VMCraft's lower memory footprint (under 50 MB versus 512 MB+) allows running more parallel conversions on the same hardware, further reducing total migration time.

Container-Friendly by Design​

VMCraft runs inside standard containers without /dev/kvm, without privileged mode, and without device access. The only requirement is qemu-nbd, which operates as a regular userspace process. This makes VMCraft compatible with Kubernetes pods, rootless Podman containers, and CI/CD pipeline runners -- environments where libguestfs appliance boot is typically impossible or requires security exceptions.

For organizations evaluating hyper2kvm for VM migration, VMCraft's container-friendly architecture means the conversion pipeline can run anywhere your container orchestrator runs, without special host configuration. Schedule a demo to see VMCraft's 480+ APIs in action.

Phase 1: Pre-Migration Assessment​

Before touching a single VM, your team needs a complete picture of what you are working with and where you are going.

Inventory and Discovery

• Generate a complete VM inventory from vCenter, Hyper-V Manager, or your current hypervisor management tool
• Document each VM's resource allocation: vCPUs, memory, disk size, and network configuration
• Identify OS versions and editions for every VM (Windows Server 2016/2019/2022, RHEL 7/8/9, Ubuntu 20.04/22.04, etc.)
• Map network dependencies: VLANs, static IPs, DNS entries, firewall rules, and load balancer configurations
• Identify storage dependencies: shared storage, NFS mounts, iSCSI targets, and local disk layouts
• Catalog installed applications and their licensing requirements on the target platform
• Flag VMs with hardware dependencies: USB passthrough, GPU passthrough, SR-IOV, or TPM requirements

Risk Classification

• Classify each VM by criticality: Tier 1 (mission-critical), Tier 2 (important), Tier 3 (non-critical)
• Identify VMs that require zero-downtime migration vs. those that can tolerate a maintenance window
• Document compliance requirements: HIPAA, PCI-DSS, SOX, FedRAMP, or internal security policies
• Establish rollback criteria: what conditions trigger a rollback, and what is the rollback procedure

Target Environment Preparation

• Provision target hypervisor infrastructure (KVM hosts, Proxmox cluster, or cloud accounts)
• Configure networking on target: bridges, VLANs, DNS, and DHCP
• Set up shared storage if required: Ceph, NFS, or local ZFS pools
• Install and configure HyperSDK on a management node with API access to both source and target environments
• Verify connectivity between source hypervisor, HyperSDK management node, and target infrastructure
• Configure backup strategy for the target environment before migration begins

Phase 2: Pilot Migration​

Never go straight to production. A pilot migration with non-critical VMs validates your process and surfaces issues early.

Pilot Execution

• Select 5-10 Tier 3 VMs representing your most common OS and application configurations
• Run a test export using HyperSDK to verify connectivity and credential configuration
• Export and convert each pilot VM, documenting the time required per VM and any errors encountered
• Verify disk image integrity using SHA-256 checksums from the export manifest
• Deploy pilot VMs to the target environment and verify first-boot success
• Test application functionality on each migrated VM: services running, network connectivity, data integrity
• Measure performance baselines: CPU utilization, memory usage, disk I/O, and network throughput
• Compare performance baselines against pre-migration measurements

Pilot Review

• Document any VMs that required manual intervention after migration
• Identify OS-specific issues: driver installation, bootloader configuration, or service startup failures
• Calculate actual migration throughput (GB/hour) to estimate production migration timelines
• Update the migration plan based on pilot findings
• Obtain stakeholder sign-off on pilot results before proceeding to production migration

Phase 3: Production Migration​

With pilot results validated, execute the production migration in planned waves.

Wave Planning

• Group VMs into migration waves based on application dependencies and criticality
• Schedule each wave during approved maintenance windows
• Notify application owners and support teams of migration schedules
• Ensure rollback resources are available: source VMs remain running until target validation is complete

Migration Execution

• Execute pre-migration VM snapshots on the source hypervisor as a safety net
• Run HyperSDK export jobs for each wave, monitoring progress through the dashboard
• Verify export manifests: disk checksums, metadata integrity, and conversion status
• Deploy converted VMs to target infrastructure
• Validate first-boot success for each VM (HyperSDK reports this automatically)
• Run application-level health checks immediately after deployment
• Update DNS records, load balancer configurations, and monitoring systems to point to migrated VMs
• Verify backup jobs are running on the target environment for each migrated VM

Phase 4: Post-Migration Validation​

The migration is not complete until everything is verified and documented.

Validation Checklist

• Confirm all VMs are running and accessible on the target platform
• Verify application functionality with end-users or application owners
• Compare performance metrics against pre-migration baselines
• Confirm backup and disaster recovery procedures are operational on the target
• Validate monitoring and alerting: all migrated VMs are visible in your monitoring system
• Update CMDB and asset management records with new infrastructure details
• Verify compliance controls: audit logging, access controls, and encryption are configured on the target

Cleanup

• Retain source VM snapshots for a defined rollback period (typically 7-30 days)
• Decommission source VMs after the rollback window expires
• Revoke source hypervisor credentials from HyperSDK once migration is finalized
• Generate a final migration report: VMs migrated, success rate, time elapsed, and cost savings
• Conduct a retrospective with the migration team to document lessons learned

Timeline Guidance​

Based on production migrations using HyperSDK:

The single most important factor in migration success is thorough pre-migration assessment. Invest the time upfront, and the execution phases will run predictably.

Prerequisites​

Before you begin, make sure you have:

• HyperSDK installed and the hypervisord daemon running (see the installation guide)
• vCenter Server credentials with at least read-only access to the VMs you want to migrate
• libvirt and qemu-kvm installed on the target host
• Sufficient disk space for the exported qcow2 image (roughly the same size as the source VMDK)

Step 1: Configure vCenter Connection​

Edit your HyperSDK configuration file at /etc/hypersdk/config.yaml (or ~/.config/hypersdk/config.yaml for user-level configuration) and add your vCenter credentials:

providers:
  vsphere:
    enabled: true
    endpoint: "vcenter.example.com"
    username: "administrator@vsphere.local"
    password: "your-password"
    datacenter: "DC1"
    insecure: false

  kvm:
    enabled: true
    connection: "qemu:///system"
    storage_pool: "default"

After saving the file, restart the daemon:

sudo systemctl restart hypervisord

HyperSDK will validate the connection to vCenter on startup and report any issues in the system log.

Step 2: Browse VMs in the Dashboard​

Open your browser and navigate to http://localhost:8080/web/dashboard/. Log in with your configured credentials and navigate to Migration > VMs in the left sidebar.

The VM browser displays all virtual machines discovered from your vCenter. Each VM is shown with its operating system icon (Windows, Ubuntu, CentOS, Debian, and others are all recognized automatically), along with CPU count, memory allocation, total disk size, and power state. You can filter by name, OS type, or power state using the search bar at the top.

Find the VM you want to migrate and verify its details. HyperSDK shows a readiness indicator for each VM -- a green checkmark means the VM is ready for export, while a yellow warning indicates potential issues like active snapshots that should be consolidated first.

Step 3: Export the VM​

Click the Export button next to your chosen VM. The export dialog opens with the following options:

• Target format: Select qcow2 for KVM (this is the default)
• Compression: Enable to reduce transfer size (recommended for network transfers)
• Destination: Choose local to save to the HyperSDK server, or select a configured target provider

Click Start Export to begin. HyperSDK connects to vCenter, creates a temporary snapshot (if the VM is running), streams the disk data, and converts from VMDK to qcow2 format in a single pass. The original VM is not modified or powered off during this process.

Step 4: Monitor Progress​

Navigate to Migration > Jobs in the sidebar to watch the export progress. The jobs table shows:

• Progress bar with percentage complete
• Transfer speed in MB/s
• Elapsed time and estimated time remaining
• Current phase (snapshot, stream, convert, finalize)

For a 50 GB VM on a gigabit network, expect the export to complete in 3-4 minutes. The progress updates in real time through the dashboard's WebSocket connection -- no need to refresh the page.

If anything goes wrong, click on the job row to see detailed logs. The explain mode (available under Observability > Explain) can diagnose common issues like network timeouts, permission errors, or storage space problems.

Step 5: Download the Converted Image​

Once the job completes, navigate to Migration > Downloads. Your converted qcow2 file is listed with its size, checksum, and creation timestamp. Click Download to transfer it to your local machine, or note the server-side path if your KVM host is the same machine running HyperSDK.

The exported file includes a manifest (export-manifest.json) with metadata about the source VM: original disk layout, network configuration, boot firmware (BIOS or UEFI), and any guest customization that was applied.

Step 6: Deploy to libvirt​

On your KVM host, use virt-install to create a new VM from the exported qcow2 image:

virt-install \
  --name my-migrated-vm \
  --memory 4096 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/exported-vm.qcow2,format=qcow2 \
  --import \
  --os-variant ubuntu22.04 \
  --network bridge=br0 \
  --noautoconsole

The --import flag tells virt-install to skip installation and boot directly from the existing disk image. Adjust the --os-variant, --memory, and --vcpus values to match your source VM's configuration (these are listed in the export manifest).

The VM should boot successfully on the first attempt. Linux VMs generally require no additional changes. The kernel detects the new virtio hardware and loads the appropriate drivers automatically.

Batch Migration for Multiple VMs​

For migrating multiple VMs at once, use the Manifest Builder under Tools > Manifest Builder in the dashboard. Create a migration manifest that lists all the VMs you want to export, their target formats, and any per-VM configuration overrides. Submit the manifest and HyperSDK will process all exports as a batch job, running multiple conversions in parallel up to your configured concurrency limit.

Alternatively, use the CLI for scripted batch migrations:

hyperctl export --provider vsphere --format qcow2 --batch manifest.yaml

The batch job respects dependency ordering, so if you have VMs that must be migrated in a specific sequence (for example, a database server before its application servers), you can define those dependencies in the manifest.

Windows VM Considerations​

Windows VMs require VirtIO drivers to run on KVM. HyperSDK handles this automatically when it detects a Windows guest operating system. During the conversion process, it injects the VirtIO storage and network drivers into the Windows image so the VM can boot without manual driver installation.

The auto-detection works for Windows Server 2016 and later, as well as Windows 10 and 11 desktop editions. For older Windows versions, you may need to install VirtIO drivers manually before or after migration. The dashboard's readiness check view will warn you if a Windows VM requires manual driver intervention.

After booting a migrated Windows VM on KVM, you will need to reactivate the Windows license, as the hardware fingerprint will have changed. This is expected behavior for any hypervisor migration.

The VMware Licensing Problem​

The client operated 200 virtual machines across 12 ESXi hosts running a mix of Windows Server 2019, RHEL 8, and Ubuntu 22.04 workloads. Their VMware stack included vSphere Enterprise Plus, vCenter Server, vSAN, and vRealize Operations -- a common enterprise configuration.

Under the new Broadcom licensing model, several changes hit simultaneously. Per-socket licensing was replaced with per-core subscriptions, dramatically increasing costs for their dual-socket servers. Perpetual licenses were eliminated entirely, forcing a move to annual subscriptions. Products were bundled into suites, requiring purchase of components they did not use. Support tiers were consolidated, removing the option for lower-cost support plans.

The combined effect was a renewal quote of $122,000 per year -- a 320% increase that the IT budget simply could not absorb.

The Migration Approach​

We designed a 10-week migration plan using three tools in sequence: HyperSDK for VM export from vSphere, hyper2kvm for disk conversion and guest OS preparation, and libvirt for deployment on KVM hosts.

Week 1-2: Assessment. HyperSDK connected to the client's vCenter Server and cataloged all 200 VMs, mapping CPU, memory, disk, and network configurations. We identified 15 VMs with VMware-specific dependencies (VMware Tools custom scripts, vSphere API integrations) that required additional preparation. Dependency mapping revealed that 80% of VMs could be migrated independently.

Week 3-4: Pilot. We selected 10 non-critical VMs spanning Windows Server, RHEL, and Ubuntu for pilot migration. Each VM was exported from vSphere using HyperSDK's manifest-tracked export, converted from VMDK to qcow2 with automatic VirtIO driver injection via hyper2kvm, and deployed on KVM hosts running libvirt. All 10 VMs booted successfully on first attempt. Application owners validated functionality within 48 hours.

Week 5-8: Production Migration. We migrated the remaining 190 VMs in four waves of approximately 50 VMs each. Changed Block Tracking (CBT) enabled incremental exports for VMs that could not tolerate extended downtime -- the final sync required transferring only the delta, reducing cutover windows to under 15 minutes per VM. Source VMs remained running on vSphere during validation.

Week 9-10: Validation and Decommission. Performance benchmarks confirmed that migrated VMs matched or exceeded their vSphere baseline. Backup and recovery procedures were tested end-to-end. After sign-off from all application owners, the vSphere infrastructure was decommissioned and licenses were not renewed.

Cost Before and After​

The annual cost comparison tells the story clearly. VMware licensing, support, and management tools totaled $122,000 per year. The equivalent KVM infrastructure -- including RHEL subscriptions for host OS, basic monitoring, and the HyperSDK migration license -- came to $8,800 per year. That is a $113,200 annual savings, or 93% reduction.

Over a three-year horizon, the savings exceed $339,000. The one-time migration cost (engineering time and HyperSDK licensing) was recovered within the first 6 weeks of operation.

Lessons Learned​

Three lessons stood out from this engagement. First, start with a thorough VM inventory -- we discovered 23 VMs that were powered off and had not been used in over a year. These were decommissioned rather than migrated, saving additional storage costs. Second, VirtIO driver injection is critical for Windows VMs. Without the correct storage and network drivers, Windows VMs will not boot on KVM. hyper2kvm handles this automatically, but it must be verified during the pilot phase. Third, keep source VMs running during validation. The ability to fall back to vSphere if any issue arose gave application owners confidence in the migration process.

The VMware exit is not just possible -- for most enterprises, it is the financially responsible decision. If your renewal quote has doubled or tripled, schedule an assessment to see what your organization could save.

This Is Not an Outlier​

Since Broadcom completed its acquisition of VMware, enterprise customers across every industry have reported renewal increases ranging from 200% to over 500%. Perpetual licenses have been eliminated entirely. Every customer has been forced onto subscription pricing with mandatory 3-year minimum commitments.

For a 500-VM enterprise, the math is brutal. VMware Cloud Foundation now costs approximately $1.2 million per year. Before the acquisition, that same environment ran on $350,000 annually. That is not a rounding error. That is a budget-breaking change that forces difficult conversations at the executive level.

Small Businesses Hit Hardest​

Large enterprises at least have the leverage to negotiate. Small and mid-market organizations have no such luxury. Broadcom has implemented minimum order thresholds of $100,000 or more. Customers who fall below that line have been told, in effect, to find a different vendor.

The licensing model itself has also changed. Per-core licensing now enforces a 16-core minimum per socket. If you are running older servers with 8-core processors, you are paying for cores you do not have. That represents a 60% cost increase on legacy hardware before you even consider the subscription price increases.

The 3-Year Trap​

Broadcom's mandatory 3-year commitment compounds the problem. Organizations that sign today are locked into inflated pricing through 2029. If costs continue to rise -- and there is no indication they will not -- customers who wait will face even steeper renewals at the end of their term.

The window to act is now, while migration options are mature and proven.

What 500-VM Enterprises Are Doing​

The organizations that have moved fastest are seeing the best outcomes. One Fortune 500 financial services company migrated 350 VMs from VMware to KVM in 6 weeks, reducing annual virtualization costs from $1.4 million to $96,000. That is a 93% reduction and a payback period measured in weeks, not years.

The migration path is straightforward: export from vSphere, convert with automated guest OS fixing, and deploy on KVM or KubeVirt. Modern tooling achieves a 99.7% first-boot success rate, meaning minimal disruption to production workloads.

The Decision Framework​

Every VMware customer now faces three options:

1. Pay the increase. Accept the 315% renewal and lock in for 3 years. Budget for further increases at the next renewal.
2. Negotiate. Possible for large enterprises, but Broadcom has shown limited flexibility. Most customers report single-digit percentage reductions at best.
3. Migrate. Move to KVM-based infrastructure and eliminate VMware licensing entirely. Proven at scale, with documented cost reductions of 90% or more.

The math speaks for itself. At $187,000 per year and rising, the cost of staying on VMware now exceeds the cost of leaving.

Next Steps​

If you are facing a VMware renewal, get a cost analysis before you sign. Understand what your environment would cost on KVM. Compare the 3-year total cost of ownership for both paths.

The organizations that act now will save millions over the next three years. The ones that wait will pay Broadcom's price.

Schedule a VMware Exit Assessment to see your specific numbers.

Performance​

KVM runs as a kernel module within Linux, giving it near-native performance for CPU-intensive workloads. There is no separate hypervisor layer consuming resources. VMware ESXi is a purpose-built bare-metal hypervisor with decades of optimization, and its performance is excellent. In practice, benchmark comparisons between the two show KVM and VMware within 2-5% of each other for most workloads. For I/O-intensive applications, KVM's VirtIO paravirtualized drivers often outperform VMware's PVSCSI, particularly for storage throughput.

The performance gap that existed a decade ago has effectively closed. Both hypervisors deliver enterprise-grade performance for database servers, application servers, and general-purpose workloads.

Cost​

This is where the comparison diverges sharply. KVM is included in every Linux distribution at no additional cost. RHEL, Ubuntu, SUSE, and Fedora all ship with KVM built into the kernel. The total licensing cost for the hypervisor itself is zero.

VMware's post-Broadcom pricing starts at approximately $250 per CPU per year for VMware Cloud Foundation, which is the minimum offering now available. For a 200-CPU deployment, that translates to $50,000 annually just for the hypervisor license, before adding support contracts. Organizations previously running vSphere Standard at $600 per CPU (perpetual) are now paying recurring subscription fees that exceed their previous one-time purchase within two years.

Management tooling adds to the cost differential. vCenter Server requires its own license. KVM management options include Proxmox VE (open-source with optional enterprise support), oVirt (open-source), and Cockpit (included with RHEL). HyperSDK provides a commercial management layer with 45 dashboard views and 205 API endpoints for organizations that need enterprise-grade operational tooling.

Management and Ecosystem​

VMware's strongest advantage has always been its management ecosystem. vCenter, vMotion, DRS, and HA provide a mature, integrated management experience that IT teams know well. The tooling is polished and the documentation is extensive.

KVM's management ecosystem has caught up significantly. Proxmox VE provides a web-based management interface with clustering, live migration, backup, and high availability. For organizations running Kubernetes, KubeVirt enables VMs to run as Kubernetes pods with full lifecycle management through standard Kubernetes tooling. Red Hat's OpenShift Virtualization (built on KubeVirt) provides enterprise support for this approach.

The gap remains in advanced features like distributed resource scheduling, though Proxmox's HA manager and QEMU's live migration capabilities cover the most critical use cases.

Security and Compliance​

Both platforms provide the security features enterprises require. VMware offers vSphere Trust Authority, encrypted vMotion, and VM encryption. KVM leverages Linux's built-in security stack: SELinux, AppArmor, sVirt for mandatory access control, and LUKS for disk encryption. The Linux kernel's security track record is well-established, and patches are typically available faster than for proprietary hypervisors.

For compliance frameworks like PCI-DSS, HIPAA, and FedRAMP, both platforms have established certification paths. KVM's open-source nature provides an advantage for organizations that require source code review as part of their security evaluation.

Migration Path​

Moving from VMware to KVM is no longer the multi-month, high-risk project it once was. Tools like HyperSDK automate the export of VMs from vSphere, convert VMDK disk images to QCOW2 format, inject VirtIO drivers into Windows and Linux guests, and deploy to KVM targets. The process achieves a 99.7% first-boot success rate, meaning most VMs require zero manual intervention after migration.

A typical migration timeline for a 200-VM environment is 60-90 days, including planning, pilot migrations, and production cutover. Organizations running HyperSDK's automated pipeline have completed migrations of 350+ VMs in as little as six weeks.

The Verdict​

For new deployments, KVM is the clear choice in 2026. The cost savings are substantial, performance is equivalent, and the management ecosystem has matured to enterprise standards.

For existing VMware customers, the decision depends on your renewal timeline and migration readiness. If your VMware renewal is approaching and costs are increasing, migrating to KVM offers 60-93% cost reduction with minimal operational disruption when using automated migration tooling.

The hypervisor is no longer the differentiator it once was. The value has shifted to the management, automation, and migration tooling that sits above it. Choose the platform that gives your team the most operational capability at the lowest total cost of ownership.

The Broadcom Effect​

When Broadcom finalized its $61 billion acquisition of VMware, the immediate impact was felt across the customer base. Perpetual licenses were eliminated entirely. Every customer was forced onto subscription-based pricing, and the cost increases have been staggering. Reports from enterprise IT teams consistently cite renewal quotes that are 200% to 500% higher than their previous annual spend.

The bundling strategy has made things worse. VMware's product portfolio was consolidated into fewer, larger bundles. Organizations that previously purchased only vSphere now find themselves paying for a full VMware Cloud Foundation suite, regardless of whether they use the additional components. A mid-market company that was spending $30,000 per year on vSphere licensing might now face a $120,000 annual bill for VMware Cloud Foundation.

Who Is Most Affected​

Small and mid-market customers have been hit hardest. Enterprise accounts with direct Broadcom relationships have some negotiating leverage, but organizations running fewer than 500 CPUs often find themselves with no room to negotiate. Channel partners that previously offered competitive pricing have seen their margins squeezed, leaving fewer options for customers seeking discounts.

Government agencies and educational institutions, which often operated under favorable licensing agreements, are seeing those agreements expire without renewal options. Healthcare organizations running critical EMR systems on vSphere face difficult choices between absorbing massive cost increases or undertaking complex migrations under tight timelines.

The Real Numbers​

Based on data from organizations that have approached HyperSDK for migration assistance, the average cost increase after Broadcom's changes breaks down as follows:

• Small deployments (under 100 VMs): 300-500% increase in annual licensing costs
• Mid-market (100-500 VMs): 200-400% increase, often with reduced support tiers
• Enterprise (500+ VMs): 150-300% increase, with pressure to adopt VMware Cloud Foundation
• Government and education: Loss of preferential pricing, effective increases of 250-600%

These numbers translate to real budget impact. A 200-host VMware environment that cost $180,000 annually might now cost $540,000 or more, with no additional functionality.

What Are Your Alternatives​

The good news is that the hypervisor market has matured significantly. KVM, the kernel-based virtual machine technology built into Linux, now powers the majority of public cloud infrastructure worldwide. AWS, Google Cloud, and Azure all run on KVM-based hypervisors. The technology is proven at a scale that dwarfs any VMware deployment.

Migration platforms like HyperSDK have emerged specifically to address this transition. HyperSDK can export VMs directly from vSphere, convert disk images to KVM-compatible formats, inject the necessary VirtIO drivers, and deploy to your target infrastructure. The entire process is automated, tracked, and verified with checksum validation.

Proxmox VE offers a mature, open-source virtualization platform with a web interface that many administrators find comparable to vCenter. For organizations moving toward cloud-native infrastructure, KubeVirt enables VM workloads to run alongside containers on Kubernetes.

The Migration Window​

Organizations that have not yet renewed their VMware agreements are in the best position to evaluate alternatives. The typical migration timeline for a mid-size deployment (200-500 VMs) is 60-90 days when using automated tooling. HyperSDK's 99.7% first-boot success rate means most VMs require no manual intervention after migration.

The key is starting the evaluation before your renewal deadline. Running a proof-of-concept migration with 10-20 non-critical VMs takes less than a week and provides the data your team needs to make an informed decision.

Next Steps​

If your organization is facing a VMware renewal, consider these immediate actions:

1. Inventory your VMware footprint -- document every VM, its resource requirements, and its criticality
2. Calculate your true cost of ownership -- include licensing, support, training, and operational overhead
3. Run a proof-of-concept -- use HyperSDK to migrate a small batch of test VMs to KVM or Proxmox
4. Build a business case -- compare 3-year TCO of staying on VMware versus migrating to open-source alternatives

The Broadcom acquisition has created urgency, but it has also created opportunity. Organizations that act now can reduce their virtualization costs by 60-93% while gaining independence from single-vendor lock-in.

The VMware Licensing Problem​

When Broadcom acquired VMware and restructured its licensing model, many enterprises saw their virtualization costs increase by 3x to 10x overnight. Perpetual licenses disappeared, bundled products were forced into expensive suites, and smaller customers lost access to affordable tiers entirely. Organizations that had built their entire infrastructure on vSphere were suddenly locked into unsustainable costs with no clear migration path.

HyperSDK exists to solve that problem. It provides a unified platform for exporting VMs from vSphere and deploying them to KVM, Proxmox, AWS, Azure, GCP, OCI, OpenStack, Alibaba Cloud, Hyper-V, or any combination of these providers.

10 Cloud Providers, One Interface​

HyperSDK supports 10 cloud providers and hypervisors through a consistent provider interface. Each provider implements the same set of port interfaces defined in our hexagonal architecture, meaning you interact with AWS the same way you interact with Proxmox or KVM. The supported providers are:

• VMware vSphere -- source provider for exports
• KVM/libvirt -- the most common migration target
• Proxmox VE -- popular open-source hypervisor
• AWS EC2 -- import as AMI or run directly
• Microsoft Azure -- managed disk import
• Google Cloud Platform -- Compute Engine integration
• Oracle Cloud Infrastructure -- custom image import
• OpenStack -- private cloud deployments
• Alibaba Cloud -- ECS instance support
• Microsoft Hyper-V -- Windows-based hypervisors

45 Dashboard Views​

The web dashboard is not an afterthought. It ships with 45 distinct views organized into five navigation groups: Migration, Observability, Infrastructure, Tools, and System. You can browse VMs with OS-specific icons, trigger exports with a single click, monitor job progress in real time, estimate costs across providers, schedule carbon-aware migrations, and debug issues with an integrated explain mode -- all from your browser.

The dashboard is built with React 18 and Tailwind CSS, supports dark and light themes, and includes keyboard shortcuts for power users. Every view communicates with the backend through the same versioned REST API that CLI users and automation scripts consume.

205 API Endpoints​

HyperSDK exposes 205 REST API endpoints under the /api/v1/ prefix. These cover the full lifecycle of VM migration: discovery, capability detection, export, import, job management, scheduling, cost estimation, carbon tracking, RBAC, audit logging, secrets management, webhooks, backups, and system health. Every endpoint is documented, versioned, and enforces authentication through a middleware chain that includes rate limiting, request size limits, CORS, and security headers.

The API is designed for automation. You can script an entire fleet migration using curl or integrate HyperSDK into your existing CI/CD pipelines. The hyperctl CLI wraps the same API for interactive use.

Hexagonal Architecture​

Under the hood, HyperSDK follows a hexagonal (ports and adapters) architecture. The domain layer in internal/domain/ defines 70+ canonical types across 12 files. Port interfaces in internal/ports/ define 17 contracts that adapters must implement. This separation means you can swap out any infrastructure component -- database, provider, auth system -- without touching business logic.

The architecture was implemented across 10 phases, each adding a new layer of abstraction. The result is a codebase where every dependency points inward, every adapter is independently testable, and every provider satisfies compile-time interface assertions.

Upload and Deploy from the Browser​

One of the most requested features during development was the ability to upload VM disk images directly through the browser and deploy them to a target hypervisor. HyperSDK supports this end-to-end. You can upload a VMDK, qcow2, or raw disk image through the dashboard, and the platform will handle format conversion, storage allocation, and deployment. Progress is tracked in real time with a callback-based progress reader that streams updates to the UI.

System Observability​

Migrating hundreds of VMs is complex, and things will go wrong. HyperSDK includes a system health score that aggregates metrics from all connected providers, storage backends, and internal services into a single 0-100 score. When something degrades, the explain mode walks you through exactly what went wrong and why, using structured diagnostic data rather than raw log dumps.

Debug tools in the dashboard let you inspect individual jobs, replay failed exports, view audit trails, and check provider capabilities without leaving the browser. Alerts are configurable through webhooks, so you can pipe notifications to Slack, PagerDuty, or any HTTP endpoint.

What is Next​

HyperSDK is under active development. On the roadmap:

• Kubernetes operator for managing migrations as custom resources, with condition-based status reporting already implemented in pkg/operator/controllers/
• Parallel batch exports to migrate entire clusters in hours rather than days
• Incremental sync for near-zero-downtime migration of production workloads
• Terraform provider so you can declare migration workflows as infrastructure-as-code
• Extended carbon reporting with historical trend analysis and ESG compliance dashboards

We believe VM migration should be boring infrastructure -- reliable, predictable, and invisible. HyperSDK is our contribution toward making that a reality. Try it out, file issues, and let us know what you think.