A vSphere Admin’s Day-Two Translation Guide to VMs on Kubernetes

When we work with teams moving VMs onto Kubernetes, one of the first things we ask is who’s doing the moving because the answer varies from shop to shop. In some organizations, the Kubernetes platform team has inherited VMs and is learning how to run something that isn’t a container. In others, the virtualization team made the call and is the one learning Kubernetes, whether that’s on Red Hat OpenShift, Nutanix NKP, SUSE Rancher or another platform. Those are usually separate teams with separate habits, and it’s a mistake to assume the vSphere side will simply absorb Kubernetes because the VMs happen to be moving there.

If you’re on the virtualization side, the case for getting involved now comes down to where infrastructure work is heading. More of it is landing on Kubernetes: AI workloads are being built there, stateful containers and databases keep growing there, and VMs increasingly run next to containers instead of in a separate silo. VMware’s own platform points the same way, since VMware Cloud Foundation includes the vSphere Kubernetes Service, so even teams that stay on VMware end up with Kubernetes somewhere in the stack. 

In a 2026 451 Research survey by S&P Global, 49% of organizations said they expect VMs and Kubernetes to coexist for the long term. Our KubeCon announcements this week cover both halves of that picture, VMs and AI. Whichever Kubernetes platform your organization lands on, the admin who understands both sides gets a say in how the move happens instead of inheriting a plan someone else wrote.

The good news is that moving VMs onto Kubernetes changes less of the day-to-day job than most admins expect. You still build from golden images, take a snapshot before you patch, move workloads off a host before maintenance, and count on VMs coming back after a hardware failure, and nearly every one of those tasks has a direct KubeVirt equivalent. For most of them, getting a detail wrong is cheap. The manifest fails validation, or the console doesn’t connect; you fix it, and the cost is an hour in the lab.

A handful of tasks work differently, and they tend to be the ones that look the most familiar. A snapshot can complete without the disk data in it. A VM you expected to live migrate off a node during maintenance can turn out to have disks that can’t attach to two nodes at once. A failed node can leave its VMs waiting for someone to confirm that it’s really down.

What those tasks share is where the prerequisite lives. In vCenter, shared storage and snapshot support were settled when someone built the cluster, so by the time you were running VMs, they were simply true. In KubeVirt, they belong to the StorageClass each VM’s disks were provisioned from. Two VMs on the same cluster can therefore behave very differently in the same maintenance window, and nothing about the VMs themselves will tell you which is which until you check their storage.

The examples use upstream KubeVirt, the open source project that runs VMs on Kubernetes and sits under OpenShift Virtualization and other distributions, with kubectl and virtctl commands. A few pieces depend on the distribution, such as node remediation and some storage migration workflows, and where they do, OpenShift is the example.

What is the KubeVirt equivalent of each vSphere day-two task? 

Sorted by what a missed prerequisite costs you, a vSphere week breaks into three groups. 

Most tasks can be fixed in the lab when something goes wrong. A few stay silent until the day you need them, and a few fail at the moment you’re counting on them, during a maintenance window or a node failure.

Which vSphere tasks are low risk to learn on KubeVirt? 

The first group is the one to learn by doing. A template becomes a VirtualMachine manifest, a YAML file that names the VM, sizes it with an instance type, and points its root disk at a DataVolume cloned from a golden image. Distributions such as OpenShift Virtualization ship golden images for common guest operating systems and let you add your own, and cloud-init or Sysprep takes over the job that customization specs did. When a manifest is wrong, the API rejects it before anything runs, so the fix is an edit and another try.

The bigger adjustment is in the habit around templates. The template that used to live in vCenter’s inventory becomes a file you keep in Git, review in a pull request, and diff when someone asks why two VMs that should be identical aren’t, and that change usually earns its keep the first time a team has to rebuild 50 VMs the same way.

Consoles, permissions, and placement are similarly low-stakes. virtctl console and virtctl vnc cover what the vCenter console did, provided the guest is configured for a serial console. Resource pools and folders become namespaces with ResourceQuotas, and vCenter roles become RBAC roles bound in each namespace, so the worst outcome of a rough mapping is a round of access requests after migration. DRS splits into two pieces. The Kubernetes scheduler places a VM when it starts, using resource requests, node selectors, and affinity rules that will look familiar if you’ve written DRS rules, and the descheduler rebalances running VMs by evicting them from busy nodes so they live migrate somewhere quieter. If the descheduler isn’t set up, VMs stay where they are and keep running.

