Virtual machine management
The beginning section of this lab will introduce you to the basics of creating and managing VMs in Red Hat OpenShift Virtualization. You will see how the web console guides you through the whole process of creating a virtual machine from a pre-defined template. We will then review the properties of that VM, do some basic customizations, and perform actions like live migration, that are often expected of virtual machine administrators.
What will you learn?
A review of virtual machine management fundamentals, including creating a virtual machine, and modifying its allotted resources.
What do you need before starting?
Your OpenShift cluster console is available {openshift_web_console}[here^].
Administrator login is available with:
User: {openshift_admin_user}
Password: {openshift_admin_password}
Create a new project
Like other objects in Red Hat OpenShift, Projects (which are an abstraction for Kubnernetes namespaces), are the boundaries for permissions and other aspects of using and managing the resources. Creating a Project is an important first step for any deployment.
Browse to Virtualization → VirtualMachines using the left navigation menu (Figure 1):
Figure 1 Note: the Virtualization tab is available only when Red Hat OpenShift Virtualization is installed and properly configured. In this lab environment the installation and configuration has already been performed for us.
Examine the VirtualMachines dashboard that appears (Figure 2). There are currently several VMs listed, but they are not turned on:
Figure 2 - 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.
Click Project: All Projects at the top left of the window (Figure 3) and then click Create Project.
Figure 3 In the Name field, type vmexamples to name the project, then click Create (Figure 4).
Figure 4
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 (Figure 5).
Note: 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.
Figure 5 The wizard will appear showing the available pre-defined VM templates (Figure 6).
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 automatically downloaded and stored template source disks. 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.
Figure 6 Select the Fedora VM tile, and a dialog opens (Figure 7).
Figure 7 Change the name to fedora01 and press Quick create VirtualMachine (Figure 8):
Figure 8 After a few seconds, expect to see the VM is Running (Figure 9). 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 can vary based on the storage provider being used to create the boot disk.
Figure 9 After the VM is created, examine the Events tab to see some details of the process (Figure 10). If there are any issues with the creation of the VM, they will show up on this tab as well.
Figure 10 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 (Figure 11). 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.
Figure 11
Administering virtual machines
Administering and using virtual machines is more than simply creating and customizing their configuration. As the platform administrator, we also need to be able to control the VM states and trigger live migrations so that we can balance resources, perform maintenance tasks, and reconfigure nodes.
Click the Configuration tab, this is the entry point to obtain information about the resources of the Virtual Machine (Figure 12).
Figure 12 It includes seven subtabs (Figure 13):
Figure 13 Details: This tab presents all of the physical features of the VM in a single panel. From here you can make edits to various descriptors and basic hardware configurations including modifying the cpu or memory, changing the hostname, attaching passthrough devices, and modifying the boot order.
Storage: This tab lists the disks attached to the system and allows you to add new disks to the system. If the guest is configured with the agent, it lists the filesystems and the utilization. Here it is possible to attach ConfigMaps, Secrets, and Service Accounts as extra disks. This is useful when passing configuration data to the application(s) running in the virtual machine.
Network: This Tab shows the current network interfaces configured for the VM and allows for you to add new ones.
Scheduling: This tab includes advanced configuration options indicating where the VM should run and the strategy to follow for eviction. This tab is used to configure (anti)affinity rules, configure node selectors and tolerations, and other behaviors that affect which cluster nodes the VM can be scheduled to.
SSH: This tab allows you to configure remote access to the machine by creating an SSH service on a configured load-balancer, or by injecting public SSH keys if the feature is enabled.
Initial run: This tab allows us to configure cloud-init for Linux or sys-prep for Microsoft Windows, including setting the commands to be executed on the first boot, such as the injection of SSH keys, installation of applications, network configuration, and more.
Metadata: This tab shows current Labels and Annotations applied to the virtual machine. Modifying these values can help us tag our machines for specific purposes, or help us enable automated workflows by uniquely identifying machines.
List the disks associated with the VM by clicking on the Storage tab (Figure 14):
Figure 14 In this environment, the default StorageClass, which defines the source and type of storage used for the disk, is called ocs-storagecluster-ceph-rbd-virtualization. This storage is the default type provided by OpenShift Data Foundation (ODF) for running virtual machines. Each storage provider has different storage classes that define the characteristics of the storage backing the VM disk.
Examine the network interfaces attached to the VM by clicking on the Network interfaces subtab (Figure 15):
Figure 15 When a VM is created, an interface on the PodNetworking network of type masquerade is created by default. This connects the VM to the SDN and provides access from the VM to outside the OpenShift cluster. Other VMs, and Pods, in the cluster can access the virtual machine using this interface. Furthermore, a VM connected to the SDN can be accessed externally using a Route, or Service with type load balancer, or even have a Network Attachment Definition configured to allow direct access to external networks.
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 (Figure 16).
Figure 16 Stop: Starts a graceful shutdown of the Virtual Machine.
Restart: This will send a signal to the operating system to reboot the Virtual Machine. Guest integrations are needed for this to work properly.
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 (Figure 17).
Figure 17 Press the Stop button and wait until the Virtual Machine is in state Stopped (Figure 18).
Figure 18 Clicking on Actions, the option Start appears, and the options Restart and Pause are greyed out (Figure 19).
Figure 19 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 (Figure 20).
Figure 20 Unpause the Virtual Machine using the Actions menu and the option Unpause, or by using the shortcut button.
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 Overview tab to see where the worker node is running (Figure 21):
Figure 21 Using the Actions menu, select the option to Migrate (Figure 22).
Figure 22 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 (Figure 23). The VM has been successfully live migrated!
Figure 23
Summary
In this resource, we reviewed virtual machine state management tasks, and executed a live migration of a VM. Both of these are common and necessary tasks as platform administrators and a great way to familiarize yourself with some basic features available when working with VMs in OpenShift Virtualization.
