Completing the migration of virtual machines to OpenShift Virtualization marks the beginning of a new operational phase. This page addresses the validation, benchmarking, Day-2 operations, observability, and data protection practices that ensure migrated workloads perform reliably in their new environment.
Validation and Testing
Post-migration validation should be executed systematically for every migrated VM before it is considered production-ready. A structured validation checklist prevents premature promotion of VMs that have undetected configuration or connectivity issues
| Validation Item | Procedure | Pass Criteria |
|---|---|---|
| VM Boot Completion | Console access via OpenShift Virt UI or virtctl | OS prompt available, no kernel panic |
| Network Connectivity | Ping gateway and DNS from inside VM | < 1 ms RTT to gateway, DNS resolves |
| Persistent Volume Mount | df -h or disk management tools inside VM | All expected volumes mounted with correct size |
| Application Service Health | Application-specific health check (HTTP endpoint, service status) | Service responds within SLA threshold |
| VirtIO Driver Status | lspci or device manager inside VM | VirtIO disk and network adapters present |
| Time Sync | timedatectl or chronyc tracking | Offset < 100 ms, NTP synchronized |
| Log Integrity | Review system logs for boot errors | No critical errors in dmesg / Event Log |
For large-scale migrations, manual validation becomes a bottleneck. Consider deploying automated post-migration tests using Ansible playbooks that run the validation checklist programmatically after each Forklift plan completes
Day-2 Operations on OpenShift
Operational practices that were native to VMware have equivalents in OpenShift Virtualization and the broader Red Hat ecosystem. The following table maps common Day-2 tasks from VMware to their OpenShift equivalents
| VMware Operation | OpenShift Equivalent | Tooling |
|---|---|---|
| vMotion (live migrate VM) | Live Migration | virtctl migrate <vm> |
| VM Snapshot | VolumeSnapshot (CSI) | oc create volumesnapshot |
| VM Clone | VirtualMachine clone (DataVolume) | CDI DataVolume with pvc source |
| VM Power Off | Stop VM | virtctl stop <vm> |
| vSphere HA Restart | VM Pod Restart / KubeVirt watchdog | Pod restart policy + liveness probe |
| Resource Pools | Namespaces + LimitRange + ResourceQuota | oc apply resourcequota |
| DRS / Placement | Node Affinity / Anti-Affinity rules | VM spec nodeSelector / affinity |
| VDS / Port Groups | NetworkAttachmentDefinitions (Multus) | NAD + CNI plugins (OVN, SR-IOV) |
| vSphere Tags | Kubernetes Labels / Annotations | oc label / oc annotate |
VM Live Migration Policy
OpenShift Virtualization supports live migration of VMs across nodes, analogous to vMotion. Live migration requires the VM to have a ReadWriteMany (RWX) or Block (RWX block) PVC. Everpure FlashArray CSI supports block RWX volumes via iSCSI multipath, enabling live migration across nodes without shared filesystem dependencies. Configure MigrationPolicy resources to define per-namespace migration bandwidth limits and completion timeouts for live migration operations.
Monitoring and Observability
Comprehensive observability is critical post-migration to detect performance regressions, resource exhaustion, and infrastructure anomalies before they impact production workloads.
OpenShift Monitoring Stack
OpenShift includes a built-in monitoring stack based on Prometheus and Alertmanager. Post-migration, enable user workload monitoring to extend metrics collection to migrated VMs and the namespaces they reside in. Key metrics to monitor for migrated workloads include:
| Metric | Source | Alert Threshold (Recommended) |
|---|---|---|
| kubevirt_vmi_vcpu_wait_seconds_total | KubeVirt | > 5% sustained CPU ready |
| kubevirt_vmi_storage_iops_read_total | KubeVirt | Compare vs baseline ±20% |
| kubevirt_vmi_storage_write_times_ms_total | KubeVirt | > 2× baseline P99 |
| purestorage_array_performance_write_latency_usec | Everpure Exporter | > 1000 µs sustained |
| container_memory_usage_bytes (conversion pods) | cAdvisor | OOM kill rate = 0 |
| node_disk_io_time_seconds_total | Node Exporter | Saturation > 80% |
Configure OpenShift user workload monitoring and set Portworx/PX-CSI to export metrics to OpenShift Prometheus rather than deploying a separate Prometheus instance. This allows storage performance metrics such as IOPS, throughput, and latency to be visualized alongside Kubernetes and application telemetry in Grafana/OpenShift, improving cross-layer correlation and troubleshooting from a common observability stack
Grafana Dashboards
For OpenShift-integrated monitoring, deploy the pre-built Portworx Grafana dashboards provided in the Portworx documentation, and optionally add the FlashArray API dashboards if FlashArray API monitoring is needed. These dashboards provide cluster-, node-, volume-, and performance-level views within the same Grafana environment used for OpenShift observability
Backup and Disaster Recovery
CSI Volume Snapshots
Post-migration VMs store disk data in PVCs backed by Portworx / Everpure CSI. The platform supports CSI Volume Snapshots through the Kubernetes VolumeSnapshot API and a configured VolumeSnapshotClass. Snapshot creation can be automated using a backup platform policy or custom automation that creates VolumeSnapshot objects on a schedule. FlashArray snapshots are generally space-efficient, making them suitable for frequent crash-consistent recovery points.
Kasten K10 Integration
For enterprise backup orchestration, Kasten K10 integrates with OpenShift Virtualization / KubeVirt and CSI-based storage to provide policy-driven backup, restore, DR, and application mobility for VM workloads. K10 can protect VM disks together with relevant Kubernetes objects such as resource manifests, ConfigMaps, and secrets, and can export backup data to external targets such as S3-compatible object storage depending on configuration.
High Availability and Disaster Recovery
For zero-RPO VM workloads, Everpure ActiveCluster - not ActiveDR - is the supported synchronous replication technology on FlashArray. In the OpenShift / KubeVirt context, ActiveCluster is documented for FlashArray Direct Access (FADA) volumes and is specifically called out as useful for stateful VM workloads using shared raw block volumes. By contrast, ActiveDR is a near-synchronous, snapshot-based DR feature with seconds of lag, making it appropriate for low-RPO DR designs but not RPO-zero