Chris Engelbert 
Most guides to migrating off VMware® vSphere spend their length on the destination platform. Choose Red Hat® OpenShift® Virtualization or plain KubeVirt, size the cluster, plan the network, and the virtual machines will follow. The tooling that actually moves them tends to get a paragraph.
That paragraph is where the storage decisions live. Red Hat’s Migration Toolkit for Virtualization, MTV, is the supported path from vSphere into OpenShift Virtualization, and on the storage side it asks you for almost nothing: a mapping from your source datastores to a target StorageClass. One field, in a plan you are filling out at the end of a long planning exercise, usually by picking whatever class the cluster already has.
Then it proceeds to make four decisions for you. Three of them are difficult to undo after the virtual machine is running on the other side, and none of them is presented as a decision at the moment you make it. This post is about those four, what MTV does if you do not choose, and what changes if the storage underneath is something other than the cluster default.
A note on what this post is not. If your open question is which storage layer to migrate onto, that argument is made properly in the KubeVirt storage migration guide and there is no point repeating it here. If your question is what a datastore becomes on the other side, that translation has its own post. This one is about the tool and its defaults.
What MTV actually does, and where storage enters
MTV supports migrations from five provider types: vSphere, oVirt, OpenStack, OVA files, and OpenShift itself. For the vSphere case you can register either vCenter or, since MTV 2.6, an ESXi host directly, which matters for estates where vCenter is being decommissioned on a different schedule than the hosts.
The objects you create are worth naming, because the storage decision hides in one of them. A provider is the source. A network map and a storage map translate source constructs to target ones, and the storage map is where source datastores become a target StorageClass. A plan is a set of virtual machines sharing those maps and their migration parameters. Creating a migration against a plan is what starts work.
What happens next is the part most planning documents skip. For each source virtual machine disk, the migration controller creates a DataVolume, and the Containerized Data Importer creates a PersistentVolumeClaim from it. So the count of volumes your storage layer is asked to provision is not the number of virtual machines, it is the number of disks across all of them, appearing more or less at once when a plan starts. A conversion pod then runs virt-v2v against the copied disk, which converts the image into a format OpenShift Virtualization can boot and goes inside the guest filesystem to strip VMware-specific drivers and inject virtio.
Two consequences follow immediately. The first is that your storage layer sees a burst of concurrent provisioning and a burst of sustained sequential writes at the same time, which is a different load profile than steady-state virtual machine operation and is the load profile that determines how long your cutover window is. The second is that whatever StorageClass you named in the storage map is now the class each of those PVCs was created from, and that class carries properties the virtual machine inherits permanently.
The four decisions, and which ones you can take back
Here is the honest version of what the storage map commits you to. The last column is the one to read first, because a decision that is cheap to revisit deserves less planning time than one that does not.
Table 1: what MTV decides on your behalf when the storage map names a class, and how reversible each decision is after the virtual machines are running.
| Decision | What happens if you do not choose | What it costs when the default is wrong | Reversible after cutover? |
|---|---|---|---|
volumeMode: Block or Filesystem | MTV applies its default volume and access modes for the storage it detects | Filesystem mode puts a host filesystem under a guest that already has one, which is slower than Block for virtual machine disks and, on EXT4-backed volumes, needs CDI filesystem overhead raised above 10% or provisioning fails on size | No. Changing volume mode means a new PVC and a second copy of the data |
| Access mode: RWO or RWX | Inherited from the class, and node-local defaults are commonly RWO | ReadWriteOnce does not support live virtual machine migration, so the VM arrives unable to move off its node and every node drain becomes downtime | No. Same as above, the mode is fixed at provisioning |
| Cold or warm migration | Cold, unless you explicitly plan warm, which is available only for vSphere and oVirt sources | Cold means the VM is down for the whole copy. Warm keeps it running through precopy and cuts over on the delta, so the wrong choice is measured in hours of unnecessary downtime | Yes. It is a plan property, not a property of the volume |
| Which pool the VM ends up on | Whatever the named class provisions from | The class you migrated onto is where the VM lives. Moving a populated disk later is a second migration with its own window | No, but the pool can grow. Independent capacity scaling avoids the re-migration; a node-local class does not |
| Cutover throughput ceiling | Set by the destination volume, not by MTV | A node-local target makes the window a function of one machine’s write bandwidth. A shared pool spreads the same writes across nodes | Not applicable. It is spent once, during the migration itself |
| Transfer acceleration path | MTV can migrate without the VDDK image, more slowly | Red Hat strongly recommends building a VDDK image, and migrations of vSAN-backed virtual machines do not work without it, which catches vSAN estates late | Yes. Fix the image and re-run the plan |
Three of the four sticky decisions are properties of the PVC, and that is the pattern worth internalising: anything fixed at provisioning time is a decision you are making permanently, in a form field, at the end of a planning process about something else.
The volumeMode row is the one with the most money in it, and it is worth being precise rather than dramatic about why. A virtual machine disk is a block device to its guest. If the PVC is Filesystem mode, that block device is a file on a filesystem the host manages, sitting under a guest filesystem that is also managing blocks. Red Hat’s own documentation states plainly that Filesystem mode is slower than Block mode. The cost is not catastrophic and plenty of estates run this way, but it is a permanent tax you accepted without being asked, on every disk in the plan, for the life of those virtual machines.
The access-mode row is the one that surprises people most, because it does not show up as slowness. It shows up weeks later, the first time someone tries to drain a node for patching and discovers that the migrated virtual machines will not move. Live migration needs the volume to be attachable from more than one node, and a ReadWriteOnce volume by definition is not.
About to fill in the storage map on your first MTV plan? Talk to us before the cutover rather than after, because three of these four decisions are set when the PVC is created and cost a second data copy to change. Talk to a storage architect
What the importer actually does to your disk
The conversion step is where the file-format questions land, and it is worth understanding at the level of what changes rather than at the level of the command line, because you are not going to be typing the command.
Table 2: what happens to each source artifact on the way into a PVC, and what the storage layer sees.
| Source artifact | What MTV and CDI do with it | What lands in the PVC | Storage-side implication |
|---|---|---|---|
| VMDK on a VMFS or vSAN datastore | Copied out, then virt-v2v converts it to a KVM-compatible format, typically raw or qcow2 | A bootable virtual machine disk, one PVC per source disk | Sequential write burst sized to the real allocated data, not the provisioned capacity |
| OVA or OVF appliance | Registered as its own provider type; the archive is unpacked and its disks imported | Same as above, one PVC per disk inside the appliance | Watch total size, an appliance can expand well beyond its archive |
| Raw device mapping or a presented LUN | No file to convert, the guest wanted the block device | A raw block volume, which is an ordinary supported mode rather than an escape hatch | This case gets simpler than it was under vSphere |
| Guest drivers and agents | The conversion pod strips VMware-specific drivers and injects virtio into the guest filesystem | A guest that boots on KVM | None directly, but this is why the conversion is a write pass over the disk and not a copy |
The point of that table is that the conversion is not a metadata operation. virt-v2v writes into the guest filesystem, so the disk is written, not merely transferred, and the destination volume’s write throughput is what that step is bound by.
Warm migration deserves one paragraph of correction, because it is commonly described in a way that puts the snapshots in the wrong place. Precopy works by copying the disks incrementally using changed block tracking snapshots on the vSphere side, taken at hourly intervals by default, while the virtual machine keeps running. Those are source-side snapshots and your destination storage has nothing to do with creating them. You must enable CBT per virtual machine and per disk beforehand, and a virtual machine supports a bounded number of CBT snapshots, so a source with a deep existing snapshot chain can fail a warm migration outright. What the destination storage layer determines is how quickly each precopy round is absorbed and, more importantly, how fast the final delta lands during the cutover, since the cutover window is exactly the time it takes to shut the virtual machine down, write the remaining changed blocks, and start it on the other side.
What the storage target changes, and what it does not
Simplyblock does not replace MTV, does not move virtual machines, and changes nothing about the vSphere side of the transfer. The provider configuration, the VDDK image, CBT, the ESXi read path and the 10 GbE minimum Red Hat specifies for the migration network are all outside any storage vendor’s reach, and a badly planned migration will not become a good one because of what is underneath it. The honest claim is narrower and still worth making: the destination storage layer decides which of MTV’s defaults hurt you.
Concretely, against the four sticky decisions above. Simplyblock serves raw block volumes over NVMe/TCP or NVMe/RoCE, so Block mode is the natural mode rather than the one you have to argue for, and the overlay tax that Filesystem-mode PVCs impose on virtual machine disks does not arise. Volumes are reachable from any node over the fabric rather than pinned to the one that has the disk, which is what live migration after the cutover requires. The write burst during conversion lands on a pool aggregated across nodes rather than on one machine’s local devices, so the cutover window is a function of pool bandwidth instead of a single server’s. And because capacity and compute scale independently, the pool you migrated onto can grow without becoming the reason for a second migration later.
The commercial shape matters during a migration specifically, and it is worth stating plainly rather than in comparison-table shorthand. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. During a migration you are deliberately running capacity on two platforms at once for weeks or months, and you do not want that overlap to trigger capacity tiers or bundle terms you do not control. A storage line that follows the platform subscription you are moving to, unmoved by data volume, tends to look better precisely during the transition rather than only after it.
The counter-honesty belongs here too, in the same breath. A shared pool is a wider failure domain than node-local disks, and that is a trade to make deliberately. You are putting a fabric in the data path, which wants a network designed for it rather than inherited. None of this makes MTV faster at reading from ESXi, which for many estates is the actual bottleneck. And if your plan is thirty virtual machines onto a cluster you already have, the default class may well be fine and the right answer is to check the volume mode and move on.
For the decisions that come after the cutover, snapshots, disaster recovery and the operational model on the other side, the day two storage operations post covers that ground. What this post is for is the fifteen minutes when someone is filling in a storage map, which is the moment the four decisions above are actually made.
Questions and Answers
What is the Migration Toolkit for Virtualization?
MTV is Red Hat’s supported tool for migrating virtual machines into OpenShift Virtualization, and it accepts five source provider types: vSphere, oVirt, OpenStack, OVA files, and OpenShift itself. You define a provider, a network map, a storage map, and a plan, then run a migration against the plan. For each source disk MTV creates a DataVolume, the Containerized Data Importer creates a PersistentVolumeClaim from it, and a conversion pod runs virt-v2v to make the disk bootable under KVM. The storage map is the only place storage enters the configuration, which is why its defaults matter more than their prominence suggests.
Does MTV choose Block or Filesystem volume mode for me?
Yes, if you do not choose. MTV applies default volume and access modes based on the storage it detects, and the class named in your storage map supplies them. This matters because Red Hat’s documentation states that Filesystem mode is slower than Block mode, and a virtual machine disk in Filesystem mode means a host filesystem sitting under a guest filesystem that is already managing blocks. We recommend confirming Block mode explicitly before the first plan runs, because changing volume mode afterwards requires a new PVC and a second copy of the data. Simplyblock provisions raw block volumes over NVMe/TCP by default, so Block mode is what you get without special configuration.
Will my migrated virtual machines be able to live-migrate afterwards?
Only if the volume’s access mode allows it. ReadWriteOnce does not support live virtual machine migration, and node-local storage classes commonly default to RWO. The failure is invisible at migration time and shows up the first time someone drains a node for maintenance and finds the virtual machines cannot move. If live migration is part of your operational plan, and it usually is for anyone replacing vSphere HA and DRS behaviour, the destination class needs to provide volumes attachable from more than one node. Volumes served over a fabric satisfy this because reachability is not tied to which node holds the physical device.
Should I use cold or warm migration?
Warm migration is available for vSphere and oVirt sources and keeps the virtual machine running through the copy, cutting over on the remaining delta, so it gives much shorter downtime for most workloads. Cold migration can finish faster in wall-clock terms for a virtual machine with a lot of data on a single disk, at the cost of being down throughout. Warm requires changed block tracking enabled per virtual machine and per disk in advance, and a source with a long existing snapshot chain can hit the CBT snapshot limit and fail. Unlike the volume-mode and access-mode decisions, this one is a plan property and can be changed between runs.
Do I need the VDDK image?
Red Hat strongly recommends building one to accelerate migrations, and for virtual machines backed by vSAN it is not optional: those migrations do not work without VDDK. You download the VMware Virtual Disk Development Kit, build an image, and push it to your registry before running plans. This one is worth checking early rather than discovering during a pilot, and unlike the PVC-level decisions it is fully reversible, since you fix the image and re-run.
Does simplyblock replace MTV?
No, and any storage vendor claiming otherwise is describing something else. MTV is Red Hat’s migration tool and simplyblock is the storage the migrated virtual machines land on. Simplyblock changes nothing about the vSphere side, the VDDK read path, changed block tracking, or the network between your ESXi hosts and the cluster. What it changes is which of MTV’s storage defaults cost you: Block mode instead of a filesystem under a filesystem, volumes reachable from any node so live migration works after the cutover, a pooled write path so the cutover window is not one server’s bandwidth, and independent capacity scaling so the pool you migrate onto does not become the reason for a second migration.
What happens to VMDK files and OVA appliances during the migration?
They get converted rather than moved. For a VMDK, MTV copies the disk out of the datastore and virt-v2v converts it to a KVM-compatible format such as raw or qcow2, then goes inside the guest filesystem to strip VMware-specific drivers and inject virtio. OVA and OVF appliances are handled through their own provider type, unpacked, and their disks imported the same way, one PVC per disk. Raw device mappings are the easy case: there is no file to convert, and the guest gets a raw block volume, which in Kubernetes is an ordinary supported volume mode rather than the special case it was under vSphere. Because the conversion writes into the guest filesystem, the step is bound by the destination volume’s write throughput, not by the tool.
