VM Lifecycle Operations

Starting and Stopping VMs

Starting and stopping virtual machines is the most common Day 2 task for virtualization administrators. In OpenShift Virtualization, this is handled through the OpenShift console.

This task is used to:

• power on a stopped VM

• gracefully stop a running VM

• confirm that VM state transitions complete cleanly

• validate that the VM is ready for maintenance, patching, or recovery activity

Workflow for powering VMs on and off

1. In the OpenShift web console, go to Virtualization > VirtualMachines.

2. Select the project or namespace containing the VM.

3. Locate the VM in the list view.

4. Review the current VM state before taking action.

5. To start a stopped VM: open the action menu for the VM and select Start.

6. To stop a running VM: open the action menu for the VM and select Stop.

7. Open the VM details page and monitor the state transition.

8. Review associated resources: VirtualMachineInstance, launcher pod state, attached storage, network status.

9. Confirm the VM reaches the expected final state.

Safe shutdown considerations for production workloads

For production workloads, stop operations should always be treated as application-impacting unless the owner has confirmed that the guest can be safely stopped.Before stopping a production VM:

1. Confirm whether application owners have approved downtime

2. Verify there is no active backup, migration, or restore task in progress

3. Confirm the VM is not hosting a clustered role that requires coordination

4. If possible, use a guest-aware shutdown path rather than an abrupt power-off pattern

If the guest operating system is unresponsive, treat the stop as a recovery action rather than routine maintenance.

• Verifying VM state transitions

After starting or stopping a VM, verify more than just the icon in the list view.

For a successful start:

• The VM should transition to running

• The VirtualMachineInstance should appear healthy

• The launcher pod should be created successfully

• Attached storage should be visible and mounted as expected

• Guest boot should complete without storage or network-related errors

For a successful stop:

• The VirtualMachineInstance should terminate cleanly

• No stale migration or attachment task should remain

• The VM object should show the intended stopped state

Live Migration Between Compute Nodes

Live migration between compute nodes is the OpenShift Virtualization equivalent of vMotion. It allows a running VM to move from one worker node to another with minimal disruption, provided the environment is correctly configured.

This is a key operational workflow for host maintenance, workload rebalance, infrastructure patching, and disruption avoidance

This task is used to:

• Evacuate VMs from a node before maintenance

• Rebalance workloads across worker nodes

• Test mobility and cluster readiness

• Reduce downtime during infrastructure changes

GUI Workflow for live migration between nodes

1. In the OpenShift web console, go to Virtualization > VirtualMachines.

2. Select the namespace that contains the VM.

3. Open the VM details page.

4. Confirm the VM is currently running.

5. Open the Actions menu.

6. Select Migrate.

7. Monitor the migration status from the VM details page.

8. Review the migration object or status panel and confirm: migration begins successfully, the VM transitions to the new node, no warning or error is raised during execution.

9. After migration completes, confirm the VM is running on the target node.

Preconditions and validation steps

Before initiating live migration, confirm:

• the VM is configured in a way that supports migration

• the source and destination nodes are healthy

• the VM's storage supports the migration workflow

• no active storage or network issue is affecting the VM

• Portworx and backend storage are healthy if the VM depends on shared or migratable storage

After migration completes, validate:

• the VM is running on the new node

• guest connectivity is intact

• attached volumes remain healthy

• application responsiveness is normal

• no hidden degradation has been introduced at the storage or network layer

Live Migration Between Storage Classes

Moving a VM between storage classes is the OpenShift-oriented equivalent of storage vMotion. This allows administrators to reposition a workload onto a different storage policy for protection, performance, availability, or operational alignment reasons.

Examples include moving a VM to a storage class backed by a different FlashArray policy, shifting from a standard tier to an ActiveCluster-backed class, or moving to a class more appropriate for recovery and snapshot operations.

This task is used to:

• reposition VMs onto a new storage service level

• align workloads to the correct protection model

• improve performance or locality

• support migration from older classes to newer operational standards

GUI workflow for moving a VM between storage classes

In practice, the exact workflow depends on how the VM disk is provisioned and whether the target storage class supports the desired movement pattern. The OpenShift GUI is still the primary control surface for managing the VM and its associated PVCs.

1. In the OpenShift web console, go to Virtualization > VirtualMachines.

2. Open the target VM and identify the attached disks and PVCs.

3. Determine which disk or PVC needs to move to a different storage class.

4. Use the appropriate GUI-driven clone, snapshot, or restore workflow to recreate the disk on the target storage class.

5. Attach the new disk or replace the original boot or data disk using the appropriate VM edit workflow.

6. Validate the VM after the storage move is complete.

Because this is more policy-driven than compute migration, administrators should treat it as a controlled storage relocation workflow rather than a one-click hypervisor operation.

Validating data placement and application impact

