Chapter 8. Virtual machines

Procedure

1. Click Workloads → Virtualization from the side menu.
2. Click the Virtual Machines tab.
3. Click Create and select Virtual Machine With YAML.

4. Write or paste your virtual machine configuration in the editable window.

   1. Alternatively, use the example virtual machine provided by default in the YAML screen.
5. Optional: Click Download to download the YAML configuration file in its present state.
6. Click Create to create the virtual machine.

Procedure

1. In the OpenShift Virtualization console, click Workloads → Virtualization from the side menu.
2. Click the Virtual Machines tab.
3. Select a virtual machine to open the Virtual Machine Overview page.
4. Click Console. The VNC console opens by default.
5. Select Disconnect before switching to ensure that only one console session is open at a time. Otherwise, the VNC console session remains active in the background.
6. Click the VNC Console drop-down list and select Serial Console.
7. Click Disconnect to end the console session.
8. Optional: Open the serial console in a separate window by clicking Open Console in New Window.

Procedure

1. In the OpenShift Virtualization console, click Workloads → Virtualization from the side menu.
2. Click the Virtual Machines tab.
3. Select a virtual machine to open the Virtual Machine Overview page.
4. Click the Console tab. The VNC console opens by default.
5. Optional: Open the VNC console in a separate window by clicking Open Console in New Window.
6. Optional: Send key combinations to the virtual machine by clicking Send Key.
7. Click outside the console window and then click Disconnect to end the session.

Procedure

1. In the OpenShift Virtualization console, click Workloads → Virtualization from the side menu.
2. Click the Virtual Machines tab.
3. Select a Windows virtual machine to open the Virtual Machine Overview screen.
4. Click the Console tab.
5. In the Console list, select Desktop Viewer.
6. In the Network Interface list, select the layer-2 NIC.
7. Click Launch Remote Desktop to download the console.rdp file.

8. Open an RDP client and reference the console.rdp file. For example, using remmina:

   $ remmina --connect /path/to/console.rdp

9. Enter the Administrator user name and password to connect to the Windows virtual machine.

Procedure

1. In the OpenShift Container Platform console, click Workloads → Virtualization from the side menu.
2. Click the Virtual Machines tab.
3. Select a virtual machine to open the Virtual Machine Overview page.
4. From the Actions list, select Copy SSH Command. You can now paste this command onto the OpenShift CLI (oc).

Procedure

1. Run the following command to create the fedora-vm-ssh service:

   $ virtctl expose vm <fedora-vm> --port=22 --name=fedora-vm-ssh --type=NodePort 1

   1

   <fedora-vm> is the name of the VM that you run the fedora-vm-ssh service on.

2. Check the service to find out which port the service acquired:

   $ oc get svc

1. Log in to the VMI via SSH. Use the ipAddress of any of the cluster nodes and the port that you found in the previous step:

   $ ssh username@<node_IP_address> -p 32551

Procedure

1. In the YAML file for the VM, add the label and a value for exposing the service for SSH connections. Enable the masquerade feature for the interface:

   Example VirtualMachine definition

   ...
   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     namespace: ssh-ns 1
     name: vm-ssh
   spec:
     running: false
     template:
       metadata:
         labels:
           kubevirt.io/vm: vm-ssh
           special: vm-ssh 2
       spec:
         domain:
           devices:
             disks:
             - disk:
                 bus: virtio
               name: containerdisk
             - disk:
                 bus: virtio
               name: cloudinitdisk
             interfaces:
             - masquerade: {} 3
               name: testmasquerade 4
             rng: {}
           machine:
             type: ""
           resources:
             requests:
               memory: 1024M
         networks:
         - name: testmasquerade
           pod: {}
         volumes:
         - name: containerdisk
           containerDisk:
             image: kubevirt/fedora-cloud-container-disk-demo
         - name: cloudinitdisk
           cloudInitNoCloud:
             userData: |
               #!/bin/bash
               echo "fedora" | passwd fedora --stdin
   ...

   1

   Name of the namespace created by the oc create namespace command.

   2

   Label used by the service to identify the virtual machine instances that are enabled for SSH traffic connections. The label can be any key:value pair that is added as a label to this YAML file and as a selector in the service YAML file.

   3

   The interface type is masquerade.

   4

   The name of this interface is testmasquerade.

2. Create the VM:

   $ oc create -f <path_for_the_VM_YAML_file>

3. Start the VM:

   $ virtctl start vm-ssh

