KVM stands for kernel-based virtual machine, also known as Linux KVM. It is an open-source virtualization that is built into Linux, using the extensions provided by both Intel and AMD machine CPUs. These extensions permit the isolation of virtual machine resources. The technology was announced in 2006 and built into the kernel about a year later. At its core, KVM is a hypervisor. A virtual machine in a KVM environment runs as a Linux process that the Linux scheduler schedules. KVM can virtualize all the common hardware components, thus achieving a complete virtualization solution, particularly when paired with an enterprise storage solution like Dell PowerStore.

KVM offers many of the same features of other hypervisors such as:

• Virtualization of hardware devices like CPU and memory for use in virtual machines.
• Support for virtual GPUs, allowing sharing of these resources across VMs.
• PCI passthrough to use a KVM node’s hardware directly.
• Online migration of virtual machines between physical hosts where KVM is installed.
• Performance and scalability are commensurate with the resources of the physical hosts on which the virtual machines run.

Unlike other hypervisors, KVM is an open-source project which permits a business to customize it to their needs.

Although KVM is the same across Linux distributions, how you manage it varies greatly. Both UI and CLI interfaces are available, some of which require licensing, while others are open-source and free. Many of the management options focus on hosting companies and thus offer extensive cloud capabilities and support for most hypervisors.

This guide focuses on implementing KVM across an Oracle Linux 8.10 three-node cluster that uses Oracle Linux Virtualization Manager, or OLVM. OLVM is built upon a popular open-source management solution known as oVirt. oVirt is a community project which delivers a management framework consisting of an “oVirt node” that runs the libvirt service and offers web-based management. The heart of the implementation is the oVirt Engine which provides the foundation of the solution. Note that while it is possible to use oVirt directly on other non-Oracle Linux distributions, the open-source version of oVirt is not well maintained and does not provide the level of stability and support that OLVM can. Furthermore, both OLVM and Oracle Linux are available free of charge, including all updates.

This guide provides configuration details for implementing Oracle Linux KVM on Dell servers using PowerStore block and file storage. It demonstrates how to use both iSCSI and NFS file systems for shared storage KVM clusters. As noted, since OLVM is the management interface, Oracle Linux is the required node operating system. If using a different management interface, you can use any supported Linux distribution. When discussing the underlying technologies such as the oVirt Engine in this paper, care is used to emphasize that Oracle Linux is not mandatory unless using OLVM.

This guide is intended for use by storage administrators, system administrators, and virtualization administrators.

Readers of this guide are expected to be familiar with the following topics:

• Dell PowerStore system operation
• Dell software: PowerStore Manager, Integrated Dell Remote Access Controller
• General storage concepts
• Linux system administration
• Virtualization technology such as hypervisors

The following table provides definitions for some of the terms that are used in this guide.

The following table provides the revision history:

The PowerStore platform is a bare-metal unified storage array that can service block, file, and VMware Virtual Volume (vVol) resources along with numerous data services and efficiencies. PowerStore is perfect for traditional and modern workloads, including relational databases, electronic medical recordapplications, and content repositories among many others. Dell PowerStore has multiple purpose-built platforms: the 2U, two-node single-socket Intel® Xeon® platform is used for the PowerStore 500 model; and the 2U, two-node dual-socket upgraded Intel® Xeon® platform is used for the PowerStore 1200, 3200, 5200, and 9200 models. For more information about PowerStore platforms, please refer to Dell PowerStore: Introduction to the Platform.

Organizations that use new applications and solutions require dependable storage and often face the challenge of doing more with less. PowerStore addresses this challenge by packaging a powerful storage system into a cost-efficient and space-efficient profile. PowerStore features and benefits include:

• Active/active architecture
• Multiple protocol support: iSCSI, Fibre Channel, NVMeoF, and SMB/NFS
• Unified offering
• Simplified, modern user interface
• VMware integration
• Inline data reduction
• Local and remote data protection

PowerStore achieves new levels of operational simplicity and agility. It uses a container- based microservices architecture, advanced storage technologies, and integrated machine learning to unlock the power of your data. It offers predictive analytics to easily monitor, analyze, and troubleshoot the environment. PowerStore is highly adaptable, providing the flexibility to host specialized workloads, and fits seamlessly into existing infrastructures to meet industry requirements. No matter where your business strategy takes you, PowerStore’s full-featured, adaptable design can help you build your unique breakthrough.

