Chapter 7. Virtual machines

Procedure

1. Ensure you are in the correct project. If not, click the Project list and select the appropriate project.
2. Click Workloads Virtualization from the side menu.
3. Click the Virtual Machines tab.
4. Select a virtual machine to open the Virtual Machine Overview screen.
5. In the Details tab, click the virt-launcher-<vm-name> pod.
6. Click the Terminal tab. If the terminal is blank, select the terminal and press any key to initiate connection.

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 screen.
4. Click Console. The VNC console opens by default.
5. Click the VNC Console drop-down list and select Serial Console.

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 screen.
4. Click the Console tab. The VNC console opens by default.

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. Run the following command to create the fedora-vm-ssh service:

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

   1

   <fedora-vm> is the name of the virtual machine 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 virtual machine instance via SSH. Use the ipAddress of the node and the port that you found in the previous step:

   $ ssh username@<node_IP_address> -p 32551

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. 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. Configure a PXE network on the cluster:

   1. Create the NetworkAttachmentDefinition 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 plug-in 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 NetworkAttachmentDefinition object 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. However, note that at this time, MAC addresses assigned automatically are not persistent.

      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 NetworkAttachmentDefinition. In this scenario, <pxe-net> is connected to the NetworkAttachmentDefinition 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 Overview page.
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. Ensure you are in the correct namespace. The ConfigMap can only be referenced by DataVolumes if it is in the same namespace.

   $ oc get ns

2. Create the ConfigMap:

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

Procedure

1. Optional: If your data source requires authentication credentials, edit the endpoint-secret.yaml file, and apply the updated configuration to the cluster:

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

   1

   Optional: your key or user name, base64 encoded

   2

   Optional: your secret or password, base64 encoded

   $ oc apply -f endpoint-secret.yaml

2. Edit the virtual machine configuration file, specifying the data source for the virtual machine image you want to import. In this example, a Fedora image is imported from an http source:

   apiVersion: kubevirt.io/v1alpha3
   kind: VirtualMachine
   metadata:
     creationTimestamp: null
     labels:
       kubevirt.io/vm: vm-fedora-datavolume
     name: vm-fedora-datavolume
   spec:
     dataVolumeTemplates:
     - metadata:
         creationTimestamp: null
         name: fedora-dv
       spec:
         pvc:
           accessModes:
           - ReadWriteOnce
           resources:
             requests:
               storage: 10Gi
           storageClassName: local
         source:
           http: 1
             url: "https://download.fedoraproject.org/pub/fedora/linux/releases/33/Cloud/x86_64/images/Fedora-Cloud-Base-33-1.2.x86_64.qcow2" 2
             secretRef: "" 3
             certConfigMap: "" 4
       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: "" 5
           resources:
             requests:
               memory: 1.5Gi
         terminationGracePeriodSeconds: 60
         volumes:
         - dataVolume:
             name: fedora-dv
           name: datavolumedisk1
   status: {}

   1

   The source type to import the image from. This example uses an HTTP endpoint. To import a container disk from a registry, replace http with registry.

   2

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

   3

   The secretRef parameter is optional.

   4

   The certConfigMap is required for communicating with servers that use self-signed certificates or certificates not signed by the system CA bundle. The referenced ConfigMap must be in the same namespace as the DataVolume.

   5

   Specify type: dataVolume or type: "". If you specify any other value for type, such as persistentVolumeClaim, a warning is displayed, and the virtual machine does not start.

3. Create the virtual machine:

   $ oc create -f vm-<name>-datavolume.yaml

   Note

   The oc create command creates the DataVolume and the virtual machine. The CDI controller creates an underlying PVC with the correct annotation, and the import process begins. When the import completes, the DataVolume status changes to Succeeded, and the virtual machine is allowed to start.

   DataVolume provisioning happens in the background, so there is no need to monitor it. You can start the virtual machine, and it will not run until the import is complete.

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 DataVolume status until it shows Succeeded by running the following command:

   $ oc describe dv <datavolume-name> 1

   1

   The name of the DataVolume as specified under dataVolumeTemplates.metadata.name in the virtual machine configuration file. In the example configuration above, this is fedora-dv.

3. To verify that provisioning is complete and that the VMI has started, try accessing its serial console by running the following command:

   $ 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 configuration 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 StorageClass 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 filename of the PersistentVolume created in the previous step.

