This is part 4 of a tutorial that demonstrates how to add OpenShift Virtualization 2.5 to an existing OpenShift 4.6 cluster and start a Fedora Linux VM inside that cluster.

Please refer to “Your First VM with OpenShift Virtualization Using the Web Console” for the introduction of this tutorial and for links to all of its parts and refer to “Preparing to Create a VM Using the OpenShift Web Console” for part 3 of this tutorial.

Because this tutorial performs all actions using the OpenShift Web Console, you could follow it from any machine you use as a personal workstation, such as a Windows laptop. You do not require a shell prompt to type oc or kubectl commands.

Creating a Virtual Machine with OpenShift Virtualization involves creating a Virtual Machine (VM) resource. That resource does not represent a running virtual machine. A real, running virtual machine is represented by a Virtual Machine Instance (VMI) resource, which is the subject of the next part of this series.

Creating a VM With OpenShift Virtualization

You can create a VM from the OpenShift CLI, but again, it is very easy to do from the Web Console. This tutorial basically “fills in the blanks” of the product documentation at:

https://docs.openshift.com/container-platform/4.6/virt/virtual_machines/virt-create-vms.html

You do not require cluster administrator privileges to create a VM with OpenShift Virtualization. Any OpenShift user who has the ability to run containers, that is, users with admin or edit roles in a project (or the ability to create new projects), are able to create VMs.

If you prefer to continue this tutorial as a cluster administrator you can; it is just not required.

Please rely on the written instructions more than on the screen captures. They are here mostly to provide you visual aid and assurance that you are on the correct page for each step.

1. Create a new project and find the New Virtual Machine wizard.

Log in to your cluster’s web console as a regular user and create a project for your VMs. I created the myvms project. Make sure that project is the default for the web console before proceeding.

Switch to the Administrator perspective of the web console to follow these instructions. You can create VMs and perform most of the developer’s tasks from this series from the Developer perspective, but I confess I was too lazy to take more screen captures and describe alternative ways of performing the same tasks from each perspective.

Click Workloads → Virtualization and click the Virtual Machines tab. Click Create Virtual Machine and select New with Wizard.

3. Fill in the fields from the General page of New Virtual Machine wizard.

Fill in the following fields in the Create Virtual Machine → General page, leaving all other fields with their default values, and click Next.

• Name: testvm
• Operating System: Fedora 31 or higher
• Source: URL
• URL: The complete URL of a qcow2 image that is accessible from your cluster nodes, for example:
  http://fedora.c3sl.ufpr.br/linux/releases/32/Cloud/x86_64/images/Fedora-Cloud-Base-32-1.6.x86_64.qcow2
• Flavor: custom
• Memory: 4GiB
• CPU: 1
• Workload profile: server
• Hostname: testvm
• Authorized ssh keys: paste the contents of the public key of your SSH key-pair, which is by default your ~/.ssh/id_rsa.pub file.

4. Review the Networking and Storage pages of New Virtual Machine wizard.

Make no changes in the Create Virtual Machine → Networking page and click Next. Your VM has a single NIC, connected to the OpenShift pod network, and using IP masquerade to access the external world.

Make no changes in the Storage page and click Next. Your VM will have a single disk of 15GiB, besides the cloud init disk.

5. Add your SSH key in the Advanced page of New Virtual Machine wizard.

In the Create Virtual Machine → Advanced > Cloud Init page, click Form and click Confirm in the Data loss confirmation dialog. Fill in the following fields, leaving all other fields with their default values, and click Next.

You do not need to click Add SSH Key. You only need to click that if you want to add multiple SSH keys.

6. Create your VM at the end of the New Virtual Machine wizard.

In the Create Virtual Machine → Review page, you have the opportunity to review your settings, and return to previous pages if you need to do so. Do not make any change in the Review page.

