Virtualization

Procedure

1. Navigate to the Virtualization → Overview page in the web console.
2. Click the Download virtctl link to download the virtctl binary for your operating system.

3. Install virtctl:

   • For RHEL 9 and other Linux operating systems:

     1. Decompress the archive file:

        $ tar -xvf <virtctl-version-distribution.arch>.tar.gz

        Copy to Clipboard Toggle word wrap

     2. Run the following command to make the virtctl binary executable:

        $ chmod +x <path/virtctl-file-name>

        Copy to Clipboard Toggle word wrap

     3. Move the virtctl binary to a directory in your PATH environment variable.

        You can check your path by running the following command:

        $ echo $PATH

        Copy to Clipboard Toggle word wrap

     4. Set the KUBECONFIG environment variable:

        $ export KUBECONFIG=/home/<user>/clusters/current/auth/kubeconfig

        Copy to Clipboard Toggle word wrap

   • For Windows:

     1. Decompress the archive file.
     2. Navigate the extracted folder hierarchy and double-click the virtctl executable file to install the client.

     3. Move the virtctl binary to a directory in your PATH environment variable.

        You can check your path by running the following command:

        C:\> path

        Copy to Clipboard Toggle word wrap

   • For macOS:

     1. Decompress the archive file.

     2. Move the virtctl binary to a directory in your PATH environment variable.

        You can check your path by running the following command:

        echo $PATH

        Copy to Clipboard Toggle word wrap

Procedure

1. Enable the OpenShift Virtualization repository by using the subscription-manager CLI tool to run the following command:

   # subscription-manager repos --enable cnv-4.19-for-rhel-8-x86_64-rpms

   Copy to Clipboard Toggle word wrap

2. Install the kubevirt-virtctl package by running the following command:

   # yum install kubevirt-virtctl

   Copy to Clipboard Toggle word wrap

Procedure

1. From the Administrator perspective, click Operators → OperatorHub.
2. In the Filter by keyword field, type Virtualization.
3. Select the OpenShift Virtualization Operator tile with the Red Hat source label.
4. Read the information about the Operator and click Install.

5. On the Install Operator page:

   1. Select stable from the list of available Update Channel options. This ensures that you install the version of OpenShift Virtualization that is compatible with your Red Hat OpenShift Service on AWS version.

   2. For Installed Namespace, ensure that the Operator recommended namespace option is selected. This installs the Operator in the mandatory openshift-cnv namespace, which is automatically created if it does not exist.

      Warning

      Attempting to install the OpenShift Virtualization Operator in a namespace other than openshift-cnv causes the installation to fail.

   3. For Approval Strategy, it is highly recommended that you select Automatic, which is the default value, so that OpenShift Virtualization automatically updates when a new version is available in the stable update channel.

      While it is possible to select the Manual approval strategy, this is inadvisable because of the high risk that it presents to the supportability and functionality of your cluster. Only select Manual if you fully understand these risks and cannot use Automatic.

      Warning

      Because OpenShift Virtualization is only supported when used with the corresponding Red Hat OpenShift Service on AWS version, missing OpenShift Virtualization updates can cause your cluster to become unsupported.

6. Click Install to make the Operator available to the openshift-cnv namespace.
7. When the Operator installs successfully, click Create HyperConverged.
8. Optional: Configure Infra and Workloads node placement options for OpenShift Virtualization components.
9. Click Create to launch OpenShift Virtualization.

Procedure

1. Navigate to the Operators → Installed Operators page.
2. Select the OpenShift Virtualization Operator.
3. Click the OpenShift Virtualization Deployment tab.
4. Click the Options menu beside kubevirt-hyperconverged and select Delete HyperConverged.
5. Click Delete in the confirmation window.

Procedure

1. Navigate to the Operators → Installed Operators page.
2. Scroll or enter a keyword into the Filter by name field to find the Operator that you want to remove. Then, click on it.

3. On the right side of the Operator Details page, select Uninstall Operator from the Actions list.

   An Uninstall Operator? dialog box is displayed.

4. Select Uninstall to remove the Operator, Operator deployments, and pods. Following this action, the Operator stops running and no longer receives updates.

   Note

   This action does not remove resources managed by the Operator, including custom resource definitions (CRDs) and custom resources (CRs). Dashboards and navigation items enabled by the web console and off-cluster resources that continue to run might need manual clean up. To remove these after uninstalling the Operator, you might need to manually delete the Operator CRDs.

Procedure

1. Navigate to Administration → Namespaces.
2. Locate the namespace that you want to delete in the list of namespaces.
3. On the far right side of the namespace listing, select Delete Namespace from the Options menu .
4. When the Delete Namespace pane opens, enter the name of the namespace that you want to delete in the field.
5. Click Delete.

