OpenShift Virtualization Basics

This lab will introduce you to the basics of creating and managing VMs in OpenShift Virtualization. You will see how the web console guides you through the whole process and how easy it is to review VM properties and do some basic customization. In the next lab you will customize the VMs a little bit further.

Among other things, this lab will show two methods for provisioning virtual machines, however, there are many different ways, and they are not limited to just what is shown here. All VM provisioning methods work with all supported operating systems.

Creating virtual machines is one of the most frequently accomplished tasks for a virtualization administrator. This section will walk through the process of creating a new virtual machine using a pre-created template. As the virtualization administrator, you have the ability to create your own templates that use guest operating system disks with your organization’s customizations, preferred VM sizing options, and additional customization options using cloud-init or sysprep.

In this lab, you become familiar with running virtual machines (VMs) on Red Hat^® OpenShift^® Container Platform. You create a new virtual machine based on a bootable operating system disk image provided in the default configuration of OpenShift Virtualization.

Goals

Understand the difference between an VM and a VMI
Create a new virtual machine
Access the VM console
Gain experience using the VM console

Difference betwen a VM and VMI

In general, a virtual machine (VM) is a virtual environment that simulates the resources of a physical machine, which include CPU, memory, network interfaces, and storage. Typically, VMs maintain application state and persistent data, similar to StatefulSet pods.

In Red Hat OpenShift Virtualization, a VM object specifies a template to create a running instance of the VM inside your cluster. The running instance of a VM is a virtual machine instance (VMI). A container inside a pod executes and manages the VMI.

The relationship between a VM and a VMI is similar to the relationship between a deployment and a replica set. A VM object specifies the template for a VMI pod. If a VMI is deleted, then Kubernetes generates another instance that is based on the VM object configuration.

When a VM is created and started, a virt-controller pod signals to a virt-handler pod on a cluster node to create a virt-launcher pod for the VMI. The virt-launcher pod consists of a running libvirtd container instance to execute the VMI as an isolated process.

Log in to your OpenShift console

As a reminder, here are your credentials for the OpenShift Console:

Your OpenShift cluster console is available {openshift_console_url}[here^].

Administrator login is available with:

User: {openshift_cluster_admin_username}
Password: {openshift_cluster_admin_password}

Create a new Project

Like other objects in OpenShift, Projects, which are an abstraction for Kubnernetes namespaces, are the boundaries for permissions and other aspects of using and maintaining the resources. Creating a Project is an important first step for any deployment.

Browse to Virtualization → VirtualMachines using the left navigation menu:

The Virtualization tab is available only when Red Hat OpenShift Virtualization is installed and properly configured.
Examine the VirtualMachines dashboard that appears. There are currently no VMs running.
Before creating a VM we need to create a new project. Virtual machines are deployed to a specific project, or namespace, where, by default, users without permission to the namespace cannot access, manage, or control them. Administrators can access all projects, and therefore view all virtual machines, however regular users must be given access to projects as needed.
1. Click Project: All Projects and then click Create Project.
2. In the Name field, type vmexamples to name the project, then click Create.

Create a Linux virtual machine

From the Virtual Machines inventory, click on the Create VirtualMachine button and select From template from the drop-down menu.

VMs can also be created from an InstanceType wizard as well as created by entering a custom YAML definition, but for this current lab scenario we are going to stick with creating VMs based on existing templates.

The wizard will appear showing the available pre-defined VM templates.

Reviewing the list of available templates you’ll notice that some have a blue badge which indicates "Source available". These are templates which are using the automatically downloaded and stored template disks reviewed in the previous page. If you were deploying in your own environment, you have the option of preventing these from being created and/or removing those source disks, followed by creating and uploading custom disks for your organization.
Select the Fedora VM tile, and a dialog opens.
Change the name to fedora01 and press Quick create VirtualMachine:
After about 30 seconds, expect to see the VM is Running. During this time, the storage provider has cloned the template disk so that it can be used by the newly created virtual machine. The amount of time this takes will depend on the storage provider.
After the VM is created, examine the Events tab to see some details of the process. If there are any issues with the creation of the VM, they will show up on this tab as well.
- A DataVolume is created. DataVolumes are used to manage the creation of a VM disk, abstracting the clone or import process onto OpenShift native storage during the virtual machine’s creation flow.
- The VM is started.
Click the Overview tab to return to the primary screen detailing information related to the VM. Note that for this template, the default is 1 CPU and 2 GiB of memory. As the administrator, you can create templates that customize the default configuration of virtual machines. Later in this lab we will have the opportunity to explore the creation of custom templates.

