Chapter 6. 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 Virtual Machines to display the virtual machines in the project.
3. Select a virtual machine.
4. In the Overview tab, click the virt-launcher-<vm-name> pod.
5. Click the Terminal tab. If the terminal is blank, select the terminal and press any key to initiate connection.

Procedure

1. In the container-native virtualization console, click Workloads Virtual Machines.
2. Select a virtual machine.
3. Click Consoles. The VNC console opens by default.
4. Click the VNC Console drop-down list and select Serial Console.

Procedure

1. In the container-native virtualization console, click Workloads Virtual Machines.
2. Select a virtual machine.
3. Click Consoles. The VNC console opens by default.

Procedure

1. In the container-native virtualization console, click Workloads Virtual Machines.
2. Select a Windows virtual machine.
3. Click the Consoles tab.
4. Click the Consoles list and select Desktop Viewer.
5. In the Network Interface list, select the layer-2 NIC.
6. Click Launch Remote Desktop to download the console.rdp file.

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

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

8. 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
   NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
   fedora-vm-ssh   NodePort   127.0.0.1      <none>        20022:32551/TCP   6s

   In this example, the service acquired the 32551 port.

3. 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 container-native 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>

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

   (...)
   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"
              },
              {
                "type": "cnv-tuning" 1
              }
            ]
          }'

      1

      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
     virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created

5. Wait for the virtual machine instance to run:

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

6. View the virtual machine instance using VNC:

   $ virtctl vnc vmi-pxe-boot

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

8. Log in to the virtual machine instance:

   $ virtctl console vmi-pxe-boot

9. 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
   ...
   3. eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
      link/ether de:00:00:00:00:de brd ff:ff:ff:ff:ff:ff

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. 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. Identify an HTTP file server that hosts the virtual disk image that you want to import. You need the complete URL in the correct format:

   • http://www.example.com/path/to/data

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

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

   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: 2Gi
           storageClassName: local
         source:
           http:
             url: https://download.fedoraproject.org/pub/fedora/linux/releases/28/Cloud/x86_64/images/Fedora-Cloud-Base-28-1.1.x86_64.qcow2 1
             secretRef: "" 2
             certConfigMap: "" 3
       status: {}
     running: false
     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: 64M
         terminationGracePeriodSeconds: 0
         volumes:
         - dataVolume:
             name: fedora-dv
           name: datavolumedisk1
   status: {}

   1

   The HTTP source of the image you want to import.

   2

   The secretRef parameter is optional.

   3

   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.

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

Optional verification steps

1. Run oc get pods and look for the importer Pod. This Pod downloads the image from the specified URL and stores it on the provisioned PV.

2. Monitor the DataVolume status until it shows Succeeded.

   $ oc describe dv <data-label> 1

   1

   The data label for the DataVolume specified in the virtual machine configuration file.

3. To verify that provisioning is complete and that the VMI has started, try 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 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:

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

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

   1

   The filename DataVolume created in the previous step.

Procedure

1. Create and navigate to a temporary directory:

   $ mkdir /tmp/<dir_name> && cd /tmp/<dir_name>

2. In a browser, navigate to VMware code and click SDKs.
3. Under Compute Virtualization, click Virtual Disk Development Kit (VDDK).
4. Select the latest VDDK release, click Download, and then save the VDDK archive in the temporary directory.

5. Extract the VDDK archive:

   $ tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz

6. Create a Dockerfile:

   $ cat > Dockerfile <<EOF
   FROM busybox:latest
   COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib
   RUN mkdir -p /opt
   ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"]
   EOF

7. Build the image:

   $ podman build . -t <registry_route_or_server_path>/vddk:<tag> 1

   1

   Specify your image registry:

   • For an internal OpenShift Container Platform registry, use the internal registry route, for example, image-registry.openshift-image-registry.svc:5000/openshift/vddk:<tag>.
   • For an external registry, specify the server name, path, and tag, for example, server.example.com:5000/vddk:<tag>.

8. Push the image to the registry:

   $ podman push <registry_route_or_server_path>/vddk:<tag>

9. Ensure that the image is accessible to your OpenShift Container Platform environment.

10. Edit the v2v-vmware ConfigMap in the openshift-cnv project:

    $ oc edit configmap v2v-vmware -n openshift-cnv

11. Add the vddk-init-image parameter to the data stanza:

    ...
    data:
      vddk-init-image: <registry_route_or_server_path>/vddk:<tag>

Procedure

1. In the container-native virtualization web console, click Workloads Virtual Machines.
2. Click Create Virtual Machine and select Import with Wizard.

