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

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

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

     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

     4. Set the KUBECONFIG environment variable:

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

   • 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

   • 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

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.16-for-rhel-8-x86_64-rpms

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

   # yum install kubevirt-virtctl

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 OpenShift Container Platform 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 OpenShift Container Platform 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.
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
       }
     }'

   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

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
   spec:
     liveMigrationConfig:
       completionTimeoutPerGiB: 800
       network: <network> 1
       parallelMigrationsPerCluster: 5
       parallelOutboundMigrationsPerNode: 2
       progressTimeout: 150
   # ...

   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 OpenShift Container Platform 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 an SriovNetworkNodePolicy object, and then save the YAML in the <name>-sriov-node-network.yaml file. Replace <name> with the name for this configuration.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: <name> 1
     namespace: openshift-sriov-network-operator 2
   spec:
     resourceName: <sriov_resource_name> 3
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true" 4
     priority: <priority> 5
     mtu: <mtu> 6
     numVfs: <num> 7
     nicSelector: 8
       vendor: "<vendor_code>" 9
       deviceID: "<device_id>" 10
       pfNames: ["<pf_name>", ...] 11
       rootDevices: ["<pci_bus_id>", "..."] 12
     deviceType: vfio-pci 13
     isRdma: false 14

   1

   Specify a name for the CR object.

   2

   Specify the namespace where the SR-IOV Operator is installed.

   3

   Specify the resource name of the SR-IOV device plugin. You can create multiple SriovNetworkNodePolicy objects for a resource name.

   4

   Specify the node selector to select which nodes are configured. Only SR-IOV network devices on selected nodes are configured. The SR-IOV Container Network Interface (CNI) plugin and device plugin are deployed only on selected nodes.

   5

   Optional: Specify an integer value between 0 and 99. A smaller number gets higher priority, so a priority of 10 is higher than a priority of 99. The default value is 99.

   6

   Optional: Specify a value for the maximum transmission unit (MTU) of the virtual function. The maximum MTU value can vary for different NIC models.

   7

   Specify the number of the virtual functions (VF) to create for the SR-IOV physical network device. For an Intel network interface controller (NIC), the number of VFs cannot be larger than the total VFs supported by the device. For a Mellanox NIC, the number of VFs cannot be larger than 127.

   8

   The nicSelector mapping selects the Ethernet device for the Operator to configure. You do not need to specify values for all the parameters. It is recommended to identify the Ethernet adapter with enough precision to minimize the possibility of selecting an Ethernet device unintentionally. If you specify rootDevices, you must also specify a value for vendor, deviceID, or pfNames. If you specify both pfNames and rootDevices at the same time, ensure that they point to an identical device.

   9

   Optional: Specify the vendor hex code of the SR-IOV network device. The only allowed values are either 8086 or 15b3.

   10

   Optional: Specify the device hex code of SR-IOV network device. The only allowed values are 158b, 1015, 1017.

   11

   Optional: The parameter accepts an array of one or more physical function (PF) names for the Ethernet device.

   12

   The parameter accepts an array of one or more PCI bus addresses for the physical function of the Ethernet device. Provide the address in the following format: 0000:02:00.1.

   13

   The vfio-pci driver type is required for virtual functions in OpenShift Virtualization.

   14

   Optional: Specify whether to enable remote direct memory access (RDMA) mode. For a Mellanox card, set isRdma to false. The default value is false.

   Note

   If isRDMA flag is set to true, you can continue to use the RDMA enabled VF as a normal network device. A device can be used in either mode.

2. Optional: Label the SR-IOV capable cluster nodes with SriovNetworkNodePolicy.Spec.NodeSelector if they are not already labeled. For more information about labeling nodes, see "Understanding how to update labels on nodes".

3. Create the SriovNetworkNodePolicy object:

   $ oc create -f <name>-sriov-node-network.yaml

   where <name> specifies the name for this configuration.

   After applying the configuration update, all the pods in sriov-network-operator namespace transition to the Running status.

4. To verify that the SR-IOV network device is configured, enter the following command. Replace <node_name> with the name of a node with the SR-IOV network device that you just configured.

   $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

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

   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

Procedure