After the storage movement is complete, confirm:

1. The VM is now backed by the intended storage class

2. The workload is attached to the correct PVCs

3. The expected protection or performance profile is now in effect

4. The guest operating system sees the expected disk state

5. Applications start and operate normally

For critical workloads, validate both function and placement. A successful VM boot alone does not confirm that the VM is using the intended storage policy.

VM Template Creation and Boot ISO on FlashArray

Reusable templates are essential for consistent VM deployment, standardization, and lifecycle governance. In OpenShift Virtualization, templates provide a controlled way to present CPU, memory, disk, and operating system combinations to users and administrators. When boot media and base images are hosted on FlashArray-backed storage, template operations also benefit from the performance, consistency, and data services of the underlying platform.

This task is used to:

• standardize new VM creation

• reduce manual build variation

• host base images and boot media on enterprise storage

• simplify repeatable provisioning workflows for infrastructure and application teams

Creating reusable VM templates in OpenShift Virtualization

Administrators should build templates from known-good golden images rather than from ad hoc running workloads. The preferred model is to prepare an approved source VM or imported image, validate it, and then publish it as a reusable template for ongoing deployment.

1. Go to Virtualization > Templates.

2. Review the available templates and identify whether an existing template can be reused or cloned.

3. If building a new template from a prepared VM, first confirm the source VM is in a clean and approved state.

4. Create or clone the template using the GUI workflow provided in the Virtualization console.

5. Populate metadata such as: operating system, workload type, sizing guidance, ownership or support notes.

6. Validate that the template references the intended storage and boot source.

Publish the template only after confirming that it aligns with platform standards.

Hosting boot media and images on FlashArray-backed storage

Boot ISOs, golden images, and reusable VM sources should be placed on storage classes that provide predictable performance and operational consistency. In FlashArray-backed environments, this helps ensure that image imports, clone workflows, and VM creation tasks do not depend on fragmented or unmanaged storage placement.

Operationally, image and ISO storage should support:

• repeatable VM provisioning

• fast clone or restore behavior

• consistent backup and snapshot handling

• controlled lifecycle management

VM Recovery from Snapshot

Snapshot-based recovery provides a fast way to return a VM or its backing disk to a known earlier state. In OpenShift Virtualization, this is particularly useful for operational rollback, application recovery, test validation, and incident response. However, snapshot recovery should be used deliberately, because it changes the state of the workload and may overwrite newer data if used incorrectly.

This task is used to:

• Recover a VM to a known good point in time

• Reverse failed changes or patching activity

• Validate rollback procedures

• Restore service quickly after workload corruption or misconfiguration

GUI workflow to recover a VM from a point-in-time snapshot

1. In the OpenShift web console, go to Virtualization > VirtualMachines.

2. Select the namespace containing the VM.

3. Open the VM details page.

4. Review the Snapshots or related recovery view for the VM.

5. Identify the snapshot that represents the intended recovery point.

6. Confirm the timestamp and context of that snapshot before proceeding.

7. Initiate the restore or recovery workflow from the GUI.

8. Monitor the restore status and wait for completion.

9. After the restore completes, confirm the VM is returned to the expected operational state.

Validation after restore

After recovery, validate:

• the VM starts or remains accessible as expected

• the restored disks are correctly attached

• guest applications reflect the intended recovery point

• networking and application dependencies still function

• no unintended storage or attachment issue was introduced

For business-critical workloads, recovery should be validated by function, not just by a successful task completion state.

Undeleting a VM

A deleted VM does not always mean the workload is unrecoverable. Recovery depends on how the VM was deleted, whether the backing PVCs or snapshots still exist, and whether a backup platform such as PX Backup is in use.

This task is used to:

• restore service after accidental VM deletion

• recover a deleted workload from surviving storage artifacts

• reconstruct a VM using snapshots, retained volumes, clones, or backups

• reduce downtime following administrative error

Recovery options when a VM has been deleted

Depending on the environment, recovery may be possible through one or more of the following:

• a surviving snapshot of the VM disk

• a cloned PVC created from a prior snapshot

• retained backing volumes that were not deleted with the VM

• a VM restore through PX Backup

• a reusable template combined with preserved application data

The correct method depends on whether only the VM object was deleted or whether its associated storage was also removed.

Using snapshots, backups, or cloned volumes to restore service

A common GUI-first recovery pattern is:

• Determine whether the deleted VM's backing PVCs still exist.

• Determine whether snapshots exist for the deleted VM or its disks.

• If backups are available, identify the most recent valid restore point.

• Recreate the VM definition using the recovered disk, cloned PVC, or restored backup.

• Attach the recovered storage to the recreated VM.

• Validate boot, storage, and application function.

If the original boot disk no longer exists, administrators may need to restore the full workload from backup or rebuild the VM definition using a template plus recovered data disks.