That last detail is where the forgiving tasks end. Rebalancing depends on live migration, and every task in the other two groups depends on something the storage under the VM either can or can’t do.

Do KubeVirt snapshots work like vSphere snapshots? 

Snapshots are the task most likely to look fine when they aren’t. A VirtualMachineSnapshot captures the VM’s configuration and, through CSI volume snapshots, its disks. If the StorageClass behind a disk doesn’t support CSI VolumeSnapshots, KubeVirt still saves the VM’s configuration, so a snapshot object exists and the patch window moves on, but the disk data was never captured, which most teams find out during the restore.

The guest agent is the second thing to confirm. With the QEMU guest agent running, KubeVirt freezes the guest file systems before the snapshot and thaws them afterward, which gives you the quiesced snapshot you’re used to from VMware Tools. Without the agent, the snapshot is crash-consistent, and its status records that with a NoGuestAgent indication. Both conditions are easy to check before the first patch window: Confirm that a VolumeSnapshotClass exists for every StorageClass your VMs use and that the agent is running in the guests you plan to snapshot.

apiVersion: snapshot.kubevirt.io/v1beta1
kind: VirtualMachineSnapshot
metadata:
  name: app01-prepatch
spec:
  source:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: app01

Restoring asks for one more change in the runbook. In vSphere, reverting is a single action on the VM. In KubeVirt, you stop the VM, wait for it to finish stopping, and then apply a VirtualMachineRestore that names the snapshot. A rollback during a patch window therefore includes downtime that needs to be planned, along with a decision made in advance about who is allowed to stop a production VM to roll it back.

What does KubeVirt live migration require compared with vMotion? 

Live migration is where a missed prerequisite shows up in the middle of the maintenance window. virtctl migrate app01 moves a running VM to another node, and creating a VirtualMachineInstanceMigration object does the same thing in a form you can automate.

apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
  name: migrate-app01
spec:
  vmiName: app01

Whether either one succeeds depends on the VM’s persistent volume claims. KubeVirt only live migrates VMs whose PVCs use the ReadWriteMany (RWX) access mode because both nodes need the disk attached during the handoff, and it rejects migration requests for VMs that don’t qualify. In vSphere, shared storage was a property of the datastore and the cluster design. In KubeVirt, it belongs to each PVC and is set by the StorageClass when the disk is provisioned, which means a single cluster can hold VMs that migrate cleanly right next to VMs that can’t move at all. Running kubectl get pvc -n <namespace> and reading the ACCESS MODES column for every VM you expect to move takes a few minutes, and it’s worth doing before the first maintenance window goes on the calendar.

The network has a condition of its own. A VM attached to the pod network with bridge binding can’t live migrate, so keep the default masquerade binding there.

The same RWX rule governs maintenance mode, which becomes a node drain. kubectl drain <node> –ignore-daemonsets –delete-emptydir-data evicts the node’s workloads, and VMs with evictionStrategy: LiveMigrate move to other nodes while they keep running. VMs on RWO disks can’t make that move, so a node that hosts both kinds is the scenario to rehearse in the lab before you rely on a drain in production. If you’d rather manage cordon and drain as a single resource, OpenShift’s Node Maintenance Operator does that.

Is there a Storage vMotion equivalent for KubeVirt VMs? 

Moving a running VM’s disks to different storage builds on live migration, so everything above about RWX applies here too. KubeVirt can migrate a running VM’s disks to a different StorageClass: The platform provisions new volumes in the destination class, copies the data while the VM keeps running (live migrating the VM to another node along the way), and switches the VM to the new volumes. This is the volume migration feature, set with updateVolumesStrategy: Migration on the VM, and OpenShift Virtualization wraps the same capability in a storage class migration workflow.

Two Storage vMotion habits don’t carry over. The copy runs through the hosts and competes with VM I/O while it runs, so it deserves the same scheduling care as any other heavy job. The second is quieter. The migration doesn’t delete the source volumes when it finishes, and they keep consuming capacity until someone deletes the old PVCs, which makes cleanup a step to write into the runbook rather than something to remember afterward.

