OpenShift Virtualization + Windows VM Migration (MTV) — the migration half of the job

1. OpenShift Virtualization = KubeVirt, productized

  • KubeVirt on OCP (operator: "OpenShift Virtualization", GA 4.10+). Runs real VMs (QEMU/KVM) side-by-side with containers on the same cluster.
  • Architecture: VM = CRDs (VirtualMachine, VirtualMachineInstance). Each running VM = a virt-launcher POD wrapping libvirt+QEMU on the worker; virt-handler DaemonSet talks to libvirt on each node; virt-controller/virt-api for lifecycle.
  • Storage: VM disks = PVCs. DataVolume (CDI = Containerized Data Importer) imports VMDKs from vCenter, ISOs, OVAs, or registry images. Snapshots/restores via the snapshot API; hotplug supported.
  • Networking: default = pod network (masquerade/bridge). For real VLANs: Multus + NetworkAttachmentDefinition → Linux bridge (or OVS bridge/SR-IOV) on the node NIC → VM gets a macvtap/bridge interface on the actual VLAN. This is the standard way migrated Windows VMs keep their legacy IPs and L2 adjacency (AD, print, file shares, monitoring).
  • Live migration: VMIM (VM Instance Migration) moves a running VM between nodes with downtime measured in ms — enables node maintenance without app outage. HUGE selling point for the "no more SPOF / drain nodes anytime" story.
  • Node maintenance mode: marks node, live-migrates VMs off, drains pods — the workflow that makes patching painless. (They mention patching explicitly in the posting.)
  • Windows guests: needs VirtIO drivers (viostor for disk, NetKVM for NIC, virtio-win ISO), QEMU guest agent for IP reporting, sysprep for clones, UEFI + Secure Boot supported, SATA/virtio-SCSI disk types (SATA first-boot before drivers load). Windows Server 2016+ supported. Licensing = bring your own (worth asking how they handle it).

2. MTV = Migration Toolkit for Virtualization (the tool they mean by "the OpenShift migration tool")

  • Operator on the OCP cluster (forklift-controller). Provides a UI (web console) + CRDs.
  • Source providers: VMware vCenter (primary), oVirt/RHV, OpenStack, OVA files, and OCP-to-OCP.
  • Core objects:
    • Provider: source credentials/URL (vCenter user with disk access, ESXi hosts reachable for disk transfer via NBD).
    • NetworkMap: source network (VLAN/portgroup) → target NAD (bridge) or pod network.
    • StorageMap: source datastore → target StorageClass.
    • Plan: pick VMs, apply maps, choose cold vs warm, transfer network, hooks.
    • Migration: one run of a plan; phases track progress.
  • Warm migration flow (the answer to "how do you move a Windows VM?"):
    1. Full disk copy to OCP via virt-v2v conversion (VMware VMDK → KVM qcow2/raw, injects VirtIO drivers into Windows).
    2. Incremental syncs via VMware CBT (changed block tracking) — only changed blocks ship.
    3. Cutover: power off source VM → final CBT sync → boot VM on OCP → verify (IP, services, AD join).
    4. Keep source powered off for N days as rollback (power it back on = instant rollback while storage intact).
  • Cold migration = same, but VM is powered off for the whole copy (simpler, longer outage).
  • virt-v2v is the engine under the hood — name it. It also does the Windows driver injection (virtio-win) and VMX→libvirt domain translation.
  • Gotchas to mention (credibility):
    • ESXi hosts must be reachable from the MTV controller for NBD disk reads; use a dedicated transfer network (they have BGP fabrics — could even use a separate VLAN/NAD).
    • Windows VMs: static IPs via guest agent or sysprep; MAC address preservation via NAD config if the app/license keys on MAC.
    • Disk types: avoid raw device mappings (RDM) — convert to VMDK first; thick vs thin provisioning maps to StorageClass.
    • Snapshots: CBT needs recent vSphere versions; vCenter permissions need proper roles (storage + VM power ops).
    • After migration: install/verify qemu-ga, VirtIO drivers, set time sync (KVM clock), remove VMware Tools.

3. Migration strategy at Proforma scale (the "how would you approach it" answer)

Frame it as phases — hiring managers love a phased plan:

  1. Discovery/assessment: inventory Windows VMs (NinjaOne gives you the estate), map apps, owners, dependencies (AD auth? SQL? file shares? VLANs?). MTA (Migration Toolkit for Applications) for app-level analysis if they're containerizing instead of lift-and-shift.
  2. Target design: NADs for required VLANs, StorageClasses (NFS/iSCSI/LVM — matches posting), resource sizing (CPU/RAM overcommit policy, node capacity), backup strategy (Velero/OADP + snapshot).
  3. Pilot: pick 2-3 low-risk VMs (internal tools first, not ProVision on day one), run MTV warm plans, document network/OS gotchas.
  4. Waves: batch by dependency group — DB/backend first or last depending on app (classic: move app VMs, keep DB on-prem initially if latency-sensitive; or same-wave if colocated). Each wave: rehearsal cutover in a maintenance window, real cutover with rollback.
  5. Parallel hardening: as each VM lands, apply RHEL/SELinux/firewall baselines, NetworkPolicy default-deny, EgressFirewall.
  6. Decommission: power down source VMs, reclaim vSphere capacity, update IPAM/DNS, remove from NinjaOne scope as appropriate.

The "not just keep-the-lights-on" framing: they're mid-migration and one person owns it. Position yourself as the person who makes the migration boring: runbooks per wave, automated pre-checks (Ansible — your strength), rollback scripts tested before each cutover.

4. Windows/Linux hybrid reality (they run both — say the right thing)

  • AD stays: identity for OCP via LDAP bind or Entra ID/OIDC (your resume: LDAP/winbind + Entra SAML experience = direct match).
  • Windows VMs that get containerized: usually .NET/IIS apps — modernize to containers where ROI exists, lift-and-shift into KubeVirt where not. Both paths are valid; ask what their mix is.
  • DNS/AD-integrated zones must keep working during the migration — plan SRV records, join new VMs to the domain, Kerberos/clock skew (NTP!) or auth breaks.

5. Quick self-test

  • "What's the difference between OpenShift Virtualization and OVN-Kubernetes?"

(Virtualization = KubeVirt, runs VMs as pods. OVN-K = the CNI/SDN providing pod networking. They interact — a VM can attach to pod network or host bridges via NAD — but they're separate components.)

  • "How does MTV keep downtime low?"

(Warm migration: full copy + CBT incremental syncs while source keeps running; cutover = final sync + boot on OCP.)

  • "How do migrated Windows VMs keep their IPs?"

(Bridge NAD on the original VLAN; static IP via sysprep/unattend or guest agent; optionally MAC preservation.)

  • "What happens when you patch an OCP node hosting VMs?"

(Node maintenance mode → live migration to another node → zero-downtime patching. This is the redundancy story they're hiring for.)