Kernel-based virtual machine, or KVM is an open-source virtualization infrastructure for the Linux kernel that allows it to act as a hypervisor. A hypervisor, or virtual machine monitor (VMM), is a hardware, software, or firmware layer that runs virtual machines on a physical host. It virtualizes the hardware, enabling one system to become many. There are two types of hypervisors: Type 1 runs directly on the physical host; and Type 2 runs on top of the operating system of the physical host. KVM is a Type 1 hypervisor as it manages the hardware resources directly rather than Type 2, which relies on the operating system device drivers.

Because KVM is part of the Linux kernel, it can use the hardware virtualization features that are available in Intel VT-x or AMD-V CPUs to create and manage virtual machines. A basic representation of the KVM architecture is shown in the following figure.

Several common KVM components include the following:

• Quick Emulator (QEMU) – An open-source emulator for hardware and virtualization. It is used with KVM to run and manage virtual machines.
• libvirt – A toolkit/API for managing virtualization technologies like KVM and other hypervisors.
• virsh – A CLI that can manage virtual machines.
• Guest OS – operating system that runs on a virtual machine in a KVM environment, for example Linux or Windows.
• Emulated devices – versions of physical hardware.
• Virtio devices – devices specifically for KVM.

KVM virtualization is essentially the same across Linux distributions, for example, running KVM on Red Hat looks and feels the same as running it on Ubuntu. However, how a business chooses to manage it can vary greatly. Unlike other commercial hypervisors that have their own management solution as part of the virtualization environment, such as VMware vCenter, KVM is open-source and has many management options available – both licensed and free. One of the more straightforward open-source implementations is oVirt.

oVirt is a management framework consisting of the oVirt node. This node runs the libvirt service and offers web-based management through the foundation of oVirt called the oVirt Engine. The management interface of Oracle Linux Virtualization Manager is built upon the oVirt Engine and offers virtualization administrators the ability to create and manage VMs, allocate memory and storage resources, and set up the required networking. Beyond the basics, administrators can migrate VMs through the interface, manage high availability, and even set up storage quotas or performance limitations (throttling). There are three options for UI views: Administration Portal, VM Portal, and Monitoring Portal.

The following figure shows an example of the Oracle Linux Virtualization Manager (OLVM) UI for the Administration Portal, which provides a high-level view of all components in the KVM environment.

The VM Portal enables the user to drill down into each virtual machine in the environment and make changes at that level. The following figure shows the details of a particular virtual machine.

The Monitoring Portal has Grafana at its foundation. Grafana is an open-source analytics and monitoring platform that integrates with oVirt and provides dashboards, alerting, and monitoring capabilities. It is a highly customizable platform that enables the user to modify and share dashboards. One advantage of the monitoring portal over other virtualization solutions is that Grafana comes preconfigured with a selection of dashboard categories and individual dashboards specifically for oVirt, as shown in the following figure.

The individual dashboards offer great detail into the clusters, hosts, and individual VMs running in the environment. The following figure shows the host-level dashboard.

The Virtual Desktop Server Manager (VDSM) is an essential component of the oVirt Engine. VDSM is the component of the oVirt platform responsible for managing and monitoring the virtualization hosts. It handles the life-cycle management of the VMs including creation, resource allocation, monitoring, migration, and deletion. VDSM runs as a host agent and communicates with the oVirt Engine from each virtualization host in the cluster to ensure proper management of the environment.

The oVirt Engine can be implemented on one or two physical hosts, or it can be deployed as a virtual machine either in a separate virtualization environment or in the KVM environment itself. If the oVirt Engine is separate from the KVM environment, it is called a stand-alone implementation. In such a configuration, the virtual machine can be hosted in a non-KVM virtualization environment. If the oVirt Engine is run in the KVM environment, it is referred to as self-hosted.

Both installation types require Enterprise Linux 8 of any distribution. When it is self-hosted, the Engine Appliance is used to automate the Guest OS installation. A virtual machine implementation, either stand-alone or self-hosted, uses the virtualization environment’s ability to support high availability. The stand-alone implementation, however, requires an external HA management such as Oracle Linux High Availability Stack.

The following figure shows an example of a stand-alone implementation in which two physical hosts access the same shared storage.1

