Virtual Machine Management

Introduction

The beginning section of 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 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.

Goals

  • Create a new virtual machine

  • Review and modify resources for virtual machines

  • Understand how VM power states are managed using the OpenShift console

  • Live migrate a VM between two hosts

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

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

Your login is available with:

  • User: {user}

  • Password: {password}

Switch to Administrator View

After logging in you will show up in the Developer view,

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 manaing the resources. Creating a Project is an important first step for any deployment.

  1. The first time you log into the console you will see the Developer perspective. Click Skip tour to dismiss the prompt. Then click on Developer and switch to Administrator.

    00 Admin Perpspective

  2. Browse to Virtualization → VirtualMachines using the left navigation menu:

    01 Left Menu

    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.

  3. From the Projects dropdown switch to the project vmimported-{user}.

    The images in this lab guide may show different user numbers than your own. Do not worry, just create projects, etc with your user number.

  4. Examine the VirtualMachines dashboard that appears. There are currently several VMs listed, but they are not turned on:

    02 VM List

  5. 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: vmimported-{user} at the lop left of the window and then click Create Project.

      02 All Projects

    2. In the Name field, type vmexamples-{user} to name the project, then click Create.

      03 Create Project

Create a Linux Virtual Machine

  1. 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.
    04 Create VM Button

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

    05 Create VM Templates

  3. Select the Fedora VM tile, and a dialog opens.

    06 Create VM Quick

  4. Change the name to fedora01 and press Quick create VirtualMachine:

    07 Create VM Quick Name

  5. After a few 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 can vary based on the storage provider being used to create the boot disk.

    08 Fedora Running

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

    09 Fedora Events

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

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

    10 Fedora Details

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.

  1. Click the Configuration tab, this is the entry point to obtain information about the resources of the Virtual Machine.

    11 Configuration Tab Nav

    It includes seven subtabs:

    12 Configuration Tab

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

  2. List the disks associated with the VM by clicking on the Storage tab:

    13 Storage Tab

    In this environment, the default StorageClass, which defines the source and type of storage used for the disk, is called ocs-external-storagecluster-ceph-rbd. 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.

  3. Examine the network interfaces attached to the VM by clicking on the Network subtab:

    14 Network Tab

    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.

  1. Click the Overview tab to return to the summary screen.

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

    15 VM State 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.

  3. You can also access these options and more by clicking on the Actions menu and seeing the options available in the drop down list.

    16 VM Actions Menu

  4. Press the Stop button and wait until the Virtual Machine is in state Stopped.

    17 VM Stopped

  5. Clicking on Actions, the option Start appears, and the options Restart and Pause are greyed out.

    18 VM Actions List Stopped

  6. Click Start, and wait for the Running status.

  7. Using the Actions menu, or the shortcut button, press the Pause option. The Virtual Machine state will change to Paused.

    19 VM Actions Paused

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

  1. Navigate to the Overview tab to see where the worker node is running:

    20 VM Info Node

    Only cluster administrators can see the Node - the screenshot is an example of what an admin would see. But you can still migrate the VM - you just won’t see the node change.

  2. Using the Actions menu, select the option to Migrate.

    21 VM Dialog Migrate

  3. After a few seconds, the VM will change the status to Migrating, and you can follow it’s progress. When it is complete it will return to the Running status, but on a new node.

    23 PodLink

  4. If you would like to see the guest switch nodes in real time, you can do so on the Pod Details screen by clicking on the pod name on the right. You can see the node the VM lives on, and it’s new node when it changes. The cutover is fairly quick, so watch closely. Blink and you may miss it!

    24 Pod

Summary

In this lab, 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.