4. In the YAML file for the service, specify the service name, port number, and the target port.

   Example Service definition

   ...
   apiVersion: v1
   kind: Service
   metadata:
     name: svc-ssh 1
     namespace: ssh-ns 2
   spec:
     ports:
     - targetPort: 22 3
       protocol: TCP
       port: 27017
     selector:
       special: vm-ssh 4
     type: NodePort
   ...

   1

   Name of the SSH service.

   2

   Name of the namespace created by the oc create namespace command.

   3

   The target port number for the SSH connection.

   4

   The selector name and value must match the label specified in the YAML file for the VM.

5. Create the service:

   $ oc create -f <path_for_the_service_YAML_file>

6. Verify that the VM is running:

   $ oc get vmi

   Example output

   NAME    AGE     PHASE       IP              NODENAME
   vm-ssh 6s       Running     10.244.196.152  node01

7. Check the service to find out which port the service acquired:

   $ oc get svc

   Example output

   NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
   svc-ssh     NodePort       10.106.236.208 <none>        27017:30093/TCP   22s

   In this example, the service acquired the port number 30093.

8. Run the following command to obtain the IP address for the node:

   $ oc get node <node_name> -o wide

   Example output

   NAME    STATUS   ROLES   AGE    VERSION          INTERNAL-IP      EXTERNAL-IP
   node01  Ready    worker  6d22h  v1.20.0+5f82cdb  192.168.55.101   <none>

9. Log in to the VM via SSH by specifying the IP address of the node where the VM is running and the port number. Use the port number displayed by the oc get svc command and the IP address of the node displayed by the oc get node command. The following example shows the ssh command with the username, node’s IP address, and the port number:

   $ ssh fedora@192.168.55.101 -p 30093

Procedure

1. Connect to the graphical interface with the virtctl utility:

   $ virtctl vnc <VMI>

2. If the command failed, try using the -v flag to collect troubleshooting information:

   $ virtctl vnc <VMI> -v 4

Procedure

1. Log in to the OpenShift Virtualization cluster through the oc CLI tool as a user with an access token.

   $ oc login -u <user> https://<cluster.example.com>:8443

2. Use oc describe vmi to display the configuration of the running Windows virtual machine.

   $ oc describe vmi <windows-vmi-name>

   Example output

   ...
   spec:
     networks:
     - name: default
       pod: {}
     - multus:
         networkName: cnv-bridge
       name: bridge-net
   ...
   status:
     interfaces:
     - interfaceName: eth0
       ipAddress: 198.51.100.0/24
       ipAddresses:
         198.51.100.0/24
       mac: a0:36:9f:0f:b1:70
       name: default
     - interfaceName: eth1
       ipAddress: 192.0.2.0/24
       ipAddresses:
         192.0.2.0/24
         2001:db8::/32
       mac: 00:17:a4:77:77:25
       name: bridge-net
   ...

3. Identify and copy the IP address of the layer 2 network interface. This is 192.0.2.0 in the above example, or 2001:db8:: if you prefer IPv6.
4. Open an RDP client and use the IP address copied in the previous step for the connection.
5. Enter the Administrator user name and password to connect to the Windows virtual machine.

Procedure

1. Start the virtual machine and connect to a graphical console.
2. Log in to a Windows user session.

3. Open Device Manager and expand Other devices to list any Unknown device.

   1. Open the Device Properties to identify the unknown device. Right-click the device and select Properties.
   2. Click the Details tab and select Hardware Ids in the Property list.
   3. Compare the Value for the Hardware Ids with the supported VirtIO drivers.
4. Right-click the device and select Update Driver Software.
5. Click Browse my computer for driver software and browse to the attached SATA CD drive, where the VirtIO drivers are located. The drivers are arranged hierarchically according to their driver type, operating system, and CPU architecture.
6. Click Next to install the driver.
7. Repeat this process for all the necessary VirtIO drivers.
8. After the driver installs, click Close to close the window.
9. Reboot the virtual machine to complete the driver installation.

Procedure

1. Start the virtual machine and connect to a graphical console.
2. Begin the Windows installation process.
3. Select the Advanced installation.
4. The storage destination will not be recognized until the driver is loaded. Click Load driver.
5. The drivers are attached as a SATA CD drive. Click OK and browse the CD drive for the storage driver to load. The drivers are arranged hierarchically according to their driver type, operating system, and CPU architecture.
6. Repeat the previous two steps for all required drivers.
7. Complete the Windows installation.