The other half of Storage vMotion is knowing where the disks end up. In vSphere, a datastore usually meant a specific array, so choosing one told you where the data would land. A Kubernetes StorageClass describes properties like replication and access mode without saying which array is underneath. Portworx® by Everpure fills that gap with Kube Datastores, which group storage by FlashArray™ system and generate a StorageClass for each array, so moving a VM’s disks to a different array uses the same storage migration workflow with a different destination class. The Portworx procedure moves one VM’s disks at a time, and every disk on the VM needs to use the same RWX volume type. Kube Datastores are in Directed Availability with Portworx Enterprise 3.7 on FlashArray Cloud Drives and require OpenShift Virtualization 4.18 or later, so check with your Portworx team before you plan around them.

How does vSphere HA translate to KubeVirt? 

vSphere HA restarts VMs from a failed host on its own, using network and datastore heartbeats to tell an isolated host from a dead one. KubeVirt can restart a VM elsewhere too: set runStrategy: Always on the VM, and the controller brings it back whenever it stops unexpectedly. The difference is in what happens before the restart. Kubernetes won’t assume a node is dead just because it stopped responding, and a VM on an unreachable node stays assigned to that node until something confirms the node is down because starting a second copy while the first might still be writing to the same disk is how data gets corrupted.

That confirmation comes from a remediation mechanism, and the specifics depend on your distribution. On OpenShift, the Node Health Check Operator watches for unhealthy nodes and hands them to Self Node Remediation or Fence Agents Remediation, which reboot or power off the node so its VMs can start somewhere else. Without one of these in place, a node failure can leave VMs waiting for someone to step in. Set remediation up before production VMs land on the cluster, then test it in the lab by pulling power on a node and timing how long the VMs take to come back.

HA is the one costly task whose prerequisite isn’t a StorageClass setting, although storage is the reason the prerequisite exists. Fencing is there to make sure two copies of a VM never write to the same disk.

How do you check a StorageClass before running VMs on it? 

Across the costly tasks, the pattern repeats. Each one depends on a property of the StorageClass that nothing checks when you provision a VM from it. A class without RWX will provision VM disks without complaint, and those VMs won’t live migrate. A class without snapshot support will accept VirtualMachineSnapshots, and those snapshots won’t hold the disk data. A CSI driver tells you that Kubernetes can provision storage on an array, and each of these capabilities is a separate question about the driver and the class.

So before production VMs land, go class by class. Find out whether it offers RWX block volumes, whether a VolumeSnapshotClass exists for it, what replication it uses, and, if placement matters for performance or compliance, which array the data lands on. Keep the answers next to the class names. That short list is what tells you, VM by VM, which of the tasks above will behave the way you expect.

How do you test KubeVirt in a lab before migrating? 

The quickest way to see which group each task falls into for your environment is to take one non-critical VM through an ordinary week in a lab cluster. Build it from a golden image, snapshot it and restore it, live migrate it, drain the node it’s on, move its disks to another StorageClass, and pull the power on its node. Each step either works or points to the StorageClass, operator, or network setting that needs attention, and every one of them is easier to fix before production VMs depend on it. 

Whether this week’s KubeCon represents your first exposure to Kubernetes or if you are a seasoned pro, Portworx by Everpure can help your teams accelerate their journey to Kubernetes. With familiar VM workflows that have been purpose-built for Kubernetes, integrations with Kubernetes platforms like Red Hat OpenShift and SUSE Rancher, and a complete storage and data management platform built for VMs on Kubernetes, we can simplify the transition for vSphere admins.

If you’re at KubeCon + CloudNativeCon North America in Salt Lake City, November 9–12, the Portworx team will be at booth #191 and happy to talk through any of these tasks. Nathan Wood’s demo theater session picks up the storage thread, covering why CSI support on its own doesn’t add up to resilience, DR, or data mobility. We’ll also be signing copies of “The VMware Professional’s Field Guide to Kubernetes” at the booth, which maps vCenter, NSX, and vSAN to their Kubernetes counterparts at the concept level.

Where to go next

• KubeVirt user guide: Live migration
• KubeVirt user guide: Snapshot and restore API
• KubeVirt user guide: Volume migration
• Portworx documentation: Migrate KubeVirt VM disks to a different Kube Datastore
• “The VMware Professional’s Field Guide to Kubernetes” (eBook)