1. In the Administrator perspective of the OpenShift Container Platform 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.

Procedure

1. Run the following command:

   $ oc get csv -n openshift-cnv

2. Review the output, checking the PHASE field. For example:

   Example output

   VERSION  REPLACES                                        PHASE
   4.9.0    kubevirt-hyperconverged-operator.v4.8.2         Installing
   4.9.0    kubevirt-hyperconverged-operator.v4.9.0         Replacing

3. Optional: Monitor the aggregated status of all OpenShift Virtualization component conditions by running the following command:

   $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv \
     -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'

   A successful upgrade results in the following output:

   Example output

   ReconcileComplete  True  Reconcile completed successfully
   Available          True  Reconcile completed successfully
   Progressing        False Reconcile completed successfully
   Degraded           False Reconcile completed successfully
   Upgradeable        True  Reconcile completed successfully

Procedure

1. In the web console, navigate to Virtualization → Catalog.

   The InstanceTypes tab opens by default.

2. Select either of the following options:

   • Select a suitable bootable volume from the list. If the list is truncated, click the Show all button to display the entire list.

     Note

     The bootable volume table lists only those volumes in the openshift-virtualization-os-images namespace that have the instancetype.kubevirt.io/default-preference label.

     • Optional: Click the star icon to designate a bootable volume as a favorite. Starred bootable volumes appear first in the volume list.

   • Click Add volume to upload a new volume or to use an existing persistent volume claim (PVC), a volume snapshot, or a containerDisk volume. Click Save.

     Logos of operating systems that are not available in the cluster are shown at the bottom of the list. You can add a volume for the required operating system by clicking the Add volume link.

     In addition, there is a link to the Create a Windows boot source quick start. The same link appears in a popover if you hover the pointer over the question mark icon next to the Select volume to boot from line.

     Immediately after you install the environment or when the environment is disconnected, the list of volumes to boot from is empty. In that case, three operating system logos are displayed: Windows, RHEL, and Linux. You can add a new volume that meets your requirements by clicking the Add volume button.

3. Click an instance type tile and select the resource size appropriate for your workload.

4. Optional: Choose the virtual machine details, including the VM’s name, that apply to the volume you are booting from:

   • For a Linux-based volume, follow these steps to configure SSH:

     1. If you have not already added a public SSH key to your project, click the edit icon beside Authorized SSH key in the VirtualMachine details section.

     2. Select one of the following options:

        • Use existing: Select a secret from the secrets list.

        • Add new: Follow these steps:

          1. Browse to the public SSH key file or paste the file in the key field.
          2. Enter the secret name.
          3. Optional: Select Automatically apply this key to any new VirtualMachine you create in this project.
     3. Click Save.

   • For a Windows volume, follow either of these set of steps to configure sysprep options:

     • If you have not already added sysprep options for the Windows volume, follow these steps:

       1. Click the edit icon beside Sysprep in the VirtualMachine details section.
       2. Add the Autoattend.xml answer file.
       3. Add the Unattend.xml answer file.
       4. Click Save.

     • If you want to use existing sysprep options for the Windows volume, follow these steps:

       1. Click Attach existing sysprep.
       2. Enter the name of the existing sysprep Unattend.xml answer file.
       3. Click Save.

5. Optional: If you are creating a Windows VM, you can mount a Windows driver disk:

   1. Click the Customize VirtualMachine button.
   2. On the VirtualMachine details page, click Storage.
   3. Select the Mount Windows drivers disk checkbox.
6. Optional: Click View YAML & CLI to view the YAML file. Click CLI to view the CLI commands. You can also download or copy either the YAML file contents or the CLI commands.
7. Click Create VirtualMachine.

Procedure

1. Navigate to Virtualization → Catalog in the web console.

2. Click Boot source available to filter templates with boot sources.

   The catalog displays the default templates. Click All Items to view all available templates for your filters.

3. Click a template tile to view its details.
4. Optional: If you are using a Windows template, you can mount a Windows driver disk by selecting the Mount Windows drivers disk checkbox.