Procedure

1. Set limits for a VM by editing the VirtualMachine manifest. For example:

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: with-limits
   spec:
     running: false
     template:
       spec:
         domain:
   # ...
           resources:
             requests:
               memory: 128Mi
             limits:
               memory: 256Mi  1

   1

   This configuration is supported because the limits.memory value is at least 100Mi larger than the requests.memory value.

2. Save the VirtualMachine manifest.

Procedure

1. Open the HyperConverged CR by running the following command:

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

2. Edit the spec.certConfig fields as shown in the following example. To avoid overloading the system, ensure that all values are greater than or equal to 10 minutes. Express all values as strings that comply with the golang ParseDuration format.

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
    name: kubevirt-hyperconverged
    namespace: openshift-cnv
   spec:
     certConfig:
       ca:
         duration: 48h0m0s
         renewBefore: 24h0m0s 1
       server:
         duration: 24h0m0s  2
         renewBefore: 12h0m0s  3

   1

   The value of ca.renewBefore must be less than or equal to the value of ca.duration.

   2

   The value of server.duration must be less than or equal to the value of ca.duration.

   3

   The value of server.renewBefore must be less than or equal to the value of server.duration.

3. Apply the YAML file to your cluster.

Procedure

1. Edit an Ansible Playbook YAML file so that it includes the kubevirt_vm task:

     kubevirt_vm:
       namespace:
       name:
       cpu_cores:
       memory:
       disks:
         - name:
           volume:
             containerDisk:
               image:
           disk:
             bus:

   Note

   This snippet only includes the kubevirt_vm portion of the playbook.

2. Edit the values to reflect the virtual machine you want to create, including the namespace, the number of cpu_cores, the memory, and the disks. For example:

     kubevirt_vm:
       namespace: default
       name: vm1
       cpu_cores: 1
       memory: 64Mi
       disks:
         - name: containerdisk
           volume:
             containerDisk:
               image: kubevirt/cirros-container-disk-demo:latest
           disk:
             bus: virtio

3. If you want the virtual machine to boot immediately after creation, add state: running to the YAML file. For example:

     kubevirt_vm:
       namespace: default
       name: vm1
       state: running 1
       cpu_cores: 1

   1

   Changing this value to state: absent deletes the virtual machine, if it already exists.

4. Run the ansible-playbook command, using your playbook’s file name as the only argument:

   $ ansible-playbook create-vm.yaml

5. Review the output to determine if the play was successful:

   Example output

   (...)
   TASK [Create my first VM] ************************************************************************
   changed: [localhost]
   
   PLAY RECAP ********************************************************************************************************
   localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

6. If you did not include state: running in your playbook file and you want to boot the VM now, edit the file so that it includes state: running and run the playbook again:

   $ ansible-playbook create-vm.yaml

Procedure

1. Create a YAML file that defines a VM object or a Virtual Machine Instance (VMI) object. Use the firmware stanza of the example YAML file:

   Booting in EFI mode with secure boot active

     apiversion: kubevirt.io/v1
     kind: VirtualMachineInstance
     metadata:
       labels:
         special: vmi-secureboot
       name: vmi-secureboot
     spec:
       domain:
         devices:
           disks:
           - disk:
               bus: virtio
             name: containerdisk
         features:
           acpi: {}
           smm:
             enabled: true 1
         firmware:
           bootloader:
             efi:
               secureBoot: true 2
   ...

   1

   OpenShift Virtualization requires System Management Mode (SMM) to be enabled for Secure Boot in EFI mode to occur.

   2

   OpenShift Virtualization only supports a virtual machine (VM) with Secure Boot when using EFI mode. If Secure Boot is not enabled, the VM crashes repeatedly. However, the VM might not support Secure Boot. Before you boot a VM, verify that it supports Secure Boot by checking the VM settings.

2. Apply the manifest to your cluster by running the following command:

   $ oc create -f <file_name>.yaml

Procedure

1. Configure a PXE network on the cluster:

   1. Create the network attachment definition file for PXE network pxe-net-conf:

      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: pxe-net-conf
      spec:
        config: '{
          "cniVersion": "0.3.1",
          "name": "pxe-net-conf",
          "plugins": [
            {
              "type": "cnv-bridge",
              "bridge": "br1",
              "vlan": 1 1
            },
            {
              "type": "cnv-tuning" 2
            }
          ]
        }'

      1

      Optional: The VLAN tag.

      2

      The cnv-tuning plugin provides support for custom MAC addresses.

      Note

      The virtual machine instance will be attached to the bridge br1 through an access port with the requested VLAN.

