Container-native virtualization

Procedure

1. In the container-native virtualization console, click Workloads → Virtual Machines.

2. Start the virtual machine from this screen, which makes it easier to perform actions on multiple virtual machines in the one screen, or from the Virtual Machine Details screen where you can view comprehensive details of the selected virtual machine:

   • Click the Options menu at the end of virtual machine and select Start Virtual Machine.
   • Click the virtual machine name to open the Virtual Machine Details screen and click Actions and select Start Virtual Machine.
3. In the confirmation window, click Start to start the virtual machine.

Procedure

1. In the container-native virtualization console, click Workloads → Virtual Machines.

2. Restart the virtual machine from this screen, which makes it easier to perform actions on multiple virtual machines in the one screen, or from the Virtual Machine Details screen where you can view comprehensive details of the selected virtual machine:

   • Click the Options menu at the end of virtual machine and select Restart Virtual Machine.
   • Click the virtual machine name to open the Virtual Machine Details screen and click Actions and select Restart Virtual Machine.
3. In the confirmation window, click Restart to restart the virtual machine.

Procedure

1. In the container-native virtualization console, click Workloads → Virtual Machines.

2. Stop the virtual machine from this screen, which makes it easier to perform actions on multiple virtual machines in the one screen, or from the Virtual Machine Details screen where you can view comprehensive details of the selected virtual machine:

   • Click the Options menu at the end of virtual machine and select Stop Virtual Machine.
   • Click the virtual machine name to open the Virtual Machine Details screen and click Actions and select Stop Virtual Machine.
3. In the confirmation window, click Stop to stop the virtual machine.

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

   Copy to Clipboard Toggle word wrap
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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

Procedure

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

   $ virtctl vnc <VMI>

   Copy to Clipboard Toggle word wrap

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

   $ virtctl vnc <VMI> -v 4

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   $ oc describe vmi <windows-vmi-name>

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
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:

   Copy to Clipboard Toggle word wrap
   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

      
              }
            ]
          }'

      Copy to Clipboard Toggle word wrap

      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

   Copy to Clipboard Toggle word wrap

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

      Copy to Clipboard Toggle word wrap
      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

      Copy to Clipboard Toggle word wrap

   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

      Copy to Clipboard Toggle word wrap

4. Create the virtual machine instance:

   $ oc create -f vmi-pxe-boot.yaml
     virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created

   Copy to Clipboard Toggle word wrap

5. Wait for the virtual machine instance to run:

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

   Copy to Clipboard Toggle word wrap

6. View the virtual machine instance using VNC:

   $ virtctl vnc vmi-pxe-boot

   Copy to Clipboard Toggle word wrap
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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

2. Create the ConfigMap:

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   1

   Optional: your key or user name, base64 encoded

   2

   Optional: your secret or password, base64 encoded

   $ oc apply -f endpoint-secret.yaml

   Copy to Clipboard Toggle word wrap

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: {}

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap
   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

   Copy to Clipboard Toggle word wrap

   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>

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

3. Mount the loop10 file as a loop device.

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

   1

   2

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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

      Copy to Clipboard Toggle word wrap

      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

      Copy to Clipboard Toggle word wrap

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>

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   1

   The filename DataVolume created in the previous step.