The IP address of the virtual machine on the software-defined network (SDN) is also displayed on this page, along with information about the storage devices, system utilization, the cluster node hosting the virtual machine, and more. By default VMs are attached to the default pod network. Later in this lab we will explore advanced networking options, and how to customize connectivity for VMs.

Create a VM using instancetypes

Ensure that you are working in the vmexamples project (namespace).
Browse to Virtualization → VirtualMachines using the left navigation menu.
From the Virtual Machines inventory, click on the Create VirtualMachine button and select From InstanceType from the drop-down menu.
In the Select volume to boot from section, select the fedora boot volume.
Scroll down to the Select InstanceType section, click on the General Purpose InstanceType tile, and select the small (1 CPUs, 2 GiB Memory) instance type.
Scroll down to the VirtualMachine details section, change the VM’s Name to fedora02, and click the Create VirtualMachine button.

Access the virtual machine console

Click the Console tab to access the VM’s console. Note that login credentials are shown for the fedora user. These are only shown when they have been injected into the guest via cloud-init.

If you are using a non US or International Keyboard in your system, you could change the virtual machine settings to match your system’s keyboard layout. To do this, in your VM console type the following command: sudo localectl set-keymap <lang>. For example, for German, the command will be: sudo localectl set-keymap <de>. For a complete list of available keymaps, you can run the command localectl list-keymaps.

Unfortunately this will most likely break the copy/paste functionality for username and password in the VNC console: this will switch keyboard mapping. When passwords contain affected characters, they will be entered wrong. For example, a password like yyf8-khyi-bbgt will be entered as zzf8-khzi-bbgt with a german keymap. You can verify that easily when pasting the password to the login prompt, where it will be visible. The serial console is not affected.

You can click on Paste to paste the password after copying it.

If the Paste functionality is not working, take into consideration that the console input is using US keymap. One small trick is to write in the login the password to ensure you are writing the proper characters (specifically that the - character is correct).

After you log in, run the ip a command to display the interfaces and IP addresses:

Since this network adapter is connected to the SDN, the IP address assigned is an internal IP address used by the KVM hypervisor and is not an externally accessible IP. This IP will not change even if the VM is live migrated to a different node and the external IP where the VM is connected to the SDN changes.
Run lsblk to display the list of disks and their capacities and free space:
- /dev/vda is the disk created during the VM creation and is the size specified at creation time.
- /dev/vdb is used for cloud-init required data (for example, to configure the fedora user password). This disk can be removed after the VM has been created.
Examine the number of CPUs and amount of memory associated with the VM (which match the instance type specified during creation), using the nproc and free -m commands:

To review the guest customization, mount the cloud-init disk:

sudo mount -o ro /dev/vdb /mnt

sudo cat /mnt/user-data; echo

The instance is running the guest agent to surface information about the guest OS to the hypervisor, along with coordinating tasks such as disk quiescing for snapshots. You can check by running systemctl | grep guest.
Click the Overview tab to show the information obtained from the guest VM, such as the disk utilization, along with seeing resource utilization information:
- Hostname
- Operating system version and timezone information
- Active users
- Utilization: CPU, Memory, Storage and Network.
You can navigate to the Metrics tab to obtain more information about the usage, including being able to specify the time range.

Using the CLI for VM management

The lab environment provides a bastion host, with various command-line tools, including oc and virtctl installed. To connect to the bastion host:

ssh lab-user@{bastion_public_hostname} -p {bastion_ssh_port}

The password is {bastion_ssh_password}

First, set the project (namespace) with which you are working:

[lab-user@bastion ~]$ oc project vmexamples
Now using project "vmexamples" on server "https://api.cluster-8jkpv.dynamic.redhatworkshops.io:6443".

Get the list of VMs in the current namespace:

[lab-user@bastion ~]$ oc get vms
NAME       AGE    STATUS    READY
fedora01   140m   Running   True
fedora02   113m   Running   True

Get a list of available instance types:

[lab-user@bastion ~]$ oc get vmclusterinstancetypes
NAME          AGE
cx1.2xlarge   153m
cx1.4xlarge   153m
cx1.8xlarge   153m
cx1.large     153m
cx1.medium    153m
cx1.xlarge    153m
m1.2xlarge    153m
m1.4xlarge    153m
m1.8xlarge    153m
m1.large      153m
m1.xlarge     153m
... continued

Get a list of datasources. Make sure to look in the openshift-virtualization-os-images namespace:

[lab-user@bastion ~]$ oc get datasources -n openshift-virtualization-os-images
NAME              AGE
centos-stream10   155m
centos-stream9    157m
fedora            157m
rhel10-beta       155m
rhel7             157m
rhel8             157m
rhel9             157m
win10             157m
win11             157m
win2k16           157m
win2k19           157m
win2k22           157m
win2k25           157m

