Stop VMs Before Platform RollbackΒΆ

About this task

If the KubeVirt application is installed and VMs are running, you must stop all the VMs before performing a platform rollback (software deploy activate-rollback). Otherwise, the KubeVirt virt-handler will not be able to manage the running VMs, causing live migration failures and VM management errors.

During a platform rollback, the kubevirt-app Helm chart is downgraded to the version shipped with the target release. KubeVirt does not support downgrades while VMs are running. The older virt-handler binary cannot manage VMs that were started by a newer version. This results in virt-handler entering a requeue loop, preventing it from orchestrating live migrations or managing any VM on affected nodes.

Procedure

  1. List all the running VMs.

    $ kubectl get vmi --all-namespaces

  2. Stop each running VM.

    $ virtctl stop <vm-name> -n <namespace>

    Repeat for every VM shown in the previous step.

  3. Confirm that there is no more active VM instances.

    $ kubectl get vmi --all-namespaces

    The command should return no resources. Only VMs should be in the Succeeded or Failed phase.

  4. Proceed with the platform rollback.

    $ software deploy activate-rollback

  5. After the activate-rollback completes, restart VMs.

    $ virtctl start <vm-name> -n <namespace>

    Note

    VMs configured with runStrategy: Always will restart automatically after the rollback completes. You only need to manually restart VMs that use runStrategy: Manual or runStrategy: RerunOnFailure.

  6. Initiate host rollbacks. Ensure that active VMs are live-migrated away from the target host prior to the rollback to avoid further downtime.

Results

The platform rollback completes successfully and VMs can be restarted on the rolled-back release without live migration or management failures.