Specially, resist the temptation of starting your VM right away. You could be frustrated that it takes a long time to start, depending on your storage network and size of your qcow2 image, and it is too easy to make mistakes such as typos in the source URL. You will see how to verify that your VM’s boot disk is good later in this tutorial.

Scroll to the bottom and click Create Virtual Machine. The web console displays “Successfully created Virtual Machine.” Click go to list.

7. Verify that OpenShift started importing the root disk of your VM.

The web console is back to Workloads → Virtualization, in the Virtual Machines tab. You should see your testvm virtual machine with a status of “importing,” which means that OpenShift is downloading the source image and creating a root disk for your VM.

Remember that the VM resource that you created is not a running virtual machine. The fact that you succeeded creating a VM does not mean it will start and run successfully.

Instead of just waiting for your new VM to be ready to start, you can monitor the progress of importing and creating your VM’s boot disk. One way of doing that is clicking your VM “importing” status.

The next section digs deeper into the process of importing a VM image and creating its root disk.

Verify Your Data Volume

Before OpenShift Virtualization can start your VM, it has to download your qcow2 VM image, store it in a persistent volume, and resize the LVs and file systems inside your disk image to match the size of your persistent volume.

It is a good idea to verify that the process of downloading and converting your qcow2 image is completed successfully before attempting to start your VM.

1. Find the Data Volume of your VM.

Click Home → Search and select DataVolume in the Resources combo box. You should see a single DV resource named testvm-rootdisk-xxxxx in the myvms project.

That resource shows the progress of importing your qcow2 image. Click testvm-rootdisk-xxxxx to enter its DataVolume Details page. It shows the label “ImportInProgress.”

Scroll down to see its conditions. They show that the DataVolume got a PVC and it is running a pod to perform the transfer of the qcow2 image to the volume.

2. Find the importer pod of your DV.

Click Workloads → Pods to see the pod that performs work for the Data Volume. If anything goes wrong during importing the qcow2 image to a volume, its logs will give a hint of what went wrong.

At the end of the process, the importer pod is gone, and there should be no other pods in the myvms project.

3. Verify that importing the DV completed successfully.

The conditions of the Data Volume will show that the import is complete.

And your data volume entered its “Succeeded” phase before moving on.

If you asked for a disk that is too big, your cluster nodes cannot download your qcow2 image, or if you have network and capacity issues, the conversion process may fail and you will have to start it over.

4. Verify that there is a PVC for the root disk of your VM.

The Data Volume just controls the process of downloading the image and storing it in a persistent volume. The real “disk” from which your VM will boot comes from a Persistent Volume Claim (PVC).

Click Storage → Persistent Volume Claims to list all PVCs in the myvms project.

Of course, if your cluster has any issue provisioning storage for that PVC, everything fails, and you will not be able to start your VM.

Starting Your VM

Assuming everything went well so far, click Workloads → Virtualization, and, in the action menu for testvm, click Start Virtual Machine.

Your Virtual Machine status should change to “Running,” and it should also display the name of the computer node running its Virtual Machine Instance and the IP address allocated to it.

Make a note of the IP address of your VM. It is the address you use to access it from any other application (be it a container or a VM) inside your OpenShift cluster.

Verify Your VM Is Up and Running

To verify if your VM finished booting and is available for interactive login and remote clients, click Open Console in the action menu for testvm. A new browser window opens with a VNC connection to your VM’s console. This is a text-only VM, so you see a text-based Linux login prompt, but if it were a graphical VM, you would see its graphical login page.

The same console is available from your VM details page, in the Terminal tab.

The Fedora 32 image I chose provides no user account enabled for interactive login. But at least you did not see a kernel panic message nor something else scary, so you know it is running.

Later during this tutorial, you will see how to access that VM using SSH and the key that you created in part 3 and that you provided to your new VM as part of its cloud-init data.

Next Steps

Now that you have a running Virtual Machine Instance, you can proceed to part 5 of this tutorial: “Peeking inside an OpenShift Virtualization VM using the OpenShift Web Console.”