2. Create the network attachment definition by using the file you created in the previous step:

   $ oc create -f pxe-net-conf.yaml

3. Edit the virtual machine instance configuration file to include the details of the interface and network.

   1. Specify the network and MAC address, if required by the PXE server. If the MAC address is not specified, a value is assigned automatically.

      Ensure that bootOrder is set to 1 so that the interface boots first. In this example, the interface is connected to a network called <pxe-net>:

      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1

      Note

      Boot order is global for interfaces and disks.

   2. Assign a boot device number to the disk to ensure proper booting after operating system provisioning.

      Set the disk bootOrder value to 2:

      devices:
        disks:
        - disk:
            bus: virtio
          name: containerdisk
          bootOrder: 2

   3. Specify that the network is connected to the previously created network attachment definition. In this scenario, <pxe-net> is connected to the network attachment definition called <pxe-net-conf>:

      networks:
      - name: default
        pod: {}
      - name: pxe-net
        multus:
          networkName: pxe-net-conf

4. Create the virtual machine instance:

   $ oc create -f vmi-pxe-boot.yaml

1. Wait for the virtual machine instance to run:

   $ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
     phase: Running

2. View the virtual machine instance using VNC:

   $ virtctl vnc vmi-pxe-boot

3. Watch the boot screen to verify that the PXE boot is successful.

4. Log in to the virtual machine instance:

   $ virtctl console vmi-pxe-boot

5. Verify the interfaces and MAC address on the virtual machine and that the interface connected to the bridge has the specified MAC address. In this case, we used eth1 for the PXE boot, without an IP address. The other interface, eth0, got an IP address from OpenShift Container Platform.

   $ ip addr

Procedure

1. To explicitly tell the virtual machine instance that it has more memory available than was requested from the cluster, edit the virtual machine configuration file and set spec.domain.memory.guest to a higher value than spec.domain.resources.requests.memory. This process is called memory overcommitment.

   In this example, 1024M is requested from the cluster, but the virtual machine instance is told that it has 2048M available. As long as there is enough free memory available on the node, the virtual machine instance will consume up to 2048M.

   kind: VirtualMachine
   spec:
     template:
       domain:
       resources:
           requests:
             memory: 1024M
       memory:
           guest: 2048M

   Note

   The same eviction rules as those for pods apply to the virtual machine instance if the node is under memory pressure.

2. Create the virtual machine:

   $ oc create -f <file_name>.yaml

Procedure

1. To disable guest memory overhead accounting, edit the YAML configuration file and set the overcommitGuestOverhead value to true. This parameter is disabled by default.

   kind: VirtualMachine
   spec:
     template:
       domain:
       resources:
           overcommitGuestOverhead: true
           requests:
             memory: 1024M

   Note

   If overcommitGuestOverhead is enabled, it adds the guest overhead to memory limits, if present.

2. Create the virtual machine:

   $ oc create -f <file_name>.yaml

Procedure

1. In your virtual machine configuration, add the resources.requests.memory and memory.hugepages.pageSize parameters to the spec.domain. The following configuration snippet is for a virtual machine that requests a total of 4Gi memory with a page size of 1Gi:

   kind: VirtualMachine
   ...
   spec:
     domain:
       resources:
         requests:
           memory: "4Gi" 1
       memory:
         hugepages:
           pageSize: "1Gi" 2
   ...

   1

   The total amount of memory requested for the virtual machine. This value must be divisible by the page size.

   2

   The size of each huge page. Valid values for x86_64 architecture are 1Gi and 2Mi. The page size must be smaller than the requested memory.

2. Apply the virtual machine configuration:

   $ oc apply -f <virtual_machine>.yaml

Procedure

1. Click Workloads → Virtual Machines from the side menu.
2. Select a virtual machine to open the Virtual Machine tab.
3. Click the Details tab.
4. Click the pencil icon to the right of the Dedicated Resources field to open the Dedicated Resources window.
5. Select Schedule this workload with dedicated resources (guaranteed policy).
6. Click Save.

Procedure