3. In the General screen, perform the following steps:

   1. Select VMware from the Provider list.

   2. Select Connect to New Instance or a saved vCenter instance from the vCenter instance list.

      • If you select Connect to New Instance, fill in the vCenter hostname, Username, and Password.
      • If you select a saved vCenter instance, the wizard connects to the vCenter instance using the saved credentials.
   3. Select a virtual machine or a template to import from the VM or Template to Import list.
   4. Select an operating system.

   5. Select an existing flavor or Custom from the Flavor list.

      If you select Custom, specify the Memory (GB) and the CPUs.

   6. Select a Workload Profile.
   7. If the virtual machine name is already being used by another virtual machine in the namespace, update the name.
   8. Click Next.

4. In the Networking screen, perform the following steps:

   1. Click the Options menu of a network interface and select Edit.

   2. Enter a valid network interface name.

      The name can contain lowercase letters (a-z), numbers (0-9), and hyphens (-), up to a maximum of 253 characters. The first and last characters must be alphanumeric. The name must not contain uppercase letters, spaces, periods (.), or special characters.

   3. Select the network interface model.
   4. Select the network definition.
   5. Select the network interface type.
   6. Enter the MAC address.
   7. Click Save and then click Next.

5. In the Storage screen, perform the following steps:

   1. Click the Options menu of a disk and select Edit.

   2. Enter a valid name.

      The name can contain lowercase letters (a-z), numbers (0-9), and hyphens (-), up to a maximum of 253 characters. The first and last characters must be alphanumeric. The name must not contain uppercase letters, spaces, periods (.), or special characters.

   3. Select the interface type.

   4. Select the storage class.

      If you do not select a storage class, container-native virtualization uses the default storage class to create the virtual machine.

   5. Click Save and then click Next.
6. In the Advanced screen, enter the Hostname and Authorized SSH Keys if you are using cloud-init.
7. Click Next.

8. Review your settings and click Create Virtual Machine.

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

9. Click See virtual machine details to view the dashboard of the imported virtual machine.

   If an error occurs, perform the following steps:

   1. Click Workloads Pods.
   2. Click the Conversion Pod, for example, kubevirt-v2v-conversion-rhel7-mini-1-27b9h.
   3. Click Logs and check for error messages.

Procedure

1. Log in to the virtual machine.
2. Go to the /etc/sysconfig/network-scripts directory.

3. Change the network configuration file name to ifcfg-eth0:

   $ mv vmnic0 ifcfg-eth0 1

   1

   Additional network configuration files are numbered sequentially, for example, ifcfg-eth1, ifcfg-eth2.

4. Update the NAME and DEVICE parameters in the network configuration file:

   NAME=eth0
   DEVICE=eth0

5. Restart the network:

   $ systemctl restart network

1. Obtain the Conversion Pod name:

   $ oc get pods -n <project> | grep v2v 1
   kubevirt-v2v-conversion-f66f7d-zqkz7            1/1     Running     0          4h49m

   1

   Specify the project of your imported virtual machine.

2. Obtain the Conversion Pod log:

   $ oc logs kubevirt-v2v-conversion-f66f7d-zqkz7 -f -n <project>

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. In the correct project in the container-native virtualization console, click Workloads Virtual Machines.
2. Select a virtual machine.
3. Click Network Interfaces to display the NICs already attached to the virtual machine.
4. Click Create Network Interface to create a new slot in the list.
5. Fill in the Name, Model, Network, Type, and MAC Address for the new NIC.
6. Click the ✓ button to save and attach the NIC to the virtual machine.

Procedure

1. Access the virtual machine command line through one of the consoles or by SSH.

2. Install the QEMU guest agent on the virtual machine:

   $ yum install -y qemu-guest-agent

3. Start the QEMU guest agent service:

   $ systemctl start qemu-guest-agent

4. Ensure the service is persistent:

   $ systemctl enable qemu-guest-agent

1. Verify that the guest agent is installed and running by entering the following command:

   $ systemctl status qemu-guest-agent

2. If the guest agent is not installed and running, install and run the guest agent on the virtual machine.

Procedure

1. In the container-native virtualization console, click Workloads Virtual Machines.
2. Click the virtual machine name to open the Virtual Machine Overview screen.

Procedure

1. Create the MachineConfig file. For example:

   $ touch machineconfig.yaml

2. Edit the file, ensuring that you include the directory where you want the hostpath provisioner to create PVs. For example:

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     name: 50-set-selinux-for-hostpath-provisioner
     labels:
       machineconfiguration.openshift.io/role: worker
   spec:
     config:
       ignition:
         version: 2.2.0
       systemd:
         units:
           - contents: |
               [Unit]
               Description=Set SELinux chcon for hostpath provisioner
               Before=kubelet.service
   
               [Service]
               ExecStart=/usr/bin/chcon -Rt container_file_t <path/to/backing/directory> 1
   
               [Install]
               WantedBy=multi-user.target
             enabled: true
             name: hostpath-provisioner.service

   1

   Specify the backing directory where you want the provisioner to create PVs.

