OpenShift Migration Toolkit for Virtualization with FlashArray

Migration Objective and Scope

The objective of this migration is to transition virtual machine workloads from VMware vSphere to Red Hat OpenShift Virtualization while preserving the existing Everpure FlashArray storage investment and maintaining data availability throughout the transition.

• Migration of VM workloads from ESXi to KubeVirt on worker nodes
• iSCSI, NVMe/TCP, and Fibre Channel transport validation
• Forklift (MTV) with Everpure XCopy Offload
• VMware and OpenShift coexistence
• Day 2 operations (monitoring, DR, backup, scaling)

Role of Everpure in Accelerating Migration

• VMware and OpenShift share the same FlashArray
• Enables hardware-assisted data movement using XCopy offload (VMFS)

• Enables full offload of the migration to the array with volume copy (vVols and RDMs)

• Eliminates dependency on host-based data transfer (VDDK bottlenecks)
• Reduces CPU, memory, and network utilization during migration
• Provides consistent storage performance across source and target environments
• Portworx creates volumes via FlashArray API
• Portworx maps them to OpenShift nodes
• Portworx presents storage via multipath

Key Outcomes and Performance Highlights

• Significant reduction in migration time using FlashArray offload
• Improved scalability for VM migrations
• Consistent performance across different VM sizes and storage types
• Reduced infrastructure overhead during migration execution

Migration Architecture Overview

This section describes the complete technical architecture of the migration — the source VMware environment, the target OpenShift Virtualization platform, the FlashArray storage integration, the migration tooling, and the end-to-end data flow.

Source Environment: VMware vSphere

The source environment is a standard VMware vSphere deployment in which ESXi hosts run virtual machine workloads under vCenter management. Storage is provided by Everpure FlashArray, accessed by ESXi hosts via iSCSI or Fibre Channel. Datastores are configured as VMFS or vVols, both backed directly by FlashArray volumes. Currently the xcopy and vol copy offload is a SCSI and Block only integration.

vCenter as the Migration Source

MTV connects to vCenter as the source provider. It uses the vCenter inventory API to discover VMs, their disk configurations, network port group assignments, and datastore mappings. When XCopy Offload is configured, Forklift also retrieves the FlashArray volume identifiers corresponding to the VMware datastores, enabling it to issue the correct XCOPY commands to FlashArray.

Target Platform: OpenShift Virtualization

OpenShift Virtualization extends Red Hat OpenShift with KubeVirt to enable virtual machines to run as Kubernetes-native workloads. VMs are defined as Kubernetes Custom Resources (VirtualMachine objects) and scheduled alongside containerised pods on RHCOS worker nodes.

KubeVirt and the virt-launcher Architecture

Each running VM in OpenShift Virtualization is backed by a virt-launcher pod on the worker node. This pod runs a QEMU/KVM process that provides hardware-accelerated virtualisation. From the Kubernetes scheduler's perspective, a VM is a pod with specific resource requests — it is scheduled, monitored, evicted, and rescheduled using the same mechanisms as any other Kubernetes workload.

RHCOS Worker Nodes and MachineConfig

All OpenShift worker nodes run RHCOS (Red Hat CoreOS), an immutable operating system managed by the Machine Config Operator (MCO). Direct OS modifications are not persistent — all configuration must be applied via MachineConfig objects, which the MCO applies via a controlled rolling reboot process.

This is the key difference from VMware ESXi host configuration. In VMware, a storage administrator configures iSCSI initiators or FC HBAs directly on each host. In OpenShift, the equivalent configuration is declared in a MachineConfig manifest and applied automatically to all worker nodes in the pool.

Storage Architecture: FlashArray Integration

FlashArray serves as the unified storage backend for both environments simultaneously throughout the migration. Storage integration operates at two levels: the management plane (Portworx communicates with the FlashArray REST API for volume lifecycle operations) and the data plane (worker nodes connect via iSCSI, NVMe/TCP, or FC for block I/O).

Management Plane: Portworx with FlashArray REST API

• Portworx connects to FlashArray using an API token stored in the px-pure-secret Kubernetes Secret.
• When a PVC is created, Portworx calls the FlashArray REST API to provision a new volume of the requested size.
• Portworx automatically creates a host object on FlashArray for each worker node, using the node's IQN, NQN, or WWPN as the identity, and adds the host to the managed host group.
• When a PVC is deleted, Portworx disconnects and deprovisions the FlashArray volume via the REST API.

Data Plane: Worker Node with FlashArray SAN Transport

• The data plane connection depends on the chosen SAN transport. All three transports result in the same logical device at the Portworx layer — a dm-multipath block device — but differ in how the connection is established and verified.

Migration Tooling: Migration Toolkit for Virtualization (MTV / Forklift)

Forklift orchestrates VM migrations through a set of Kubernetes Custom Resources (CRs). Each migration is defined declaratively — the engineer creates YAML manifests describing the source, the target, and the mapping between them, then applies them to the cluster. Forklift's controller reads these CRs and executes the migration.

XCopy Offload vs. VDDK: Architecture Difference

Test Environment and Lab Setup

Infrastructure Overview (Compute, Network, Storage)

VMware Source Configuration

OpenShift Cluster Configuration

FlashArray Configuration

Network Topology and Connectivity

SCSI-FC

iSCSI

Test Workload Profiles

Three VM profiles were used in the engineering lab migration testing. Each profile exercises different aspects of the migration tooling — disk count, disk size, OS type, and data density. All test VMs were created by cloning from pre-built base images using standard VMware cloning operations.

Random data was generated using:

dd if=/dev/urandom of=/mnt/disk1/random_file.img bs=1G count=<N>

For shared RDM testing, 6 instances of the Large-Disk Linux VM were deployed with two 1 TB shared RDM volumes configured in physical compatibility mode with multi-writer sharing — representing a clustered application with shared storage.