5. If you do not need to customize the template or VM parameters, click Quick create VirtualMachine to create a VM from the template.

   If you need to customize the template or VM parameters, do the following:

   1. Click Customize VirtualMachine.
   2. Expand Storage or Optional parameters to edit data source settings.

   3. Click Customize VirtualMachine parameters.

      The Customize and create VirtualMachine pane displays the Overview, YAML, Scheduling, Environment, Network interfaces, Disks, Scripts, and Metadata tabs.

   4. Edit the parameters that must be set before the VM boots, such as cloud-init or a static SSH key.

   5. Click Create VirtualMachine.

      The VirtualMachine details page displays the provisioning status.

Procedure

1. Edit the VirtualMachine manifest for your VM. The following example configures a Red Hat Enterprise Linux (RHEL) VM:

   Note

   This example manifest does not configure VM authentication.

   Example manifest for a RHEL VM

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
     name: rhel-9-minimal
    spec:
     dataVolumeTemplates:
       - metadata:
           name: rhel-9-minimal-volume
         spec:
           sourceRef:
             kind: DataSource
             name: rhel9 1
             namespace: openshift-virtualization-os-images 2
           storage: {}
     instancetype:
       name: u1.medium 3
     preference:
       name: rhel.9 4
     running: true
     template:
       spec:
         domain:
           devices: {}
         volumes:
           - dataVolume:
               name: rhel-9-minimal-volume
             name: rootdisk

   1

   The rhel9 golden image is used to install RHEL 9 as the guest operating system.

   2

   Golden images are stored in the openshift-virtualization-os-images namespace.

   3

   The u1.medium instance type requests 1 vCPU and 4Gi memory for the VM. These resource values cannot be overridden within the VM.

   4

   The rhel.9 preference specifies additional attributes that support the RHEL 9 guest operating system.

2. Create a virtual machine by using the manifest file:

   $ oc create -f <vm_manifest_file>.yaml

3. Optional: Start the virtual machine:

   $ virtctl start <vm_name> -n <namespace>

Procedure