3. Create the MachineConfig object:

   $ oc create -f machineconfig.yaml -n <namespace>

Procedure

1. Create the HostPathProvisioner custom resource file. For example:

   $ touch hostpathprovisioner_cr.yaml

2. Edit the file, ensuring that the spec.pathConfig.path value is the directory where you want the hostpath provisioner to create PVs. For example:

   apiVersion: hostpathprovisioner.kubevirt.io/v1alpha1
   kind: HostPathProvisioner
   metadata:
     name: hostpath-provisioner
   spec:
     imagePullPolicy: IfNotPresent
     pathConfig:
       path: "</path/to/backing/directory>" 1
       useNamingPrefix: "false" 2

   1

   Specify the backing directory where you want the provisioner to create PVs.

   2

   Change this value to true if you want to use the name of the PersistentVolumeClaim (PVC) that is bound to the created PV as the prefix of the directory name.

   Note

   If you did not create the backing directory, the provisioner attempts to create it for you. If you did not apply the container_file_t SELinux context, this can cause Permission denied errors.

3. Create the custom resource in the openshift-cnv namespace:

   $ oc create -f hostpathprovisioner_cr.yaml -n openshift-cnv

Procedure

1. Create a YAML file for defining the storage class. For example:

   $ touch storageclass.yaml

2. Edit the file. For example:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hostpath-provisioner 1
   provisioner: kubevirt.io/hostpath-provisioner
   reclaimPolicy: Delete 2
   volumeBindingMode: WaitForFirstConsumer 3

   1

   You can optionally rename the storage class by changing this value.

   2

   The two possible reclaimPolicy values are Delete and Retain. If you do not specify a value, the storage class defaults to Delete.

   3

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

3. Create the StorageClass object:

   $ oc create -f storageclass.yaml

Procedure

1. Create a DataVolume configuration that specifies spec: source: upload{}:

   apiVersion: cdi.kubevirt.io/v1alpha1
   kind: DataVolume
   metadata:
     name: <upload-datavolume> 1
   spec:
     source:
         upload: {}
     pvc:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
           storage: <2Gi> 2

   1

   The name of the DataVolume.

   2

   The size of the DataVolume. Ensure that this value is greater than or equal to the size of the disk that you upload.

2. Create the DataVolume by running the following command:

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

Procedure

1. Identify the following items:

   • The name of the upload DataVolume that you want to use. If this DataVolume does not exist, it is created automatically.
   • The size of the DataVolume, if you want it to be created during the upload procedure. The size must be greater than or equal to the size of the disk image.
   • The file location of the virtual machine disk image that you want to upload.

2. Upload the disk image by running the virtctl image-upload command. Specify the parameters that you identified in the previous step. For example:

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

   1

   The name of the DataVolume.

   2

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

   3

   The file path of the virtual machine disk image.

   Note
   • If you do not want to create a new DataVolume, omit the --size parameter and include the --no-create flag.
   • To allow insecure server connections when using HTTPS, use the --insecure parameter. Be aware that when you use the --insecure flag, the authenticity of the upload endpoint is not verified.

3. Optional. To verify that a DataVolume was created, view all DataVolume objects by running the following command:

   $ oc get dvs

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. Create a DataVolume configuration that specifies spec: source: upload{}:

   apiVersion: cdi.kubevirt.io/v1alpha1
   kind: DataVolume
   metadata:
     name: <upload-datavolume> 1
   spec:
     source:
         upload: {}
     pvc:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
           storage: <2Gi> 2

   1

   The name of the DataVolume.

   2

   The size of the DataVolume. Ensure that this value is greater than or equal to the size of the disk that you upload.

2. Create the DataVolume by running the following command:

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

Procedure

1. Identify the following items:

   • The name of the upload DataVolume that you want to use. If this DataVolume does not exist, it is created automatically.
   • The size of the DataVolume, if you want it to be created during the upload procedure. The size must be greater than or equal to the size of the disk image.
   • The file location of the virtual machine disk image that you want to upload.

2. Upload the disk image by running the virtctl image-upload command. Specify the parameters that you identified in the previous step. For example:

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

   1

   The name of the DataVolume.

   2

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

   3

   The file path of the virtual machine disk image.

   Note
   • If you do not want to create a new DataVolume, omit the --size parameter and include the --no-create flag.
   • To allow insecure server connections when using HTTPS, use the --insecure parameter. Be aware that when you use the --insecure flag, the authenticity of the upload endpoint is not verified.