1. Create a YAML file with the following contents:

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     labels:
       kubevirt.io/vm: vm2-rhel84-watchdog
     name: <vm-name>
   spec:
     running: false
     template:
       metadata:
        labels:
           kubevirt.io/vm: vm2-rhel84-watchdog
       spec:
         domain:
           devices:
             watchdog:
               name: <watchdog>
               i6300esb:
                 action: "poweroff" 1
   ...

   1

   Specify the watchdog action (poweroff, reset, or shutdown).

   The example above configures the i6300esb watchdog device on a RHEL8 VM with the poweroff action and exposes the device as /dev/watchdog.

   This device can now be used by the watchdog binary.

2. Apply the YAML file to your cluster by running the following command:

   $ oc apply -f <file_name>.yaml

1. Run the following command to verify that the VM is connected to the watchdog device:

   $ lspci | grep watchdog -i

2. Run one of the following commands to confirm the watchdog is active:

   • Trigger a kernel panic:

     # echo c > /proc/sysrq-trigger

   • Terminate the watchdog service:

     # pkill -9 watchdog

Procedure

1. As a root user, install the watchdog package and dependencies:

   # yum install watchdog

2. Uncomment the following line in the /etc/watchdog.conf file, and save the changes:

   #watchdog-device = /dev/watchdog

3. Enable the watchdog service to start on boot:

   # systemctl enable --now watchdog.service

Procedure

1. Ensure you are in the correct namespace. The config map can only be referenced by data volumes if it is in the same namespace.

   $ oc get ns

2. Create the config map:

   $ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>

Procedure

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

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

   1

   Specify the name of the Secret.

   2

   Specify the Base64-encoded key ID or user name.

   3

   Specify the Base64-encoded secret key or password.

2. Apply the Secret manifest:

   $ oc apply -f endpoint-secret.yaml

3. Edit the VirtualMachine manifest, specifying the data source for the virtual machine image you want to import, and save it as vm-fedora-datavolume.yaml:

   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
           storageClassName: local
         source:
           http: 3
             url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 4
             secretRef: endpoint-secret 5
             certConfigMap: "" 6
       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: 60
         volumes:
         - dataVolume:
             name: fedora-dv
           name: datavolumedisk1
   status: {}

   1

   Specify the name of the virtual machine.

   2

   Specify the name of the data volume.

   3

   Specify http for an HTTP or HTTPS endpoint. Specify registry for a container disk image imported from a registry.

   4

   The source of the virtual machine image you want to import. This example references a virtual machine image at an HTTPS endpoint. An example of a container registry endpoint is url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest".

   5

   Required if you created a Secret for the data source.

   6

   Optional: Specify a CA certificate config map.

4. Create the virtual machine:

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

   Note

   The oc create command creates the data volume and the virtual machine. 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 virtual machine.

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

Verification

1. The importer pod downloads the virtual machine image or container disk from the specified URL and stores it on the provisioned PV. 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 virtual machine has started by accessing its serial console:

   $ virtctl console vm-fedora-datavolume

Procedure

1. Log in as root to the node on which to create the local PV. This procedure uses node01 for its examples.

2. Create a file and populate it with null characters so that it can be used as a block device. The following example creates a file loop10 with a size of 2Gb (20 100Mb blocks):

   $ dd if=/dev/zero of=<loop10> bs=100M count=20

3. Mount the loop10 file as a loop device.

   $ losetup </dev/loop10>d3 <loop10> 1 2

   1

   File path where the loop device is mounted.

   2

   The file created in the previous step to be mounted as the loop device.

4. Create a PersistentVolume manifest that references the mounted loop device.

   kind: PersistentVolume
   apiVersion: v1
   metadata:
     name: <local-block-pv10>
     annotations:
   spec:
     local:
       path: </dev/loop10> 1
     capacity:
       storage: <2Gi>
     volumeMode: Block 2
     storageClassName: local 3
     accessModes:
       - ReadWriteOnce
     persistentVolumeReclaimPolicy: Delete
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - <node01> 4

   1

   The path of the loop device on the node.

   2

   Specifies it is a block PV.

   3

   Optional: Set a storage class for the PV. If you omit it, the cluster default is used.

   4

   The node on which the block device was mounted.

5. Create the block PV.

   # oc create -f <local-block-pv10.yaml>1

   1

   The file name of the persistent volume created in the previous step.

Procedure

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

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

   1

   Specify the name of the Secret.

   2

   Specify the Base64-encoded key ID or user name.

   3

   Specify the Base64-encoded secret key or password.

2. Apply the Secret manifest:

   $ oc apply -f endpoint-secret.yaml