The oVirt Engine only runs on a single host, with the second providing high availability if there is external HA management, hence the requirement for the hosts to see the same storage. For details on sizing requirements for the Engine host, see the following documentation.

The following figure shows the self-hosted example in which the oVirt Engine is deployed directly in the KVM environment as is the case in this paper.2

The oVirt community generally recommends a stand-alone configuration because it separates management from the KVM environment. This recommendation is similar to VMware’s recommendation of not running vCenter on the same ESXi hosts that it is managing. For the environment described in this guide, however, we had to use a self-hosted oVirt Engine because of a lack of physical hosts.

The following figure shows that a self-hosted engine is displayed like any other virtual machine (HostedEngine) in the UI, with the addition of a golden crown.

oVirt supports two types of hosts: oVirt node and Enterprise Linux.

An oVirt node is a pared-down Enterprise Linux CentOS that contains only the packages and enabled repositories that are required for being a virtualization host. oVirt supplies this operating system in a downloadable ISO file, and it is the quickest and easiest way to implement KVM with oVirt as it has been designed specifically for this purpose. There are no other distributions except CentOS.

oVirt also supports using a standard Enterprise Linux OS implementation of any distribution with the properly enabled repositories.

The implementation instructions for each host type vary, with the Enterprise Linux host requiring extra steps. Dell Technologies recommends using version 8.x for all production implementations.

Because KVM is built into the kernel, most Linux distributions are candidates for a virtualization environment; however, the level of commitment to virtualization varies across the distributions. Oracle Virtualization was selected for this environment as it continues to develop and issue new releases. Before selecting a Linux distribution, be sure it meets the needs of the business now and in the future.

The following sections provide the requirements for implementing oVirt and KVM with PowerStore.

Meet the following prerequisites before implementing KVM on PowerStore. These prerequisites are high level as some tasks related to them are described in this guide.

• Storage:
  • For file storage, a PowerStore system must be installed and configured as Unified. If only using block storage, Block-Optimized can be used.
  • For iSCSI, an interface module that supports Ethernet connectivity.
  • For FC, and interface module that supports fibre channel connectivity.
• Dell servers with sufficient networking, memory, CPU, and storage to satisfy the requirements of a KVM shared storage cluster. Sizing varies greatly depending on the number of virtual machines needed and their purpose.
  • If using FC, the servers require HBAs that are connected to the PowerStore (typically through a switch).
  • If using iSCSI, the servers need to communicate on the same network as the iSCSI interfaces on the PowerStore. In addition, the KVM hosts must be configured for iSCSI by installing the proper packages and configuring communication to the PowerStore.
  • If using file storage, the servers will need to communicate on the same network as the file interfaces on the array.
• Licenses for PowerStore and the Enterprise Linux distribution, if applicable. If one employs Oracle Linux with the public yum servers, as in this paper, no additional licensing is required. If using Oracle ULN, however, a subscription is required.

The following table lists the oVirt software versions and the versions for both the oVirt Engine and hosts. Oracle Linux is called out specifically since it is the distribution used in this paper.

Dell Technologies recommends a robust network topology in production setups. At the physical layer, you could use two Top of Rack (TOR) switches for both redundancy and load-balancing purposes. Then connect each Dell host to both switches.

The following table shows the different networks configured for this solution.

The PowerStore system is a PowerStore 3200T array with iSCSI and File connectivity in a Unified configuration. The following figure shows the appliance Capacity view in PowerStore Manager.

The KVM environment, as described in this guide, consists of three identical Dell R640 servers. The specifications are:

• 2 x Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz (18 core)
• 512 GB (16 * 32 GB, 2666 MT/s DRAM DDR-4)
• Intel(R) Gigabit 4P X710/I350 rNDC
• Intel(R) Ethernet 25G 2P E810-XXV Adapter
• 2 * 447.13 GB (SATA SSD)

The following sections describe the installation of Oracle Linux and the oVirt Engine in a self-hosted configuration, as well as the post install creation of storage domains. If using an oVirt node implementation, review the oVirt, Oracle, and KVM documentation for details.

The oVirt installation begins with selecting a node for the oVirt Engine.

There are three steps to the installation.

1. Identify a physical host for the first KVM node of the cluster with sufficient memory, CPU, and PowerStore storage connectivity (iSCSI, FC, or NFS) to support the oVirt Engine.
2. Install Oracle Linux 8.x as it is the chosen distribution for this paper.
3. Run the hosted-engine script to deploy the oVirt Engine.

