How Kubermatic Is Bringing Virtual Machines Into the Kubernetes Control Plane

VMware environments typically host long-lived applications, operating systems, storage dependencies, network rules, and established administrative practices. Transitioning from VMware requires more than choosing a new hypervisor. Teams need a solution that preserves the operating model essential for workload continuity.

In a Software Plaza webinar, Twain Taylor interviewed Mo’ath Qasim, VP of Engineering at Kubermatic, about running virtual machines on Kubernetes and transitioning from VMware-based infrastructure. They discussed Kubermatic Virtualization, which leverages KubeVirt to manage VMs through Kubernetes while maintaining familiar operational workflows for infrastructure teams.

VMware’s shifting terms have made exit planning more urgent

VMware has been the default enterprise virtualization platform due to its integrated hypervisor and management stack. However, after Broadcom acquired VMware and changed its commercial model, organizations are reassessing licensing costs, bundled products, and their reliance on a single vendor.

The challenge extends beyond the hypervisor. Large environments often rely on integrated networking, storage, identity, and management products. Replacing a single layer can introduce operational issues. The initial step is to inventory current dependencies and identify feasible migration paths.

Qasim advised a gradual transition. Reducing VMware usage in manageable segments lets teams test performance, operations, and support before migrating critical systems.

Why Kubernetes changes the way teams run VMs

Kubernetes was designed for containers, which are typically short-lived and easily replaced. In contrast, virtual machines often persist for years, retain state, require stable network identities, and may run software that cannot be quickly containerized.

KubeVirt adds VM management to Kubernetes. A VM becomes a Kubernetes-managed resource, allowing teams to apply scheduling, access control, policy, and declarative configuration. Storage, network design, high availability, security, backup, and service-level expectations still need deliberate attention.

A Kubernetes platform unifies VMs and containers under one control plane. However, teams used to vCenter may be reluctant to manage all tasks through command-line tools and YAML. The transition affects both administration and infrastructure.

Kubermatic keeps Kubernetes as the underlying control plane and adds a layer for day-to-day VM operations. Its wider Kubernetes platform manages large numbers of clusters. The virtualization offering extends that operating model to VM workloads, so organizations can manage VMs alongside containers instead of maintaining separate systems for each.

A familiar interface matters during a platform change

Migration projects can stall if experienced administrators must abandon familiar tools and concepts. VMware operators rely on graphical interfaces for VM management, while Kubernetes operators typically use APIs, command-line tools, and GitOps workflows.

Kubermatic Virtualization bridges those models through its dashboard. Teams can create and manage VMs using instance types, CPU and memory sizing, attached disks, VPCs, subnets, and console access. They can select a predefined configuration or set resources directly, then choose networks, add interfaces, and use cloud-init or SSH access for initial setup.

The goal is not to hide Kubernetes, but to make common VM tasks accessible to administrators unfamiliar with Kubernetes-native workflows. VMs remain declaratively managed, enabling platform teams to adopt GitOps without requiring immediate changes to all UI-driven processes.

The same pattern applies to installation and provisioning. Kubermatic supports declarative blueprints for infrastructure setup and tools for provisioning and expanding clusters. Teams describe the desired state rather than performing each change manually.

Networking and storage make migration harder than VM conversion

Migrating a disk image is only one aspect of the process. Applications often depend on fixed IP addresses, VLANs, firewall rules, ingress paths, service exposure, and specific storage behaviors. Without mapping these dependencies, a VM may not function correctly after migration.

The webinar covered VPCs and subnets, including isolated networks that can use overlapping address ranges. That can help teams represent existing network layouts while separating tenants or environments. Load balancers, policy controls, multiple interfaces, and BGP or BFD peering were also discussed where a Kubernetes-based environment needs to coexist with VMware networking.

VM disks require a storage system that meets workload availability and performance requirements. While snapshots can assist with data migration, teams must also test restore paths, throughput, and application behavior.

A migration assessment should answer a small set of questions:

• Which VMs can move without changes, and which have operating system, guest software, or application constraints?
• What network addresses, routing rules, security policies, and integrations must be preserved?
• What storage behavior does each workload require?
• Which systems should remain on VMware during a hybrid phase?

Linux workloads are often easier to validate initially. Windows VMs can run on KubeVirt-based platforms but require careful testing due to compatibility and software dependencies. The objective is to identify suitable workloads and maintain a hybrid environment as needed.

Migration needs a staged operational plan

KubeVirt-based migration work can use projects such as Forklift and the Migration Toolkit for Virtualization to bring VMs from vSphere-derived environments into a Kubernetes destination. The workflow starts by connecting to the source environment, selecting systems to import, and checking that access, network paths, and storage are ready.

For large VMware environments, repeatability is more important than a single successful migration. Teams should document how VM configurations map to instance types, how IP addresses are managed, how snapshots are handled, and how applications are tested after migration. They must also determine when live migration is appropriate and when a planned outage is safer.

The webinar emphasized that organizations do not need to make an immediate, all-or-nothing decision. A phased approach allows teams to migrate lower-risk workloads first, retain selected systems, and refine the process based on operational data.

Kubernetes becomes a shared control plane for VMs and containers

Kubernetes-native virtualization offers more than another hypervisor. It puts VMs, containers, networking, identity, and policy under a shared set of APIs and operating practices. That can suit private cloud environments, edge deployments, and estates where older VM workloads must coexist with newer application services.

GPU support is also relevant as organizations place AI-related workloads closer to existing infrastructure. With suitable hardware, KubeVirt-based environments can expose GPUs to VMs, placing selected GPU-backed workloads in the same broader operating environment as Kubernetes services.

This transition requires careful planning. Teams must assess workload suitability, maintain necessary network and storage behaviors, and provide administrators with a clear path from traditional VM operations to Kubernetes-based management. For organizations evaluating VMware alternatives, Kubermatic offers a solution with KubeVirt as the VM layer, an operational interface for administrators, and a staged migration process.

The webinar provides further details on Kubermatic Virtualization’s dashboard, VM configuration, network setup, and migration strategy. It serves as a valuable resource for infrastructure teams evaluating which VMware workloads to migrate, which to retain, and how a Kubernetes-based VM platform could support a broader private cloud strategy.