Michael Schmidt 
Every other destination in the VMware® exit has a migration guide on this site. Red Hat® OpenShift® has one built around the Migration Toolkit for Virtualization. Generic KubeVirt has one built around DataVolumes and CDI. Teams skipping the hypervisor entirely have the bare-metal one.
Harvester has eight posts and not one of them covers the move. Seven compare it to something else, for a reader who has not decided yet. The eighth explains how to replace its bundled storage engine, for a reader already running it in production. Nobody has written for the person in between, who has decided, has a vSphere estate, and now has to get the virtual machines across.
That reader has a specific and slightly awkward problem. The platform’s migration tooling has moved storage from something you handled per virtual machine, at move time, to something you declare once, centrally, before the first disk transfers. Providers, networks and storage mappings get configured up front and then applied as per-VM defaults. Operationally that is a real improvement over a fragmented per-VM flow. Architecturally it means a decision that used to be made two hundred times, revisably, is now made once, early, by whoever is setting up the migration, often before anyone has thought about what runs on the cluster in month six.
Where the storage mapping actually happens
On vSphere, storage was never a question you answered. A virtual machine lived on a datastore. Moving it meant choosing a different datastore, and the choice was constrained to things that already existed and were already presented to the cluster. The properties of that target, how it tolerated a failure, whether it was thin, what media the blocks landed on, were attributes of the datastore itself, decided at build time by somebody else.
The Kubernetes-native equivalent splits that single object into two. The virtual machine’s disks become persistent volume claims, and the properties come from a StorageClass named at creation time. The migration’s storage mapping is nothing more than a table saying datastore A becomes StorageClass X. It looks like plumbing. It is the entire storage architecture of the destination cluster, entered in a form, before you have run a single workload on it.
Two things make this sharper than it looks:
- The mapping is applied as a default to every virtual machine in the plan. Whatever you put there is what several hundred disks inherit. There is no per-VM review step unless you build one.
- It runs before the cluster has any production load on it, which is exactly when nobody has evidence about latency, density or failure behaviour, and when the path of least resistance is to point everything at whatever StorageClass the installer created.
On Harvester that default is Longhorn, the bundled engine. Picking it is not wrong. Picking it by not choosing is the failure mode, because the consequences do not show up during the migration. They show up on the first node drain.
Four things the mapping decides that you cannot cheaply undo
Whether live migration works at all
This is the one that surprises people. A StorageClass whose volumes are ReadWriteOnce produces virtual machines that run perfectly well and cannot live migrate, because live migration needs the disk attached to the source and destination nodes simultaneously, however briefly. Everything looks healthy. The gap is invisible until the first time someone drains a node for a kernel update and discovers the VMs have to be powered off instead.
If the estate you are moving relied on vMotion, and most vSphere estates do, then RWX block on the target StorageClass is not a nice-to-have, it is the feature you are migrating in order to keep. The vMotion translation post works through the rest of that mapping.
Whether a multi-disk VM snapshots consistently
A virtual machine with a boot disk and two data disks is three volumes on the destination. Snapshotting them at three slightly different moments produces a restore point where the database file is newer than its own write-ahead log. Crash-consistency across a group of volumes is a property of the storage layer, and either the StorageClass you named supports consistent group snapshots or your restore procedure quietly becomes “restore, then repair.”
What the failure domain costs you
Bundled per-volume replication engines keep whole replicas of each volume on other nodes. Lose a node and the surviving replicas rebuild the missing copy, volume by volume, across the same network the running virtual machines are using. With a few hundred VM disks, that rebuild window is measured in hours and it is not quiet. A storage layer that separates the volume from the node it happens to be running on re-attaches instead of rebuilding, because the data never lived on the failed node in the first place. Erasure coding rather than three-way replication changes the arithmetic again: roughly 1.5x raw for the same usable capacity instead of 3x, which is the difference between buying drives twice and buying them once.
Whether you can change your mind
This is the reason the mapping deserves more than five minutes. Changing a StorageClass after the fact is not a configuration edit. Each virtual machine disk has to be copied to a new volume on the new class, which means, per VM, a clone, a cutover and a window. Doing that for an estate you have just finished migrating is a second migration, run by a team that has already spent its migration budget and its patience.
Declaring a target StorageClass is a ten-minute decision with a two-migration cost if you get it wrong. If you are filling in a storage mapping this quarter and are not certain the target supports RWX block and consistent group snapshots, it is worth an hour with someone who has done it. Talk to a storage architect
Declaring the target instead of landing on the default
The honest version of this advice is not “never use the bundled engine.” It is that the mapping should name the storage layer you intend to run in production, and that intention should be formed before the form is filled in, not after the estate is on it.
Table 1 compares the two orders of operations for a mid-size estate, roughly one to three hundred virtual machines.
| Map to the bundled default, swap later | Map to the intended target up front | |
|---|---|---|
| Migration effort | One pass, fastest to start | One pass, plus a day of design first |
| Live migration on day one | Only if the default class provides RWX block | Verified before any VM moves |
| Cost of changing your mind | Per-disk clone and cutover for every VM, a second migration | None; the decision was already made |
| When problems surface | First node drain, first restore test, first capacity review | During design, on an empty cluster |
| Node-failure behaviour | Replica rebuild across the production network | Volume re-attach, no rebuild |
The comparison content that got you here is about whether the platform is right. This is the narrower question of what you point it at, and the two decisions do not have to be the same. A Kubernetes-native VM platform that explicitly unbundles its storage layer is inviting exactly this separation: keep the compute and management platform, choose the storage independently.
Simplyblock is what we build for that slot. It presents NVMe/TCP volumes through a CSI driver, so the StorageClass you name in the mapping behaves like any other, with RWX block for live migration, consistent group snapshots across a multi-disk virtual machine, thin provisioning so allocated capacity is not consumed capacity, and re-attachment rather than rebuild when a node dies. It runs hyperconverged on the same nodes as the VMs, or on separate storage nodes when you want compute and capacity to scale independently, and the same cluster serves container workloads alongside the migrated virtual machines.
The licensing follows the same logic as the platform underneath it: simplyblock is priced by the CPU capacity of your worker nodes, counted the way an OpenShift subscription is counted, with control-plane and infrastructure nodes free. Data volume, feature set and replication factor do not change the number. That matters here specifically because a migration is the moment your provisioned capacity jumps by an order of magnitude in a week, and a model that charges for that jump turns a successful migration into a budget conversation.
What to settle before you fill in the form
Four questions, answerable in an afternoon, that determine everything above:
- Do any of the VMs in scope need live migration? If yes, the target StorageClass must provide RWX block. Confirm it on a test VM and an actual node drain, not from a feature matrix.
- Which VMs have more than one disk? Those are the ones whose backups are worthless without consistent group snapshots. Count them before you assume the number is small.
- What does node failure look like at your VM count? Ask the engine how long a rebuild takes with your disk count and your network, and whether that rebuild competes with production traffic.
- What is the estate’s real capacity, as opposed to its provisioned capacity? vSphere estates are routinely provisioned at two to three times what is written. Thin provisioning on the target preserves that; a target without it turns your overcommit into a hardware order.
Answer those and the mapping fills itself in. Skip them and the mapping still fills itself in, just with the default, and you find out which answers were wrong somewhere between the first node drain and the first restore test.
Questions and Answers
What is a storage mapping in a VM migration?
A storage mapping is the table that says which source datastore becomes which target StorageClass. On Harvester and other Kubernetes-native VM platforms it is declared centrally, before the migration runs, and applied as a default to every virtual machine in the plan. It is the single point where the destination cluster’s storage architecture is chosen, so it deserves design time rather than being treated as a form field.
Can I change the StorageClass after migrating the VMs?
Technically yes, practically at a cost most teams underestimate. Changing the class means copying each virtual machine disk to a new volume on the new class, with a cutover window per VM. For an estate of one to three hundred VMs that is effectively a second migration. Naming the intended target in the original mapping avoids it entirely, which is why the ten minutes spent on that entry is the highest-leverage part of the whole plan.
Why do my migrated VMs fail to live migrate?
Almost always because the StorageClass they landed on issues ReadWriteOnce volumes. Live migration needs the disk attached to two nodes at once during the handover, so RWO silently blocks it. The VMs run normally, and the problem only appears at the first node drain. Verify RWX block on the target class with a real drain before you migrate at scale, not from a datasheet.
Should I keep the bundled storage engine on a Kubernetes-native VM platform?
It is a reasonable choice for small clusters and lab estates, and a poor default for a production VM estate coming off vSphere. Per-volume replication engines rebuild whole replicas across the production network when a node fails, and that window grows with VM count. Platforms that unbundle their storage layer do so precisely so you can make this choice deliberately. Ceph is a credible alternative when raw performance is not the deciding factor and you have the operational depth to run it; simplyblock is the better fit when latency, density and re-attach speed matter.
How does simplyblock fit a Harvester or KubeVirt migration?
Simplyblock is named as the target StorageClass in the storage mapping, before the first disk transfers. It provides NVMe/TCP volumes through a CSI driver with RWX block for live migration, consistent group snapshots across multi-disk VMs, thin provisioning, and volume re-attachment instead of replica rebuild on node failure. It runs hyperconverged on the VM nodes or on separate storage nodes, and it is priced by worker-node CPU capacity rather than by the volume of data you migrate.