Creating a VM with virtctl

Let’s create a VM project space with the information we just collected. The virtctl create command can be used to create a VM definition:

[lab-user@bastion ~]$ virtctl create vm \
    --name rhel9-enablement \
    --instancetype u1.small \
    --infer-preference  \
    --volume-import type:ds,src:openshift-virtualization-os-images/rhel9,size:50Gi

You will see the following output as result of the command above. Note that no VM has been created, virtctl has only generated a YAML template:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  creationTimestamp: null
  name: rhel9-enablement
spec:
  dataVolumeTemplates:
  - metadata:
      creationTimestamp: null
      name: imported-volume-rn97x
    spec:
      sourceRef:
        kind: DataSource
        name: rhel9
        namespace: openshift-virtualization-os-images
      storage:
        resources:
          requests:
            storage: 50Gi
... continued

So, to actually create the VM, pipe the definition to oc create:

[lab-user@bastion ~]$ virtctl create vm \
    --name rhel9-enablement \
    --instancetype u1.small \
    --infer-preference  \
    --volume-import type:ds,src:openshift-virtualization-os-images/rhel9,size:50Gi \
    | oc create -f -
virtualmachine.kubevirt.io/rhel9-enablement created

Live Migrate a Virtual Machine

In this section, we will migrate the VM from one OpenShift node to another without shutting down the VM. Live migration requires ReadWriteMany (RWX) storage so that the VM disks can be mounted on both the source and destination nodes at the same time. OpenShift Virtualization, unlike other virtualization solutions, does not use monolithic datastores mounted to each cluster member that hold many VM disks for many different VMs. Instead, each VM disk is stored in its own volume that is only mounted when and where it’s needed.

Navigate to the fedora01 VM in your OpenShift console

Navigate to the Overview tab to see on which worker node the VM is running:

You may have to make your browser window wider to see the node’s full name. Alternatively, you can click on the abbreviated name, which will take you to the details page for that node, where the full name is displayed; use your browser’s back arrow to return to the virtual machine overview.)

Using the Actions menu, select Migration and then select Compute.
After a few seconds, the VM will change the status to Migrating. A few seconds later, it will return to the Running status, but on a new node. The VM has been successfully live migrated!

Controlling Virtual Machine State

As a user with permission to access Virtualization, you can stop, start, restart, pause, and unpause virtual machines from the web console.

Click the Overview tab to return to the summary screen.
In the top right corner you will notice shortcut buttons for running state: stop, restart, and pause. As well as a dropdown menu title Actions.
1. Stop: Starts a graceful shutdown of the Virtual Machine.
2. Restart: This will send a signal to the operating system to reboot the Virtual Machine. Guest integrations are needed for this to work properly.
3. Pause: The process is frozen without further access to CPU resources and I/O, but the memory used by the VM at the hypervisor level will stay allocated.
You can also access these options and more by clicking on the Actions menu and seeing the options available in the drop down list.
Press the Stop button and wait until the Virtual Machine is in state Stopped.
Clicking on Actions, the option Start appears, and the options Restart and Pause are greyed out.
Click Start, and wait for the Running status.
Using the Actions menu, or the shortcut button, press the Pause option. The Virtual Machine state will change to Paused.
Unpause the Virtual Machine using the Actions menu and the option Unpause, or by using the shortcut button.

Virtualization Overview dashboard

The overview dashboard provides a cluster-level view of virtual machines and resources used, along with status information for the health of OpenShift Virtualization and virtual machines. It is a useful starting point for administrators who want a quick and high-level view of what’s happening with OpenShift Virtualization.

From the left navigation menu, browse to Virtualization → Overview and select Project: → All projects

This overview page provides the OpenShift Virtualization administrator a global overview of the virtual machines in the cluster. A normal user would only see the VMs in his/her own project.

Don’t forget to check out the Getting started resources panel and click the "View all quick starts" link there to access more information about OpenShift virtualization, including Quick Starts which provide many guided walkthroughs including how to create a VM and upload a custom boot source for your virtual machines.

Review the top consumers

Use the tabs across the top to view more about the virtualization resources in the cluster. For instance, the "Top consumers" tab shows the VMs which are "top consumers" of various resources, including CPU, memory, and storage. Note that in a newly created cluster, there are no consumers, so there is little to see in the beginning. You might also want to dig deeper into metrics by clicking on "View virtualization dashboard" link. That brings you to the KubeVirt Metrics Dashboard with more data and graphs.

If you don’t see any resources here, no VMs have been started in your lab. Revisit this page after this segment to see the overview details.