Chapter 6. Updating

Procedure

1. Click Ecosystem Installed Operators.
2. Select OpenShift Virtualization from the list.
3. Click the Subscription tab.
4. In the Subscription details section, click the setting that you want to change. For example, to change the approval strategy from Manual to Automatic, click Manual.
5. In the window that opens, select the new update channel or approval strategy.
6. Click Save.

Procedure

1. In the OpenShift Container Platform web console, navigate to Ecosystem Installed Operators.
2. Operators that have a pending update display a status with Upgrade available. Click the name of the Operator you want to update.
3. Click the Subscription tab. Any updates requiring approval are displayed next to Upgrade status. For example, it might display 1 requires approval.
4. Click 1 requires approval, then click Preview Install Plan.
5. Review the resources that are listed as available for update. When satisfied, click Approve.
6. Navigate back to the Ecosystem Installed Operators page to monitor the progress of the update. When complete, the status changes to Succeeded and Up to date.

Procedure

1. Delete the MigrationController custom resource (CR) on all clusters:

   $ oc delete migrationcontroller <migration_controller>

2. Uninstall the Migration Toolkit for Containers Operator on OpenShift Container Platform 4 by using the Operator Lifecycle Manager (OLM).

3. Delete cluster-scoped resources on all clusters by running the following commands:

   • migration custom resource definitions (CRDs):

     $ oc delete $(oc get crds -o name | grep 'migration.openshift.io')

   • velero CRDs:

     $ oc delete $(oc get crds -o name | grep 'velero')

   • migration cluster roles:

     $ oc delete $(oc get clusterroles -o name | grep 'migration.openshift.io')

   • migration-operator cluster role:

     $ oc delete clusterrole migration-operator

   • velero cluster roles:

     $ oc delete $(oc get clusterroles -o name | grep 'velero')

   • migration cluster role bindings:

     $ oc delete $(oc get clusterrolebindings -o name | grep 'migration.openshift.io')

   • migration-operator cluster role bindings:

     $ oc delete clusterrolebindings migration-operator

   • velero cluster role bindings:

     $ oc delete $(oc get clusterrolebindings -o name | grep 'velero')

Procedure

1. To open the HyperConverged CR in your default editor, run the following command:

   $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv

2. Edit the workloadUpdateStrategy stanza of the HyperConverged CR. For example:

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     workloadUpdateStrategy:
       workloadUpdateMethods:
       - LiveMigrate
       - Evict
       batchEvictionSize: 10
       batchEvictionInterval: "1m0s"
   # ...

   • spec.workloadUpdateStrategy.workloadUpdateMethods defines the methods that can be used to perform automated workload updates. The available values are LiveMigrate and Evict. If you enable both options as shown in this example, updates use LiveMigrate for VMIs that support live migration and Evict for any VMIs that do not support live migration. To disable automatic workload updates, you can either remove the workloadUpdateStrategy stanza or set workloadUpdateMethods: [] to leave the array empty.

     • LiveMigrate is the least disruptive update method. VMIs that support live migration are updated by migrating the virtual machine (VM) guest into a new pod with the updated components enabled. If LiveMigrate is the only workload update method listed, VMIs that do not support live migration are not disrupted or updated.
     • Evict is a disruptive method that shuts down VMI pods during upgrade. Evict is the only update method available if live migration is not enabled in the cluster. If a VMI is controlled by a VirtualMachine object that has runStrategy: Always configured, a new VMI is created in a new pod with updated components.
   • spec.workloadUpdateStrategy.batchEvictionSize defines the number of VMIs that can be forced to be updated at a time by using the Evict method. This does not apply to the LiveMigrate method.

   • spec.workloadUpdateStrategy.batchEvictionInterval defines the interval to wait before evicting the next batch of workloads. This does not apply to the LiveMigrate method.

     Note

     You can configure live migration limits and timeouts by editing the spec.liveMigrationConfig stanza of the HyperConverged CR.

3. To apply your changes, save and exit the editor.

Procedure

1. Run the following command and record the workloadUpdateMethods configuration:

   $ oc get kv kubevirt-kubevirt-hyperconverged \
     -n openshift-cnv -o jsonpath='{.spec.workloadUpdateStrategy.workloadUpdateMethods}'

2. Disable workload update methods by running the following command:

   $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
     --type json -p '[{"op":"replace","path":"/spec/workloadUpdateStrategy/workloadUpdateMethods", "value":[]}]'

3. Ensure that the HyperConverged Operator is Upgradeable before continuing:

   $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"

4. Manually update your cluster from the source EUS version to the next minor version of OpenShift Container Platform:

   $ oc adm upgrade

5. Verify the current cluster version:

   $ oc get clusterversion

   Note

   Updating OpenShift Container Platform to the next version is a prerequisite for updating OpenShift Virtualization. For more details, see the "Updating clusters" section of the OpenShift Container Platform documentation.

6. Update OpenShift Virtualization.

   • With the default Automatic approval strategy, OpenShift Virtualization automatically updates after the OpenShift Container Platform update completes.
   • If you use the Manual approval strategy, approve the pending update in the web console.

7. Monitor the OpenShift Virtualization update:

   $ oc get csv -n openshift-cnv

8. Confirm that OpenShift Virtualization updated to the latest z-stream release of the intermediate version:

   $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"

9. Wait until the HyperConverged Operator again reports the Upgradeable condition.
10. Update OpenShift Container Platform to the target EUS version.

11. Verify the cluster version:

    $ oc get clusterversion

12. Update OpenShift Virtualization to the target EUS version.

    • With the default Automatic approval strategy, OpenShift Virtualization updates automatically.
    • If you use the Manual approval strategy, approve the pending update in the web console.

13. Monitor the update:

    $ oc get csv -n openshift-cnv

    The update completes when the VERSION field matches the target EUS version and the PHASE field reads Succeeded.

14. Restore the workloadUpdateMethods configuration recorded in step 1:

    $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p \
    "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":{WorkloadUpdateMethodConfig}}]"