The migration is the visible win
This is the "real build work" the posting promises. Red Hat's tool is the Migration Toolkit for Virtualization (MTV) — productized Konveyor Forklift. Learn the plan objects, the warm-migration mechanics, and the Windows-specific traps, and you can run the whole conversation.
MTV vs MTC — don't confuse them
MTV — Migration Toolkit for Virtualization
Moves VMs into OpenShift Virtualization (KubeVirt). Operator from the Red Hat catalog, web UI in the OCP console, CLI via oc CRs. Sources: vSphere/vCenter primarily (oVirt/RHV too). Under the hood: Konveyor Forklift + virt-v2v.
MTC — Migration Toolkit for Containers
Moves workloads between Kubernetes clusters (namespace-to-namespace). Different product, different problem. Knowing the difference instantly signals you've touched this ecosystem.
The plan objects (know all four)
- Provider — a vCenter (or RHV) with credentials, stored as a Secret
- NetworkMap — source vCenter network → target OpenShift NAD (Multus-attached interface, e.g. bridge or macvlan on OVN)
- StorageMap — source datastore → target StorageClass (OpenShift Virtualization uses DataVolumes/CDI for disks)
- Plan — one or more VMs + the maps + cold or warm mode + hooks
And the destination: OpenShift Virtualization (KubeVirt-based) runs the VM as a pod-shaped resource — VirtualMachine/VirtualMachineInstance CRs, same network policies, same scheduling, snapshots via DataVolumes, live migration between nodes when you drain for patching. That last one is the quiet killer feature for a Windows fleet.
Cold vs warm migration
Cold
VM is powered off, disks copied once, VM booted on the target. Simplest, but downtime = full copy time. Right for batch jobs, non-critical boxes, and anything with a tolerance window.
Warm
VM keeps running. Forklift uses vSphere Changed Block Tracking to pre-copy data in a loop (precopy) while the source stays live, then a final sync + cutover boot on OpenShift. Downtime shrinks from hours to a reboot. Right for the production Windows servers this company is moving.
Forklift spins up a small controller VM inside the target cluster. It snapshots the source disk (CBT keeps subsequent passes incremental), streams the blocks to the target volume, and repeats until the delta converges. At cutover: final sync, source VM powers off, target VM boots. Your failure modes: snapshot bloat on vCenter, CBT reset (e.g. after a vMotion/storage migration), and the last-mile sync window growing unbounded if the app writes faster than the link copies.
Why Windows guests are the hard part
A Linux VM migrates and just boots. A Windows VM will happily blue-screen on a disk driver change. The interview gold is showing you know exactly which traps exist:
| Trap | Mitigation |
|---|---|
| BSOD 0x7B (INACCESSIBLE_BOOT_DEVICE) — boot disk controller changes from LSI/IDE to VirtIO | virt-v2v injects virtio-win drivers during conversion; verify guest tools install post-boot |
| BIOS vs UEFI firmware mismatch | Match the source's firmware on the target VM; test boot early, not at cutover |
| Network identity: MAC/IP, static config, firewall profiles | NetworkMap to the right NAD/VLAN; plan for "unidentified network" → firewall profile flips that break services |
| Windows licensing/activation | MAK/KMS re-activation after hardware change — budget for it in the cutover window |
| App dependencies outside the VM | AD, SQL, file shares, DNS, NTP, monitoring agents — dependency-map every box before it moves |
| Time sync drift | Windows guest agents + chrony on the host; drift breaks Kerberos (5-min skew = auth failures) |
| Snapshots left behind by warm migration | Consolidate vCenter snapshots post-cutover; stale CBT resets the incremental chain |
A cutover plan he'll respect
- Inventory + dependency map — VMs, vCPUs/RAM/disk, VLANs, AD/DB/DNS dependencies, backup status of each
- Prep the target — MTV Operator installed, providers added, NetworkMap/StorageMap built, NADs created (Multus), storage capacity verified
- Test migration — migrate a snapshot/copy of a representative VM in warm mode, boot it on an isolated network, verify services
- Pilot — a low-risk production box, real users, soak for a week
- Wave rollouts — batch VMs by app tier; keep rollback = power off target, power on source
- Cutover window — final sync, source off, target boot, post-boot checks (services, auth, time, monitoring agents), roll back on any blocker
- Decommission — only after the app owner signs off; consolidate snapshots, reclaim VMware resources
The source VM is your rollback until you delete it. Keep it powered off, disks intact, for the agreed retention window. Say this unprompted and you sound like someone who has done cutovers — because the candidate who plans rollback is the one the team can trust at midnight.
Questions to answer out loud
Walk me through migrating a Windows VM from vSphere to OpenShift.
MTV Operator installed → add vCenter as a Provider → define NetworkMap (vCenter network → Multus NAD) and StorageMap (datastore → StorageClass) → create a Plan, warm mode → precopy loop runs with CBT until deltas converge → cutover window: final sync, source off, target boots → verify services, auth, time sync, agents → retain source as rollback → consolidate snapshots → decommission after sign-off. Flag the Windows specifics: virtio driver injection, firmware match, firewall profiles, activation.
Warm vs cold — how do you choose?
Cold when downtime is tolerable and data is small — simpler, fewer moving parts. Warm when the app can't be down for a full copy: precopy keeps the source live, and cutover is a final sync plus boot. Warm adds operational costs: CBT reliability, snapshot management, and monitoring convergence — worth it for production, overkill for throwaway boxes.
What have you actually migrated, and what did it teach you?
This is where the Penske story goes: V2V across ESXi, VxRail, and Dell PowerFlex at 1,000+ server scale, the 50 TB NetApp → PowerScale NFS migration, and OpenShift ↔ vCenter workload moves. The lessons: dependency-map before you move (AD, DNS, time, monitoring), test the boot path early, and never delete the source until the app owner signs off. Those translate one-to-one to this migration.