The following sections describe the installation of Oracle Linux and oVirt Engine.

After the host comes up, run the pre-check script to ensure the host is ready for the oVirt Engine deployment.

<sudo> olvm-pre-check.py

All tests should pass before continuing as in the following figure.

If the pre-check succeeds, install the hosted engine deployment tool and engine appliance by running:

dnf install ovirt-hosted-engine-setup ovirt-engine-appliance

If the tool and appliance install successfully, you can deploy the self-hosted oVirt Engine.

The self-hosted oVirt Engine is a virtual machine created on the first node of a KVM cluster. There are two methods for deploying the oVirt Engine: CLI or UI.

To access the UI, navigate to https://<KVM host>:9090 and log in as root. Next, on the left-hand menu, select Virtualization > Hosted Manager page. Click Start to begin deployment in the following figure.

Alternatively, as in this environment, use the CLI to deploy the oVirt Engine by running the hosted-engine –deploycommand, which in turn runs Ansible scripts or playbooks to create the oVirt Engine. The script queries for the network, host names, IP addresses, and most importantly, storage. Initially, the virtual machine is deployed on the local mount (/) before being moved to the chosen shared storage. It is essential to use a disk large enough for deployment of the KVM node where the oVirt Engine will be built (as noted in the section Oracle Linux installation). By default, the script uses IPV6. If IPV4 is required, the --4 parameter must be passed. The following figure shows the execution of the script as run for this paper:

Note the reference above to shared storage – this step cannot be bypassed. The virtual machine is copied to a shared storage domain of the user’s choice that is created as part of the script. It cannot be a local storage domain. This limitation narrows the options to: GlusterFS, iSCSI, FC, or NFS. The storage must be presented to the node before running the deployment script for iSCSI and FC. To prepare for an iSCSI storage domain, see iSCSI. The user can specify GlusterFS and NFS when prompted, though you must create the NFS file system and export on PowerStore, prior to the engine deployment.

The script prompts the user for the management network (typically the public adapter of the host), the data center and cluster names, and the CPU, memory, and FQDN of the Engine. The Engine FQDN is not the running host, rather it is an available host/IP address for the virtual machine. The default values for CPU and memory are a percentage of the actual server amounts. They can be adjusted as shown in the following figure.

When the user enters the required information, the script deploys the appliance and creates the virtual machine on local storage. After this step is completed, the oVirt Engine is ready.

The final steps in the script move the virtual machine to shared storage. The user is prompted to select the type of storage. At the prompt, NFS is the default option. If you take the default, as here in the following figure, you will be prompted for the export path. For the steps to create an NFS file system and export on PowerStore see the section NFS.

When selecting either iSCSI or FC, the script initiates a storage scan and then presents a list of devices from which to choose. Below is an example when you select fc for the storage. The bolded 99 GiB LUNs in the list are presented through fibre channel from a Dell PowerMax (tagged as EMC SYMMETRIX). This is why the operating system must see the devices prior to running the deployment of the oVirt Engine. The disk should not contain any partitions.

INFO  ->  Getting Fibre Channel LUNs list
INFO  ->  TASK [ovirt.ovirt.hosted_engine_setup : Execute just a specific set of steps]
INFO  ->  ok: [localhost]
INFO  ->  TASK [ovirt.ovirt.hosted_engine_setup : Force facts gathering]
INFO  ->  ok: [localhost]
INFO  ->  TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
INFO  ->  included: ...
INFO  ->  TASK [ovirt.ovirt.hosted_engine_setup : Obtain SSO token using username/password credentials]
INFO  ->  ok: [localhost]
INFO  ->  TASK [ovirt.ovirt.hosted_engine_setup : Get Fibre Channel LUNs]
INFO  ->  ok: [localhost]

The following luns have been found on the requested target:
[1]  36000097000012000167253300303031       99.0GiB  EMC  SYMMETRIX
     status: free, paths: 1 active
[2]  36000097000012000167253300303135       99.0GiB  EMC  SYMMETRIX
     status: free, paths: 2 active
[3]  3600009700001200016725330030313135     99.0GiB  EMC  SYMMETRIX
     status: free, paths: 2 active
[4]  SSDSC2KB480G7R_PHY8805302408BN         447.0GiB ATA
     status: used, paths: 1 active