Procedure

1. If your data source requires authentication credentials, edit the endpoint-secret.yaml file, and apply the updated configuration to the cluster.

   1. Edit the endpoint-secret.yaml file with your preferred text editor:

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

      1

      Optional: your key or user name, base64 encoded

      2

      Optional: your secret or password, base64 encoded

   2. Update the secret by running the following command:

      $ oc apply -f endpoint-secret.yaml

2. Create a DataVolume configuration that specifies the data source for the image you want to import and volumeMode: Block so that an available block PV is used.

   apiVersion: cdi.kubevirt.io/v1alpha1
   kind: DataVolume
   metadata:
     name: <import-pv-datavolume> 1
   spec:
     storageClassName: local 2
     source:
         http:
            url: <http://download.fedoraproject.org/pub/fedora/linux/releases/28/Cloud/x86_64/images/Fedora-Cloud-Base-28-1.1.x86_64.qcow2> 3
            secretRef: <endpoint-secret> 4
     pvc:
       volumeMode: Block 5
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
           storage: <2Gi>

   1

   The name of the DataVolume.

   2

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

   3

   The HTTP source of the image to import.

   4

   Only required if the data source requires authentication.

   5

   Required for importing to a block PV.

3. Create the DataVolume to import the virtual machine image by running the following command:

   $ oc create -f <import-pv-datavolume.yaml>1

   1

   The file name of the DataVolume that you created in the previous step.

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

Procedure

1. In a web browser, identify the REST API name of the RHV VM operating system by navigating to http://<RHV_Manager_FQDN>/ovirt-engine/api/vms/<VM_ID>. The operating system name appears in the <os> section of the XML output, as shown in the following example:

   ...
   <os>
   ...
   <type>rhel_8x64</type>
   </os>

2. View a list of the available OpenShift Virtualization templates:

   $ oc get templates -n openshift --show-labels | tr ',' '\n' | grep os.template.kubevirt.io | sed -r 's#os.template.kubevirt.io/(.*)=.*#\1#g' | sort -u

   Example output

   fedora31
   fedora32
   ...
   rhel8.1
   rhel8.2
   ...

3. If an OpenShift Virtualization template that matches the RHV VM operating system does not appear in the list of available templates, create a template with the OpenShift Virtualization web console.

4. Create a ConfigMap to map the RHV VM operating system to the OpenShift Virtualization template:

   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: os-configmap
     namespace: default 1
   data:
     guestos2common: |
       "Red Hat Enterprise Linux Server": "rhel"
       "CentOS Linux": "centos"
       "Fedora": "fedora"
       "Ubuntu": "ubuntu"
       "openSUSE": "opensuse"
     osinfo2common: |
       "<rhv-operating-system>": "<vm-template>" 2
   EOF

   1

   Optional: You can change the value of the namespace parameter.

   2

   Specify the REST API name of the RHV operating system and its corresponding VM template as shown in the following example.

   ConfigMap example

   $ cat <<EOF | oc apply -f -
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: os-configmap
     namespace: default
   data:
     osinfo2common: |
       "other_linux": "fedora31"
   EOF

5. Verify that the custom ConfigMap was created:

   $ oc get cm -n default os-configmap -o yaml

6. Edit the kubevirt-hyperconverged-operator.v2.4.9.yaml file:

   $ oc edit clusterserviceversion -n openshift-cnv kubevirt-hyperconverged-operator.v2.4.9

7. Update the following parameters of the vm-import-operator deployment manifest:

   ...
   spec:
     containers:
     - env:
       ...
       - name: OS_CONFIGMAP_NAME
         value: os-configmap 1
       - name: OS_CONFIGMAP_NAMESPACE
         value: default 2

   1

   Add value: os-configmap to the name: OS_CONFIGMAP_NAME parameter.

   2

   Optional: You can add this value if you changed the namespace in the ConfigMap.

8. Save the kubevirt-hyperconverged-operator.v2.4.9.yaml file.

   Updating the vm-import-operator deployment updates the vm-import-controller ConfigMap.

9. Verify that the template appears in the OpenShift Virtualization web console:

   1. Click Workloads Virtualization from the side menu.
   2. Click the Virtual Machine Templates tab and find the template in the list.

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, admin@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: admin@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 admin@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/v1alpha1
   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.

Procedure