3. Optional. To verify that a DataVolume was created, view all DataVolume objects by running the following command:

   $ oc get dvs

Procedure

1. Either create a new local PV on the node, or identify a local PV already on the node:

   • Create a local PV that includes the nodeAffinity.nodeSelectorTerms parameters. The following manifest creates a 10Gi local PV on node01.

     kind: PersistentVolume
     apiVersion: v1
     metadata:
       name: <destination-pv> 1
       annotations:
     spec:
       accessModes:
       - ReadWriteOnce
       capacity:
         storage: 10Gi 2
       local:
         path: /mnt/local-storage/local/disk1 3
       nodeAffinity:
         required:
           nodeSelectorTerms:
           - matchExpressions:
             - key: kubernetes.io/hostname
               operator: In
               values:
               - node01 4
       persistentVolumeReclaimPolicy: Delete
       storageClassName: local
       volumeMode: Filesystem

     1

     The name of the PV.

     2

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

     3

     The mount path on the node.

     4

     The name of the node where you want to create the PV.

   • Identify a PV that already exists on the target node. You can identify the node where a PV is provisioned by viewing the nodeAffinity field in its configuration:

     $ oc get pv <destination-pv> -o yaml

     The following snippet shows that the PV is on node01:

     ...
     spec:
       nodeAffinity:
         required:
           nodeSelectorTerms:
           - matchExpressions:
             - key: kubernetes.io/hostname 1
               operator: In
               values:
               - node01 2
     ...

     1

     The kubernetes.io/hostname key uses the node host name to select a node.

     2

     The host name of the node.

2. Add a unique label to the PV:

   $ oc label pv <destination-pv> node=node01

3. Create a DataVolume manifest that references the following:

   • The PVC name and namespace of the virtual machine.
   • The label you applied to the PV in the previous step.

   • The size of the destination PV.

     apiVersion: cdi.kubevirt.io/v1alpha1
     kind: DataVolume
     metadata:
       name: <clone-datavolume> 1
     spec:
       source:
         pvc:
           name: "<source-vm-disk>" 2
           namespace: "<source-namespace>" 3
       pvc:
         accessModes:
           - ReadWriteOnce
         selector:
           matchLabels:
             node: node01 4
         resources:
           requests:
             storage: <10Gi> 5

     1

     The name of the new DataVolume.

     2

     The name of the source PVC. If you do not know the PVC name, you can find it in the virtual machine configuration: spec.volumes.persistentVolumeClaim.claimName.

     3

     The namespace where the source PVC exists.

     4

     The label that you applied to the PV in the previous step.

     5

     The size of the destination PV.

4. Start the cloning operation by applying the DataVolume manifest to your cluster:

   $ oc apply -f <clone-datavolume.yaml>

Procedure

1. Edit the DataVolume configuration file:

   apiVersion: cdi.kubevirt.io/v1alpha1
   kind: DataVolume
   metadata:
     name: blank-image-datavolume
   spec:
     source:
         blank: {}
     pvc:
       # Optional: Set the storage class or omit to accept the default
       # storageClassName: "hostpath"
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
           storage: 500Mi

2. Create the blank disk image by running the following command:

   $ oc create -f <blank-image-datavolume>.yaml

Procedure

1. Click Workloads Config Maps from the side menu.
2. In the Project list, select openshift-cnv.
3. Click kubevirt-storage-class-defaults to open the Config Map Overview.
4. Click the YAML tab to display the editable configuration.

5. Update the data values with the storage configuration that is appropriate for your underlying storage:

   ...
   data:
     accessMode: ReadWriteOnce 1
     volumeMode: Filesystem 2
     <new>.accessMode: ReadWriteMany 3
     <new>.volumeMode: Block 4

   1

   The default accessMode is ReadWriteOnce.

   2

   The default volumeMode is Filesystem.

   3

   If you add an access mode for a storage class, replace the <new> part of the parameter with the storage class name.

   4

   If you add a volume mode for a storage class, replace the <new> part of the parameter with the storage class name.

6. Click Save to update the ConfigMap.

Procedure

1. Use oc edit to edit the ConfigMap:

   $ oc edit configmap kubevirt-storage-class-defaults -n openshift-cnv

2. Update the data values of the ConfigMap:

   ...
   data:
     accessMode: ReadWriteOnce 1
     volumeMode: Filesystem 2
     <new>.accessMode: ReadWriteMany 3
     <new>.volumeMode: Block 4

   1

   The default accessMode is ReadWriteOnce.

   2

   The default volumeMode is Filesystem.

   3

   If you add an access mode for storage class, replace the <new> part of the parameter with the storage class name.

   4

   If you add a volume mode for a storage class, replace the <new> part of the parameter with the storage class name.

3. Save and exit the editor to update the ConfigMap.