3. Create a DataVolume manifest, specifying the data source for the virtual machine image and Block for storage.volumeMode.

   apiVersion: cdi.kubevirt.io/v1beta1
   kind: DataVolume
   metadata:
     name: import-pv-datavolume 1
   spec:
     storageClassName: local 2
       source:
         http:
           url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 3
           secretRef: endpoint-secret 4
     storage:
       volumeMode: Block 5
       resources:
         requests:
           storage: 10Gi

   1

   Specify the name of the data volume.

   2

   Optional: Set the storage class or omit it to accept the cluster default.

   3

   Specify the HTTP or HTTPS URL of the image to import.

   4

   Required if you created a Secret for the data source.

   5

   The volume mode and access mode are detected automatically for known storage provisioners. Otherwise, specify Block.

4. Create the data volume to import the virtual machine image:

   $ oc create -f import-pv-datavolume.yaml

1. PVCs must request a ReadWriteMany access mode.
2. PVCs must request a ReadWriteOnce access mode.

Procedure

1. In the web console, click Workloads → Virtual Machines.
2. Click Create Virtual Machine and select Import with Wizard.
3. Select Red Hat Virtualization (RHV) from the Provider list.

4. Select Connect to New Instance or a saved RHV instance.

   • If you select Connect to New Instance, fill in the following fields:

     • API URL: For example, https://<RHV_Manager_FQDN>/ovirt-engine/api

     • CA certificate: Click Browse to upload the RHV Manager CA certificate or paste the CA certificate into the field.

       View the CA certificate by running the following command:

       $ openssl s_client -connect <RHV_Manager_FQDN>:443 -showcerts < /dev/null

       The CA certificate is the second certificate in the output.

     • Username: RHV Manager user name, for example, ocpadmin@internal
     • Password: RHV Manager password
   • If you select a saved RHV instance, the wizard connects to the RHV instance using the saved credentials.

5. Click Check and Save and wait for the connection to complete.

   Note

   The connection details are stored in a secret. If you add a provider with an incorrect URL, user name, or password, click Workloads → Secrets and delete the provider secret.

6. Select a cluster and a virtual machine.
7. Click Next.
8. In the Review screen, review your settings.
9. Optional: You can select Start virtual machine on creation.

10. Click Edit to update the following settings:

    • General → Name: The VM name is limited to 63 characters.

    • General → Description: Optional description of the VM.

      • Storage Class: Select NFS or ocs-storagecluster-ceph-rbd.

        If you select ocs-storagecluster-ceph-rbd, you must set the Volume Mode of the disk to Block.

      • Advanced → Volume Mode: Select Block.
    • Advanced → Volume Mode: Select Block.
    • Networking → Network: You can select a network from a list of available network attachment definition objects.

11. Click Import or Review and Import, if you have edited the import settings.

    A Successfully created virtual machine message and a list of resources created for the virtual machine are displayed. The virtual machine appears in Workloads → Virtual Machines.

1. You can change the access mode by using the command line interface.

Procedure

1. Create the Secret CR by running the following command:

   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: rhv-credentials
     namespace: default 1
   type: Opaque
   stringData:
     ovirt: |
       apiUrl: <api_endpoint> 2
       username: ocpadmin@internal
       password: 3
       caCert: |
         -----BEGIN CERTIFICATE-----
         4
         -----END CERTIFICATE-----
   EOF

   1

   Optional. You can specify a different namespace in all the CRs.

   2

   Specify the API endpoint of the RHV Manager, for example, \"https://www.example.com:8443/ovirt-engine/api"

   3

   Specify the password for ocpadmin@internal.

   4

   Specify the RHV Manager CA certificate. You can obtain the CA certificate by running the following command:

   $ openssl s_client -connect :443 -showcerts < /dev/null

2. Optional: Create a ResourceMapping CR if you want to separate the resource mapping from the VirtualMachineImport CR by running the following command:

   $ cat <<EOF | kubectl create -f -
   apiVersion: v2v.kubevirt.io/v1alpha1
   kind: ResourceMapping
   metadata:
     name: resourcemapping_example
     namespace: default
   spec:
     ovirt:
       networkMappings:
         - source:
             name: <rhv_logical_network>/<vnic_profile> 1
           target:
             name: <target_network> 2
           type: pod
       storageMappings: 3
         - source:
             name: <rhv_storage_domain> 4
           target:
             name: <target_storage_class> 5
           volumeMode: <volume_mode> 6
   EOF

   1

   Specify the RHV logical network and vNIC profile.

   2

   Specify the OpenShift Virtualization network.

   3

   If storage mappings are specified in both the ResourceMapping and the VirtualMachineImport CRs, the VirtualMachineImport CR takes precedence.

   4

   Specify the RHV storage domain.

   5

   Specify nfs or ocs-storagecluster-ceph-rbd.

   6

   If you specified the ocs-storagecluster-ceph-rbd storage class, you must specify Block as the volume mode.