1. Click Workloads Virtual Machines.
2. Click the Options menu of the virtual machine you are importing and select Delete Virtual Machine.

3. In the Delete Virtual Machine window, click Delete.

   The virtual machine is removed from the list of virtual machines.

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 host name, 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: You must select the masquerade binding method.
     • 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 ClusterRole.

2. Create the ClusterRole 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 ClusterRole 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 RoleBinding.

   2

   The namespace for the source DataVolume.

   3

   The namespace to which the DataVolume is cloned.

   4

   The name of the ClusterRole created in the previous step.

4. Create the RoleBinding 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 DataVolume object that specifies the name of the new DataVolume, the name and namespace of the source PVC, and the size of the new DataVolume.

   For example:

   apiVersion: cdi.kubevirt.io/v1alpha1
   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 DataVolume.

   2

   The namespace where the source PVC exists.

   3

   The name of the source PVC.

   4

   The size of the new DataVolume. 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 DataVolume:

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

   Note

   DataVolumes prevent a virtual machine from starting before the PVC is prepared, so you can create a virtual machine that references the new DataVolume while the PVC clones.

Procedure

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

2. Create a YAML file for a VirtualMachine object. The following virtual machine example clones my-favorite-vm-disk, which is located in the source-namespace namespace. The 2Gi DataVolume called favorite-clone is created from my-favorite-vm-disk.

   For example:

   apiVersion: kubevirt.io/v1alpha3
   kind: VirtualMachine
   metadata:
     labels:
       kubevirt.io/vm: vm-dv-clone
     name: vm-dv-clone 1
   spec:
     running: false
     template:
       metadata:
         labels:
           kubevirt.io/vm: vm-dv-clone
       spec:
         domain:
           devices:
             disks:
             - disk:
                 bus: virtio
               name: root-disk
           resources:
             requests:
               memory: 64M
         volumes:
         - dataVolume:
             name: favorite-clone
           name: root-disk
     dataVolumeTemplates:
     - metadata:
         name: favorite-clone
       spec:
         pvc:
           accessModes:
           - ReadWriteOnce
           resources:
             requests:
               storage: 2Gi
         source:
           pvc:
             namespace: "source-namespace"
             name: "my-favorite-vm-disk"

   1

   The virtual machine to create.

3. Create the virtual machine with the PVC-cloned DataVolume:

   $ oc create -f <vm-clone-datavolumetemplate>.yaml

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 configuration 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 StorageClass 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 filename of the PersistentVolume 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 DataVolume object that specifies the name of the new DataVolume, the name and namespace of the source PVC, volumeMode: Block so that an available block PV is used, and the size of the new DataVolume.

   For example:

   apiVersion: cdi.kubevirt.io/v1alpha1
   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
       volumeMode: Block 5

   1

   The name of the new DataVolume.

   2

   The namespace where the source PVC exists.

   3

   The name of the source PVC.

   4

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

   5

   Specifies that the destination is a block PV

3. Start cloning the PVC by creating the DataVolume:

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

   Note

   DataVolumes prevent a virtual machine from starting before the PVC is prepared, so you can create a virtual machine that references the new DataVolume while the PVC clones.

Procedure

1. Edit the interfaces spec of your virtual machine configuration file:

   kind: VirtualMachine
   spec:
     domain:
       devices:
         interfaces:
           - name: red
             masquerade: {} 1
             ports:
               - port: 80 2
     networks:
     - name: red
       pod: {}

   1

   Connect using masquerade mode

   2

   Allow incoming traffic on port 80

2. Create the virtual machine:

   $ oc create -f <vm-name>.yaml

Procedure

1. Edit the virtual machine YAML as follows:

   apiVersion: kubevirt.io/v1alpha3
   kind: VirtualMachine
   metadata:
     name: vm-ephemeral
     namespace: example-namespace
   spec:
     running: false
     template:
       metadata:
         labels:
           special: key 1
       spec:
         domain:
           devices:
             disks:
               - name: containerdisk
                 disk:
                   bus: virtio
               - name: cloudinitdisk
                 disk:
                   bus: virtio
             interfaces:
             - masquerade: {}
               name: default
           resources:
             requests:
               memory: 1024M
         networks:
           - name: default
             pod: {}
         volumes:
           - name: containerdisk
             containerDisk:
               image: kubevirt/fedora-cloud-container-disk-demo
           - name: cloudinitdisk
             cloudInitNoCloud:
               userData: |
                 #!/bin/bash
                 echo "fedora" | passwd fedora --stdin

   1

   Add the label special: key in the spec.template.metadata.labels section.

   Note

   Labels on a virtual machine are passed through to the pod. The labels on the VirtualMachine, for example special: key, must match the labels in the Service YAML selector attribute, which you create later in this procedure.