Procedure

1. Navigate to Administration → CustomResourceDefinitions.
2. Select the Label filter and enter operators.coreos.com/kubevirt-hyperconverged.openshift-cnv in the Search field to display the OpenShift Virtualization CRDs.
3. Click the Options menu beside each CRD and select Delete CustomResourceDefinition.

Procedure

1. In the web console, click Networking → NetworkAttachmentDefinitions.

2. Click Create Network Attachment Definition.

   Note

   The network attachment definition must be in the same namespace as the pod or virtual machine.

3. Enter a unique Name and optional Description.
4. Select CNV Linux bridge from the Network Type list.
5. Enter the name of the bridge in the Bridge Name field.

6. Optional: If the resource has VLAN IDs configured, enter the ID numbers in the VLAN Tag Number field.

   Note

   OSA interfaces on IBM Z® do not support VLAN filtering and VLAN-tagged traffic is dropped. Avoid using VLAN-tagged NADs with OSA interfaces.

7. Optional: Select MAC Spoof Check to enable MAC spoof filtering. This feature provides security against a MAC spoofing attack by allowing only a single MAC address to exit the pod.
8. Click Create.

Procedure

1. Create a NetworkAttachmentDefinition manifest according to the following example:

   Example configuration file

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: my-secondary-network 

   1

   
     namespace: openshift-cnv
   spec:
     config: '{
       "cniVersion": "0.3.1",
       "name": "migration-bridge",
       "type": "macvlan",
       "master": "eth1", 

   2

   
       "mode": "bridge",
       "ipam": {
         "type": "whereabouts", 

   3

   
         "range": "10.200.5.0/24" 

   4

   
       }
     }'

   Copy to Clipboard Toggle word wrap

   1

   Specify the name of the NetworkAttachmentDefinition object.

   2

   Specify the name of the NIC to be used for live migration.

   3

   Specify the name of the CNI plugin that provides the network for the NAD.

   4

   Specify an IP address range for the secondary network. This range must not overlap the IP addresses of the main network.

2. Open the HyperConverged CR in your default editor by running the following command:

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

   Copy to Clipboard Toggle word wrap

3. Add the name of the NetworkAttachmentDefinition object to the spec.liveMigrationConfig stanza of the HyperConverged CR:

   Example HyperConverged manifest

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
     namespace: openshift-cnv
   spec:
     liveMigrationConfig:
       completionTimeoutPerGiB: 800
       network: <network> 

   1

   
       parallelMigrationsPerCluster: 5
       parallelOutboundMigrationsPerNode: 2
       progressTimeout: 150
   # ...

   Copy to Clipboard Toggle word wrap

   1

   Specify the name of the Multus NetworkAttachmentDefinition object to be used for live migrations.

4. Save your changes and exit the editor. The virt-handler pods restart and connect to the secondary network.

Procedure

1. Navigate to Virtualization > Overview in the Red Hat OpenShift Service on AWS web console.
2. Click the Settings tab and then click Live migration.
3. Select the network from the Live migration network list.

Procedure

1. Create a storageclass_csi.yaml file to define the storage class:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hostpath-csi
   provisioner: kubevirt.io.hostpath-provisioner
   reclaimPolicy: Delete 

   1

   
   volumeBindingMode: WaitForFirstConsumer 

   2

   
   parameters:
     storagePool: my-storage-pool 

   3

   Copy to Clipboard Toggle word wrap

   1

   The two possible reclaimPolicy values are Delete and Retain. If you do not specify a value, the default value is Delete.

   2

   The volumeBindingMode parameter determines when dynamic provisioning and volume binding occur. Specify WaitForFirstConsumer to delay the binding and provisioning of a persistent volume (PV) until after a pod that uses the persistent volume claim (PVC) is created. This ensures that the PV meets the pod’s scheduling requirements.

   3

   Specify the name of the storage pool defined in the HPP CR.

2. Save the file and exit.

3. Create the StorageClass object by running the following command:

   $ oc create -f storageclass_csi.yaml

   Copy to Clipboard Toggle word wrap

Procedure

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

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

   Copy to Clipboard Toggle word wrap

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: 

   1

   
       - LiveMigrate 

   2

   
       - Evict 

   3

   
       batchEvictionSize: 10 

   4

   
       batchEvictionInterval: "1m0s" 

   5

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   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.

   2

   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.

   3

   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.

   4

   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.

   5

   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. Click Operators → 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 Administrator perspective of the Red Hat OpenShift Service on AWS web console, navigate to Operators → 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 Operators → Installed Operators page to monitor the progress of the update. When complete, the status changes to Succeeded and Up to date.