3. Create the VirtualMachineImport CR by running the following command:

   $ cat <<EOF | oc create -f -
   apiVersion: v2v.kubevirt.io/v1beta1
   kind: VirtualMachineImport
   metadata:
     name: vm-import
     namespace: default
   spec:
     providerCredentialsSecret:
       name: rhv-credentials
       namespace: default
   # resourceMapping: 1
   #   name: resourcemapping-example
   #   namespace: default
     targetVmName: vm_example 2
     startVm: true
     source:
       ovirt:
         vm:
           id: <source_vm_id> 3
           name: <source_vm_name> 4
         cluster:
           name: <source_cluster_name> 5
         mappings: 6
           networkMappings:
             - source:
                 name: <source_logical_network>/<vnic_profile> 7
               target:
                 name: <target_network> 8
               type: pod
           storageMappings: 9
             - source:
                 name: <source_storage_domain> 10
               target:
                 name: <target_storage_class> 11
               accessMode: <volume_access_mode> 12
           diskMappings:
             - source:
                 id: <source_vm_disk_id> 13
               target:
                 name: <target_storage_class> 14
   EOF

   1

   If you create a ResourceMapping CR, uncomment the resourceMapping section.

   2

   Specify the target VM name.

   3

   Specify the source VM ID, for example, 80554327-0569-496b-bdeb-fcbbf52b827b. You can obtain the VM ID by entering https://www.example.com/ovirt-engine/api/vms/ in a web browser on the Manager machine to list all VMs. Locate the VM you want to import and its corresponding VM ID. You do not need to specify a VM name or cluster name.

   4

   If you specify the source VM name, you must also specify the source cluster. Do not specify the source VM ID.

   5

   If you specify the source cluster, you must also specify the source VM name. Do not specify the source VM ID.

   6

   If you create a ResourceMapping CR, comment out the mappings section.

   7

   Specify the logical network and vNIC profile of the source VM.

   8

   Specify the OpenShift Virtualization network.

   9

   If storage mappings are specified in both the ResourceMapping and the VirtualMachineImport CRs, the VirtualMachineImport CR takes precedence.

   10

   Specify the source storage domain.

   11

   Specify the target storage class.

   12

   Specify ReadWriteOnce, ReadWriteMany, or ReadOnlyMany. If no access mode is specified, {virt} determines the correct volume access mode based on the Host → Migration mode setting of the RHV VM or on the virtual disk access mode:

   • If the RHV VM migration mode is Allow manual and automatic migration, the default access mode is ReadWriteMany.
   • If the RHV virtual disk access mode is ReadOnly, the default access mode is ReadOnlyMany.
   • For all other settings, the default access mode is ReadWriteOnce.

   13

   Specify the source VM disk ID, for example, 8181ecc1-5db8-4193-9c92-3ddab3be7b05. You can obtain the disk ID by entering https://www.example.com/ovirt-engine/api/vms/vm23 in a web browser on the Manager machine and reviewing the VM details.

   14

   Specify the target storage class.

4. Follow the progress of the virtual machine import to verify that the import was successful:

   $ oc get vmimports vm-import -n default

   The output indicating a successful import resembles the following example:

   Example output

   ...
   status:
     conditions:
     - lastHeartbeatTime: "2020-07-22T08:58:52Z"
       lastTransitionTime: "2020-07-22T08:58:52Z"
       message: Validation completed successfully
       reason: ValidationCompleted
       status: "True"
       type: Valid
     - lastHeartbeatTime: "2020-07-22T08:58:52Z"
       lastTransitionTime: "2020-07-22T08:58:52Z"
       message: 'VM specifies IO Threads: 1, VM has NUMA tune mode specified: interleave'
       reason: MappingRulesVerificationReportedWarnings
       status: "True"
       type: MappingRulesVerified
     - lastHeartbeatTime: "2020-07-22T08:58:56Z"
       lastTransitionTime: "2020-07-22T08:58:52Z"
       message: Copying virtual machine disks
       reason: CopyingDisks
       status: "True"
       type: Processing
     dataVolumes:
     - name: fedora32-b870c429-11e0-4630-b3df-21da551a48c0
     targetVmName: fedora32