[5]  SSDSC2KB480G7R_PHY8805301408BN         447.0GiB ATA
     status: used, paths: 1 active
[6]  SSDSC2KB480G7R                         447.0GiB ATA
     status: used, paths: 1 active

Please select the destination LUN (1, 2, 3, 4, 5, 6) [1]: 2

After the script creates the shared storage domain, it prompts the user for a virtual machine disk size before moving it to shared storage. Unless there is a specific reason to increase the size, accept the default value which is 38 GB in this example. The following figure shows these steps (abbreviated screenshot).

The script in this example reports a successful deployment, which means that the oVirt Engine is up and running on shared storage. If there are errors at any point, the user can address them, and the script starts again. Sometimes, the state of the installation is unknown and requires a full reset. See Failed oVirt Engine script, which describes how to rollback a failed installation for such instances.

A user will likely see a reference to Cockpit if they SSH into a KVM node. Cockpit is part of the build for the oVirt node and can be enabled on each KVM node for a standard server installation. It is a UI that can manage a Linux system, including virtual machines. The user might find it useful to manage the Linux host themselves, however, because the oVirt Engine provides the UI OLVM for the KVM environment as a whole, Cockpit is unnecessary for virtualization components.

If new oVirt software becomes available, OLVM informs the user if any hosts in a cluster can be upgraded. If the user examines the hosts, each host indicates whether it can be upgraded by showing the Update available in the following figure.

In the hosts view, the Installation menu also enables the user to check for updates because OLVM only checks for updates periodically.

Storage plays an essential role in the KVM implementation. The storage dictates the type of cluster: shared or local. Shared storage is the more common option for a KVM cluster, enabling features such as HA and migration. For example, during the oVirt Engine installation that is described in this guide, an initial shared storage location on PowerStore is required. Dell Technologies recommends creating additional storage domains on PowerStore for objects such as virtual machines and ISOs. These objects can be on FC, iSCSI, or NFS on PowerStore.

When creating new shared storage domains in a KVM environment, the user is limited to these storage types, as shown in the following figure.

• NFS
• POSIX-compliant FS (global file system)
• GlusterFS
• iSCSI
• Fibre Channel

PowerStore supports all these protocols: NFS, iSCSI, and FC. KVM has specific requirements for each storage type that is used in a storage domain. Creating storage domains on NFS and iSCSI is covered next.

NFS is a distributed file system protocol that allows one to access files over a network. NFS is a common choice for storage domains because it is simple to implement and manage. When using NFS storage with KVM, it is important to pick a platform that meets the performance and scalability requirements of user workloads. PowerStore supports both NFS 3 and 4.1 and delivers superior performance when matched with a low-latency network.

For NFS, the permissions and the ownership of the share must be altered so that the oVirt Engine can use it. The available ownership and permissions on the PowerStore NFS export are limited and do not meet the requirements of KVM. Therefore, it is necessary to manipulate the share either on an existing KVM node, or on a separate host altogether. In the following example, a Linux host was configured for the sole purpose of meeting the prerequisites of NFS storage. This example sets up the storage for the self-hosted oVirt Engine. It is the same process, however, as is required for creating an NFS storage domain after the oVirt Engine deployment is completed.

Both Fibre Channel and iSCSI are block storage options for KVM. The manner of volume provisioning and mapping through PowerStore Manager is similar so while both are supported, only iSCSI is shown here as an example as it requires more host steps.

To present iSCSI storage to the KVM environment from a PowerStore there are two parts, the host and the array. We’ll start with the host changes and the network configuration. This section assumes the PowerStore is already configured for iSCSI storage with a VLAN-tagged network.

Multipath is not required but offers redundancy and performance benefits with iSCSI. After installing the multipath packages on the KVM hosts, configure a multipath.conf file. The example below is a basic one for PowerStore. See the Linux Connectivity Guide.

# PowerStore multipath settings - drop-in for VDSM-managed main config
defaults {
    # keep polling interval small for fast detection
    polling_interval        5
    no_path_retry           3
    fast_io_fail_tmo        5
    dev_loss_tmo            10
    user_friendly_names     no
    # do NOT change user_friendly_names here - VDSM enforces 'no' globally
}

blacklist {
    # example: ignore a single local device 'sda' if needed; change carefully
    # devnode "^sd[a]$"
}