1. Create a Dockerfile to build the VM image into a container image. The VM image must be owned by QEMU, which has a UID of 107, and placed in the /disk/ directory inside the container. Permissions for the /disk/ directory must then be set to 0440.

   The following example uses the Red Hat Universal Base Image (UBI) to handle these configuration changes in the first stage, and uses the minimal scratch image in the second stage to store the result:

   $ cat > Dockerfile << EOF
   FROM registry.access.redhat.com/ubi8/ubi:latest AS builder
   ADD --chown=107:107 <vm_image>.qcow2 /disk/ 1
   RUN chmod 0440 /disk/*
   
   FROM scratch
   COPY --from=builder /disk/* /disk/
   EOF

   1

   Where <vm_image> is the image in either QCOW2 or RAW format. If you use a remote image, replace <vm_image>.qcow2 with the complete URL.

2. Build and tag the container:

   $ podman build -t <registry>/<container_disk_name>:latest .

3. Push the container image to the registry:

   $ podman push <registry>/<container_disk_name>:latest

Prerequisites

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

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

2. Add a list of insecure registries to the spec.storageImport.insecureRegistries field.

   Example HyperConverged custom resource

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
     namespace: openshift-cnv
   spec:
     storageImport:
       insecureRegistries: 1
         - "private-registry-example-1:5000"
         - "private-registry-example-2:5000"

   1

   Replace the examples in this list with valid registry hostnames.

Procedure

1. Navigate to Virtualization → Catalog in the web console.
2. Click a template tile without an available boot source.
3. Click Customize VirtualMachine.
4. On the Customize template parameters page, expand Storage and select Registry (creates PVC) from the Disk source list.
5. Enter the container image URL. Example: https://mirror.arizona.edu/fedora/linux/releases/38/Cloud/x86_64/images/Fedora-Cloud-Base-38-1.6.x86_64.qcow2
6. Set the disk size.
7. Click Next.
8. Click Create VirtualMachine.

Procedure

1. If the container registry requires authentication, create a Secret manifest, specifying the credentials, and save it as a data-source-secret.yaml file:

   apiVersion: v1
   kind: Secret
   metadata:
     name: data-source-secret
     labels:
       app: containerized-data-importer
   type: Opaque
   data:
     accessKeyId: "" 1
     secretKey:   "" 2

   1

   Specify the Base64-encoded key ID or user name.

   2

   Specify the Base64-encoded secret key or password.

2. Apply the Secret manifest by running the following command:

   $ oc apply -f data-source-secret.yaml

3. If the VM must communicate with servers that use self-signed certificates or certificates that are not signed by the system CA bundle, create a config map in the same namespace as the VM:

   $ oc create configmap tls-certs 1
     --from-file=</path/to/file/ca.pem> 2

   1

   Specify the config map name.

   2

   Specify the path to the CA certificate.

4. Edit the VirtualMachine manifest and save it as a vm-fedora-datavolume.yaml file:

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     creationTimestamp: null
     labels:
       kubevirt.io/vm: vm-fedora-datavolume
     name: vm-fedora-datavolume 1
   spec:
     dataVolumeTemplates:
     - metadata:
         creationTimestamp: null
         name: fedora-dv 2
       spec:
         storage:
           resources:
             requests:
               storage: 10Gi 3
           storageClassName: <storage_class> 4
         source:
           registry:
             url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest" 5
             secretRef: data-source-secret 6
             certConfigMap: tls-certs 7
       status: {}
     running: true
     template:
       metadata:
         creationTimestamp: null
         labels:
           kubevirt.io/vm: vm-fedora-datavolume
       spec:
         domain:
           devices:
             disks:
             - disk:
                 bus: virtio
               name: datavolumedisk1
           machine:
             type: ""
           resources:
             requests:
               memory: 1.5Gi
         terminationGracePeriodSeconds: 180
         volumes:
         - dataVolume:
             name: fedora-dv
           name: datavolumedisk1
   status: {}

   1

   Specify the name of the VM.

   2

   Specify the name of the data volume.

   3

   Specify the size of the storage requested for the data volume.

   4

   Optional: If you do not specify a storage class, the default storage class is used.

   5

   Specify the URL of the container registry.

   6

   Optional: Specify the secret name if you created a secret for the container registry access credentials.

   7

   Optional: Specify a CA certificate config map.

5. Create the VM by running the following command:

   $ oc create -f vm-fedora-datavolume.yaml

   The oc create command creates the data volume and the VM. The CDI controller creates an underlying PVC with the correct annotation and the import process begins. When the import is complete, the data volume status changes to Succeeded. You can start the VM.

   Data volume provisioning happens in the background, so there is no need to monitor the process.

Verification

1. The importer pod downloads the container disk from the specified URL and stores it on the provisioned persistent volume. View the status of the importer pod by running the following command:

   $ oc get pods

2. Monitor the data volume until its status is Succeeded by running the following command:

   $ oc describe dv fedora-dv 1

   1

   Specify the data volume name that you defined in the VirtualMachine manifest.

3. Verify that provisioning is complete and that the VM has started by accessing its serial console:

   $ virtctl console vm-fedora-datavolume

Procedure

1. Navigate to Virtualization → Catalog in the web console.
2. Click a template tile without an available boot source.
3. Click Customize VirtualMachine.
4. On the Customize template parameters page, expand Storage and select URL (creates PVC) from the Disk source list.
5. Enter the image URL. Example: https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.9/x86_64/product-software
6. Enter the container image URL. Example: https://mirror.arizona.edu/fedora/linux/releases/38/Cloud/x86_64/images/Fedora-Cloud-Base-38-1.6.x86_64.qcow2
7. Set the disk size.
8. Click Next.
9. Click Create VirtualMachine.

Procedure

1. If the web page requires authentication, create a Secret manifest, specifying the credentials, and save it as a data-source-secret.yaml file:

   apiVersion: v1
   kind: Secret
   metadata:
     name: data-source-secret
     labels:
       app: containerized-data-importer
   type: Opaque
   data:
     accessKeyId: "" 1
     secretKey:   "" 2

   1

   Specify the Base64-encoded key ID or user name.

   2

   Specify the Base64-encoded secret key or password.

2. Apply the Secret manifest by running the following command:

   $ oc apply -f data-source-secret.yaml

3. If the VM must communicate with servers that use self-signed certificates or certificates that are not signed by the system CA bundle, create a config map in the same namespace as the VM:

   $ oc create configmap tls-certs 1
     --from-file=</path/to/file/ca.pem> 2

   1

   Specify the config map name.

   2

   Specify the path to the CA certificate.

4. Edit the VirtualMachine manifest and save it as a vm-fedora-datavolume.yaml file:

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     creationTimestamp: null
     labels:
       kubevirt.io/vm: vm-fedora-datavolume
     name: vm-fedora-datavolume 1
   spec:
     dataVolumeTemplates:
     - metadata:
         creationTimestamp: null
         name: fedora-dv 2
       spec:
         storage:
           resources:
             requests:
               storage: 10Gi 3
           storageClassName: <storage_class> 4
         source:
           http:
             url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 5
           registry:
             url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest" 6
             secretRef: data-source-secret 7
             certConfigMap: tls-certs 8
       status: {}
     running: true
     template:
       metadata:
         creationTimestamp: null
         labels:
           kubevirt.io/vm: vm-fedora-datavolume
       spec:
         domain:
           devices:
             disks:
             - disk:
                 bus: virtio
               name: datavolumedisk1
           machine:
             type: ""
           resources:
             requests:
               memory: 1.5Gi
         terminationGracePeriodSeconds: 180
         volumes:
         - dataVolume:
             name: fedora-dv
           name: datavolumedisk1
   status: {}

   1

   Specify the name of the VM.

   2

   Specify the name of the data volume.

   3

   Specify the size of the storage requested for the data volume.

   4

   Optional: If you do not specify a storage class, the default storage class is used.

   5 6

   Specify the URL of the web page.

   7

   Optional: Specify the secret name if you created a secret for the web page access credentials.

   8

   Optional: Specify a CA certificate config map.

5. Create the VM by running the following command:

   $ oc create -f vm-fedora-datavolume.yaml

   The oc create command creates the data volume and the VM. The CDI controller creates an underlying PVC with the correct annotation and the import process begins. When the import is complete, the data volume status changes to Succeeded. You can start the VM.

   Data volume provisioning happens in the background, so there is no need to monitor the process.

Verification

1. The importer pod downloads the image from the specified URL and stores it on the provisioned persistent volume. View the status of the importer pod by running the following command:

   $ oc get pods

2. Monitor the data volume until its status is Succeeded by running the following command:

   $ oc describe dv fedora-dv 1

   1

   Specify the data volume name that you defined in the VirtualMachine manifest.

3. Verify that provisioning is complete and that the VM has started by accessing its serial console:

   $ virtctl console vm-fedora-datavolume

Procedure

1. Navigate to Virtualization → Catalog in the web console.
2. Click a template tile without an available boot source.
3. Click Customize VirtualMachine.
4. On the Customize template parameters page, expand Storage and select Upload (Upload a new file to a PVC) from the Disk source list.
5. Browse to the image on your local machine and set the disk size.
6. Click Customize VirtualMachine.
7. Click Create VirtualMachine.

Procedure

1. Upload the Windows image as a new PVC:

   1. Navigate to Storage → PersistentVolumeClaims in the web console.
   2. Click Create PersistentVolumeClaim → With Data upload form.
   3. Browse to the Windows image and select it.

   4. Enter the PVC name, select the storage class and size and then click Upload.

      The Windows image is uploaded to a PVC.

2. Configure a new VM by cloning the uploaded PVC:

   1. Navigate to Virtualization → Catalog.
   2. Select a Windows template tile and click Customize VirtualMachine.
   3. Select Clone (clone PVC) from the Disk source list.
   4. Select the PVC project, the Windows image PVC, and the disk size.

3. Apply the answer file to the VM:

   1. Click Customize VirtualMachine parameters.
   2. On the Sysprep section of the Scripts tab, click Edit.
   3. Browse to the autounattend.xml answer file and click Save.

4. Set the run strategy of the VM:

   1. Clear Start this VirtualMachine after creation so that the VM does not start immediately.
   2. Click Create VirtualMachine.
   3. On the YAML tab, replace running:false with runStrategy: RerunOnFailure and click Save.

5. Click the options menu and select Start.

   The VM boots from the sysprep disk containing the autounattend.xml answer file.

Procedure

1. Upload the image by running the virtctl image-upload command:

   $ virtctl image-upload dv <datavolume_name> \ 1
     --size=<datavolume_size> \ 2
     --image-path=</path/to/image> \ 3

   1

   The name of the data volume.

   2

   The size of the data volume. For example: --size=500Mi, --size=1G

   3

   The file path of the image.

   Note
   • If you do not want to create a new data volume, omit the --size parameter and include the --no-create flag.
   • When uploading a disk image to a PVC, the PVC size must be larger than the size of the uncompressed virtual disk.
   • To allow insecure server connections when using HTTPS, use the --insecure parameter. When you use the --insecure flag, the authenticity of the upload endpoint is not verified.

2. Optional. To verify that a data volume was created, view all data volumes by running the following command:

   $ oc get dvs

Procedure

1. Navigate to Virtualization → VirtualMachines in the web console.
2. Select a VM to open the VirtualMachine details page.
3. Click Actions.
4. Select Clone.
5. On the Clone VirtualMachine page, enter the name of the new VM.
6. (Optional) Select the Start cloned VM checkbox to start the cloned VM.
7. Click Clone.

Procedure

1. Navigate to Virtualization → VirtualMachines in the web console.
2. Select a VM to open the VirtualMachine details page.
3. Click the Snapshots tab.
4. Click the actions menu for the snapshot you want to copy.
5. Select Create VirtualMachine.
6. Enter the name of the virtual machine.
7. (Optional) Select the Start this VirtualMachine after creation checkbox to start the new virtual machine.
8. Click Create.

Procedure

1. Navigate to Virtualization → Catalog in the web console.
2. Click a template tile without an available boot source.
3. Click Customize VirtualMachine.
4. On the Customize template parameters page, expand Storage and select PVC (clone PVC) from the Disk source list.
5. Enter the image URL. Example: https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.9/x86_64/product-software
6. Enter the container image URL. Example: https://mirror.arizona.edu/fedora/linux/releases/38/Cloud/x86_64/images/Fedora-Cloud-Base-38-1.6.x86_64.qcow2
7. Select the PVC project and the PVC name.
8. Set the disk size.
9. Click Next.
10. Click Create VirtualMachine.

Procedure

1. On the Virtualization → VirtualMachines page, click a VM to open the VirtualMachine details page.
2. Click the Console tab. The VNC console session starts automatically.

3. Optional: To switch to the vGPU display of a Windows VM, select Ctl + Alt + 2 from the Send key list.

   • Select Ctl + Alt + 1 from the Send key list to restore the default display.
4. To end the console session, click outside the console pane and then click Disconnect.

Procedure

1. Run the following command to start the console session:

   $ virtctl vnc <vm_name>

2. If the connection fails, run the following command to collect troubleshooting information:

   $ virtctl vnc <vm_name> -v 4

Procedure

1. Enable the feature gate in the HyperConverged (HCO) custom resource (CR):

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

2. Generate a token by entering the following command:

   $ curl --header "Authorization: Bearer ${TOKEN}" \
        "https://api.<cluster_fqdn>/apis/token.kubevirt.io/v1alpha1/namespaces/<namespace>/virtualmachines/<vm_name>/vnc?duration=<duration>"

   The <duration> parameter can be set in hours and minutes, with a minimum duration of 10 minutes. For example: 5h30m. If this parameter is not set, the token is valid for 10 minutes by default.

   Sample output:

   { "token": "eyJhb..." }

3. Optional: Use the token provided in the output to create a variable:

   $ export VNC_TOKEN="<token>"

Verification

1. Log in to the cluster by entering the following command:

   $ oc login --token ${VNC_TOKEN}

2. Test access to the VNC console of the VM by using the virtctl command:

   $ virtctl vnc <vm_name> -n <namespace>

Procedure

1. On the Virtualization → VirtualMachines page, click a VM to open the VirtualMachine details page.
2. Click the Console tab. The VNC console session starts automatically.
3. Click Disconnect to end the VNC console session. Otherwise, the VNC console session continues to run in the background.
4. Select Serial console from the console list.
5. To end the console session, click outside the console pane and then click Disconnect.