1. PVCs must request a ReadWriteMany access mode.
2. PVCs must request a ReadWriteOnce access mode.

Procedure

1. In the web console, click Workloads → Virtual Machines.
2. Click Create Virtual Machine and select Import with Wizard.
3. Select VMware from the Provider list.

4. Select Connect to New Instance or a saved vCenter instance.

   • If you select Connect to New Instance, enter the vCenter hostname, Username, and Password.
   • If you select a saved vCenter instance, the wizard connects to the vCenter instance using the saved credentials.

5. Click Check and Save and wait for the connection to complete.

   Note

   The connection details are stored in a secret. If you add a provider with an incorrect hostname, user name, or password, click Workloads → Secrets and delete the provider secret.

6. Select a virtual machine or a template.
7. Click Next.
8. In the Review screen, review your settings.

9. Click Edit to update the following settings:

   • General:

     • Description
     • Operating System
     • Flavor
     • Memory
     • CPUs
     • Workload Profile

   • Networking:

     • Name
     • Model
     • Network
     • Type
     • MAC Address

   • Storage: Click the Options menu of the VM disk and select Edit to update the following fields:

     • Name
     • Source: For example, Import Disk.
     • Size
     • Interface

     • Storage Class: Select NFS or ocs-storagecluster-ceph-rbd (ceph-rbd).

       If you select ocs-storagecluster-ceph-rbd, you must set the Volume Mode of the disk to Block.

       Other storage classes might work, but they are not officially supported.

     • Advanced → Volume Mode: Select Block.
     • Advanced → Access Mode

   • Advanced → Cloud-init:

     • Form: Enter the Hostname and Authenticated SSH Keys.
     • Custom script: Enter the cloud-init script in the text field.
   • Advanced → Virtual Hardware: You can attach a virtual CD-ROM to the imported virtual machine.

10. Click Import or Review and Import, if you have edited the import settings.

    A Successfully created virtual machine message and a list of resources created for the virtual machine are displayed. The virtual machine appears in Workloads → Virtual Machines.

Procedure

1. Create a ClusterRole manifest:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: <datavolume-cloner> 1
   rules:
   - apiGroups: ["cdi.kubevirt.io"]
     resources: ["datavolumes/source"]
     verbs: ["*"]

   1

   Unique name for the cluster role.

2. Create the cluster role in the cluster:

   $ oc create -f <datavolume-cloner.yaml> 1

   1

   The file name of the ClusterRole manifest created in the previous step.

3. Create a RoleBinding manifest that applies to both the source and destination namespaces and references the cluster role created in the previous step.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: <allow-clone-to-user> 1
     namespace: <Source namespace> 2
   subjects:
   - kind: ServiceAccount
     name: default
     namespace: <Destination namespace> 3
   roleRef:
     kind: ClusterRole
     name: datavolume-cloner 4
     apiGroup: rbac.authorization.k8s.io

   1

   Unique name for the role binding.

   2

   The namespace for the source data volume.

   3

   The namespace to which the data volume is cloned.

   4

   The name of the cluster role created in the previous step.

4. Create the role binding in the cluster:

   $ oc create -f <datavolume-cloner.yaml> 1

   1

   The file name of the RoleBinding manifest created in the previous step.

Procedure

1. Examine the virtual machine disk you want to clone to identify the name and namespace of the associated PVC.

2. Create a YAML file for a data volume that specifies the name of the new data volume, the name and namespace of the source PVC, and the size of the new data volume.

   For example:

   apiVersion: cdi.kubevirt.io/v1beta1
   kind: DataVolume
   metadata:
     name: <cloner-datavolume> 1
   spec:
     source:
       pvc:
         namespace: "<source-namespace>" 2
         name: "<my-favorite-vm-disk>" 3
     pvc:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
           storage: <2Gi> 4

   1

   The name of the new data volume.

   2

   The namespace where the source PVC exists.

   3

   The name of the source PVC.

   4

   The size of the new data volume. You must allocate enough space, or the cloning operation fails. The size must be the same as or larger than the source PVC.

3. Start cloning the PVC by creating the data volume:

   $ oc create -f <cloner-datavolume>.yaml

   Note

   Data volumes prevent a virtual machine from starting before the PVC is prepared, so you can create a virtual machine that references the new data volume while the PVC clones.