devices {
    device {
        vendor                  .*
        product                 dellemc-powerstore
        path_grouping_policy    group_by_prio
        path_checker            tur
        prio                    alua
        failback                immediate
        no_path_retry           3
        fast_io_fail_tmo        5
        dev_loss_tmo            10
    }
}

Begin by creating an initiator group or host for each KVM host. The steps below use auto-discovery, but the initiator can be entered manually.

First, record the initiator name on the KVM host. The initiatorname.iscsi file is located in the /etc/iscsi directory, as shown in the following image. If you want to rename the initiator so that it includes the hostname, as below, do so before continuing. Then restart the iscsi daemon.

To avoid having to add the initiator manually in PowerStore Manager, run a discover and log in on the target IP addresses. There are two targets on the PowerStore in this environment in the following image but it is only necessary to discover one of the IPs. Both will be discovered. Then, issue a login. Performing this step informs the PowerStore about the host.

Regardless of type, each storage domain contains two disks named OVF_STORE by default. These disks contain all the information about the storage domain (such as virtual machines and metadata), which allows KVM to recover the storage domain without needing the oVirt Engine (previous functionality). This information, however, is also shared with the oVirt Engine. The disks are not created at instantiation, rather oVirt generates them through a scheduled process.

The example in the following figure shows that the General-NFS storage domain was created at 4:10:15 PM but the OVF_STORE disks were not initiated until 4:18:02 PM, eight minutes later. After storage domain creation, OVF_STORE disk creation varies depending on when the oVirt job runs (auto), which might be up to an hour after initial creation of the domain.

These disks remain for the life of the storage domain, neither increasing nor decreasing in number, no matter how many virtual disks or ISOs are created in the storage domain.

Protecting a virtualization infrastructure like KVM is an essential task for any customer. While there are numerous third-party software solutions for backing up virtual machines, this chapter takes a more holistic approach, covering the backup of the oVirt Engine and storage domains using PowerStore replication technology.

A benefit of using array-based storage for KVM is the ability to use the features of the array, such as local and remote replication. While KVM does offer the ability to take virtual machine-based snapshots, it cannot take a snapshot of the entire storage domain. Such copies can serve multiple purposes such as cloning, restores, and backups. Because storage domains are used to run production applications, it is essential to have a backup strategy in case there is a failure.

PowerStore offers protection through Protection Policies. A Protection policy is comprised of one or more rules that define snapshots (local and remote) and replication. A replication rule is either synchronous or asynchronous and requires a secondary PowerStore array. A snapshot rule defines what time and day to take snapshots, how long to retain them, whether they are secure, and the access type. The PowerStore supports remote replication and snapshots for both block and file storage. For example, in this paper, the NFS storage domain is associated with a daily snapshot policy while the iSCSI storage domain has a synchronous replication policy. While remote replication is a continuous process, individual snapshots can be taken outside of a protection policy at any time.

For example, the NFS daily snapshot rule that is associated with the storage domain in this paper is defined as so:

The following sections will discuss block and file snapshots of storage domains. Details on setting up remote replication are beyond the scope of this guide but can be found at support.dell.com.

If you do choose to use a Snapshot Access Type, you can access the files directly on any of the KVM nodes. For example, if in Step 3 – File system snapshot you select the Snapshot Access Type, you can log in to one of the KVM nodes and navigate to the .snapshot directly. In the following figure note that the .snapshot directory is not included even when requesting hidden files. But you can change into the directory regardless and access the files.

It is also possible to mount the file system on another box and access it that way.

You can create virtual machines through the UI or CLI. The virtual disks reside on the storage domains created in the data center. The following example uses the OLVM interface to create a virtual machine with a Rocky operating system. While there are many advanced options, only the basics are presented to convey the process.

Complete the following prerequisites before creating the first virtual machine in the environment.

Before creating a virtual machine, install the Virtual Machine Viewer software on the host where the KVM environment is accessed. This software enables the user to connect to the virtual machine console and install the operating system. The software is available at the following URL: virt-manager.org/download.html.

After the installation completes, reboot the virtual machine. If your operating system does not automatically install a guest agent (as Rocky does), OLVM places an exclamation point next to the virtual machine indicating that the latest guest agent must be installed, as shown in the following figure. The guest agent is required to enable functionality such as displaying the IP/FQDN, gracefully powering off the VM, and providing resource information.