2. Save the virtual machine YAML to apply your changes.

3. Edit the Service YAML to configure the settings necessary to create and expose the Service object:

   apiVersion: v1
   kind: Service
   metadata:
     name: vmservice 1
     namespace: example-namespace 2
   spec:
     ports:
     - port: 27017
       protocol: TCP
       targetPort: 22 3
     selector:
       special: key 4
     type: ClusterIP 5

   1

   Specify the name of the service you are creating and exposing.

   2

   Specify namespace in the metadata section of the Service YAML that corresponds to the namespace you specify in the virtual machine YAML.

   3

   Add targetPort: 22, exposing the service on SSH port 22.

   4

   In the spec section of the Service YAML, add special: key to the selector attribute, which corresponds to the labels you added in the virtual machine YAML configuration file.

   5

   In the spec section of the Service YAML, add type: ClusterIP for a ClusterIP service. To create and expose other types of services externally, outside of the cluster, such as NodePort and LoadBalancer, replace type: ClusterIP with type: NodePort or type: LoadBalancer, as appropriate.

4. Save the Service YAML to store the service configuration.

5. Create the ClusterIP service:

   $ oc create -f <service_name>.yaml

6. Start the virtual machine. If the virtual machine is already running, restart it.

7. Query the Service object to verify it is available and is configured with type ClusterIP.

   Verification

   • Run the oc get service command, specifying the namespace that you reference in the virtual machine and Service YAML files.

     $ oc get service -n example-namespace

     Example output

     NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
     vmservice   ClusterIP   172.30.3.149   <none>        27017/TCP   2m

     • As shown from the output, vmservice is running.
     • The TYPE displays as ClusterIP, as you specified in the Service YAML.

8. Establish a connection to the virtual machine that you want to use to back your service. Connect from an object inside the cluster, such as another virtual machine.

   1. Edit the virtual machine YAML as follows:

      apiVersion: kubevirt.io/v1alpha3
      kind: VirtualMachine
      metadata:
        name: vm-connect
        namespace: example-namespace
      spec:
        running: false
        template:
          spec:
            domain:
              devices:
                disks:
                  - name: containerdisk
                    disk:
                      bus: virtio
                  - name: cloudinitdisk
                    disk:
                      bus: virtio
                interfaces:
                - masquerade: {}
                  name: default
              resources:
                requests:
                  memory: 1024M
            networks:
              - name: default
                pod: {}
            volumes:
              - name: containerdisk
                containerDisk:
                  image: kubevirt/fedora-cloud-container-disk-demo
              - name: cloudinitdisk
                cloudInitNoCloud:
                  userData: |
                    #!/bin/bash
                    echo "fedora" | passwd fedora --stdin

   2. Run the oc create command to create a second virtual machine, where file.yaml is the name of the virtual machine YAML:

      $ oc create -f <file.yaml>

   3. Start the virtual machine.

   4. Connect to the virtual machine by running the following virtctl command:

      $ virtctl -n example-namespace console <new-vm-name>

      Note

      For service type LoadBalancer, use the vinagre client to connect your virtual machine by using the public IP and port. External ports are dynamically allocated when using service type LoadBalancer.

   5. Run the ssh command to authenticate the connection, where 172.30.3.149 is the ClusterIP of the service and fedora is the user name of the virtual machine:

      $ ssh fedora@172.30.3.149 -p 27017

      Verification

      • You receive the command prompt of the virtual machine backing the service you want to expose. You now have a service backed by a running virtual machine.

Procedure

1. In the correct project 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 screen.
4. Click Network Interfaces to display the NICs already attached to the virtual machine.
5. Click Add Network Interface to create a new slot in the list.
6. Fill in the Name, Model, Network, Type, and MAC Address for the new NIC.
7. Click the Add button to save and attach the NIC to the virtual machine.

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.

2. 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.

3. 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 the following SriovNetwork object, and then save the YAML in the <name>-sriov-network.yaml file. Replace <name> with a name for this additional network.