Storage Scale Lab Migration

Storage Scale lab migration networkBohr VMware migrates through MTV to Erdos345. After evacuation Bohr is rebuilt for OpenShift Virtualization, then workloads relocate back. Management uses documented VLAN 72. The proposed high-speed storage path targets 100 GbE with 40 GbE fallback; VLAN 803 is a candidate pending confirmation. Temporary VMware workloads on Erdos01–02 must be resolved before VMware retirement.1VMware sourceBohr01–032Pilot + wavesErdos03–053Rebuild + relocateBohr01–034VMware exitZero dependenciesOpenShift VirtualizationOpenShift VirtualizationMTVOnce Bohris emptyAfteracceptanceVLAN 72 · ManagementScale storage + high-speed network100 GbE target / 40 GbE fallbackVLAN choice: confirm with JohnRelocate workloads to BohrResolve temporary VMware on Erdos01–02Retire ESXi + vCenterDate TBD

Timeline

SetupPilotReserve
Technical steps

Rehost the VMs. Keep the applications; move them onto OpenShift Virtualization. Red Hat: rehosting

Before W1 Subscription + readiness

  • Bring Dr. Todd’s Red Hat account into the ATG organization and secure an ongoing OpenShift subscription—transfer existing coverage if eligible, or assign ATG coverage to his account.
  • If cluster ownership changes, initiate the transfer in OpenShift Cluster Manager, then update the global pull secret. Confirm registration and coverage before the trial expires. Red Hat: ownership transfer
  • Choose 3–5 pilot VMs, owners, downtime and acceptance criteria. Confirm supported OpenShift, Virtualization, MTV, VMware and Scale/CSI versions.

W1 · 2–3 days Inventory + health

  • Inventory VM owners, dependencies, OS, CPU/RAM, disks, networks and firmware. Flag encryption, shared disks, passthrough devices and unsupported guests.
  • Check Erdos03–05 health, virtualization support, available capacity and failure headroom.
  • Validate VMware permissions and guest support. Warm migration needs VMware Tools and changed-block tracking on each VM and its disks. Red Hat: provider requirements

W1–2 · 2–5 days Network configuration

  • With John Bernatz, confirm NICs, switch ports, cabling, VLANs, routing and MTU for 100 GbE—or 40 GbE. VLAN 72 serves management; VLAN 803 remains a candidate.
  • Measure end-to-end transfer speed. Check ESXi, datastore reads and any remaining 1 GbE bottleneck; VLAN choice alone does not set speed.
  • Prepare guest networks and the migration-transfer path. Validate DNS/NTP, retained addresses, vCenter TCP 443 and ESXi TCP 443/902. Freeze VM IP/VLAN changes during migration. Red Hat: software and network requirements

W1–2 · 3–5 days Storage + Virtualization

  • With Dr. Todd, validate Scale/CSI support, StorageClass, volume/access modes, capacity and performance.
  • Install or verify OpenShift Virtualization. Boot a test VM using the intended storage and guest network.
  • Prove required VM mobility, snapshots and backup/restore with the selected storage class.

W2 · 0.5–1 day Install MTV

  • Install the supported MTV Operator and controller instance; verify migration services and console integration.
  • Provide a private VDDK image: required for warm migration and vSAN; recommended for other cold VMware migrations. Red Hat: VMware migration planning

W2–3 · 2–3 days Providers + mappings

  • Connect: add VMware/vCenter as the source; select Erdos and the destination namespace. Verify credentials, certificates, permissions and provider readiness.
  • Map: datastores → StorageClasses; source networks → target networks. Confirm quota, capacity and the transfer network.
  • Plan: select pilot VMs, choose the migration mode and resolve validation warnings. Red Hat: providers and mappings
  • Convert: VMDK → MTV / virt-v2v → PVC-backed VM disks. MTV adjusts boot configuration and VirtIO drivers; manual QCOW2 export is normally unnecessary. Keep guest conversion enabled and verify guest agents afterward. Red Hat: conversion workflow

W3–4 · 3–5 days + copying Pilot + application tests

  • Cold: power off for transfer and conversion. Warm: pre-copy while running, then stop for final synchronization and cutover. Both require an outage.
  • Avoid new VMware snapshots and vMotion/storage vMotion during migration. Watch transfer/conversion logs. Red Hat: running a VMware migration
  • Test boot, disks, networking, authentication, applications and performance. Check Windows VSS/quiescing prerequisites. Red Hat: guest prerequisites
  • Record throughput, copy/conversion time and outage; use these measurements to size later waves.

W4 · 2–3 days Recovery + acceptance

  • Test restore, restart/recovery and required VM mobility; obtain application-owner acceptance.
  • Retain the source for rollback, but prevent duplicate IPs and competing writers. After destination writes begin, rollback needs a data-reconciliation plan.
  • Use W5–6 for fixes if needed. Approve the pilot runbook and wave inventory before scaling up.

After pilot · dates TBD Waves → rebuild → full exit

  • Migrate waves: move dependent VM groups to Erdos; check capacity and obtain acceptance per wave. Update VMware-dependent Ansible workflows in parallel.
  • Rebuild Bohr: first move all workloads and dependencies off Bohr and prove recovery. Then install and validate OpenShift, storage and networking.
  • Relocate: prove a supported OpenShift-to-OpenShift migration method, then move workloads from Erdos to Bohr.
  • Retire VMware: resolve Erdos01–02 exceptions and all remaining VM, automation and backup dependencies before removing ESXi/vCenter.

Network and storage preparation run in parallel; both must be ready before the pilot. Estimates assume subscriptions, hardware and a healthy cluster are ready. Days indicate effort; bars show work windows. Calendar dates are illustrative, exclude weekends and omit holidays. Full exit remains TBD. Match the linked MTV 2.12 guidance to the installed release.