The Virtual Machine Management Guide provides instructions for installing the agent depending on the operating system. Using Enterprise Linux 8 as an example, run the following commands:

yum install qemu-guest-agent
systemctl start qemu-guest-agent
systemctl enable qemu-guest-agent

KVM is an open-source hypervisor that offers many of the same enterprise-level features of commercial alternatives, while providing excellent performance and scalability at minimal cost. For many businesses running on PowerStore with Linux, it can fulfill their virtualization requirements, offering a flexible platform that can be customized to meet their needs.

When using a PowerStore array with KVM, a business can use both block and file storage for virtualization. Local and remote replication can provide the necessary protection of the environment. As a result, PowerStore enables the KVM environment to become highly resilient, scalable, and able to handle the most demanding workloads.

Dell Technologies and the authors of this document welcome your feedback on the solution and the solution documentation. Contact the Dell Technologies Solutions team by email.

Author

Drew Tonnesen, Dell Technologies Application Engineering

The following Dell Technologies documentation provides additional and relevant information. Access to these documents depends on user login credentials. If the user does not have access to a document, contact your Dell Technologies representative.

• Dell PowerStore documentation

The following oVirt, Oracle, and KVM documentation provide additional and relevant information:

• Oracle Linux Virtualization Manager
• Rocky Linux documentation
• Installing oVirt as a self-hosted engine using the command line
• oVirt Administration Guide
• oVirt REST API
• Virtual Machine Manager

The following sections describe some common issues as well as configuration options that the user might come upon during the KVM implementation. They are presented in no particular order.

If an oVirt Engine implementation fails, the user can reverse the installation by using the ovirt-hosted-engine-cleanup utility. The utility attempts to undo all tasks undertaken by the deployment script, though it warns that it might not be able to do so. In addition, because of the reliance on a bridged network, the management network might go down. Therefore, it is essential to use the tmux interface, which allows a reacquisition of the session if disconnected.

When KVM creates a storage domain, an ID is assigned. If that ID is not removed before reuse, KVM fails to create the storage domain. For block volumes, wiping the signature by using the fdisk or dd command is straightforward, though it also prevents accessing any of the old data (importing a storage domain into a different KVM cluster retains data). For NFS, however the user might want to keep the existing file system instead of destroying and re-creating it. If you want to retain the storage domain completely, you must import it into a new cluster.

In the example in the following figure, the ID of the storage domain is shown boxed in the UI.

A folder on the file system represents this ID, as shown in the following figure.

If an attempt is made to mount an NFS export that already has an “ID folder,” it fails and generates an error, as shown in the following figure. Note that the existence of the folder is what causes the error, not that the ID happens to match an existing storage domain like block.

If the user receives this error message but knows that they want to reuse the file system, they can remove the folder and contents. The easiest way is to mount the NFS export on another Windows or Linux host and recursively deleting the “ID folder.” When the folder is removed, retrying the operation succeeds.

Note that the file system does not have to be empty before creating a storage domain on it, however, the mount point should have nothing underneath it. Therefore if you want to keep the existing contents, mount the NFS on a server and create a new folder with the correct ownership and permissions. In the following figure a new mount, new_folder, was added and used.

The creation is successful now in the following figure. Note that the old data is only accessible through the previous mount and therefore would require mounting it from another host to access it.

As mentioned in the paper, it is possible for a physical NIC on a KVM host to be associated with multiple virtual networks. For example, if you wished to separate your NFS traffic on a VLAN using the same public network, you would create a virtual network as covered in the section Virtual network, and then drag it to the public NIC in the following figure.

Now you can add a new file system using the VLAN.

A data center with local storage can only support a single host. If a user attempts to add a second host, an error message is displayed, as shown in the following figure.

When creating a new virtual machine, the Boot Options page includes an Attach CD option that enables the user to specify an ISO for booting (for operating system installation). If the user selects the checkbox and there are no entries in the drop-down list, as shown in the following figure, there are no ISOs are available in any storage domains.

To resolve the issue, follow the instructions in . The user can also specify boot options at the time of initial power on of the virtual machine. Make sure to clear the Attach CD check box, otherwise OLVM generates an error.

You can test KVM on virtual machines in a VMware infrastructure if no physical servers are available. This is similar to doing nested ESXi installations. There are two prerequisites that are necessary to succeed in such an implementation. They are:

• Hardware virtualization
• Distributed port group