Home > Storage > PowerMax and VMAX > Storage Admin > Using Dell PowerMax with Linux KVM Implementation Guide > 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 the oVirt Engine 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.
Figure 2 shows an example of the oVirt Open Virtualization Management (OVM) UI for the Administration Portal, which provides a high-level view of all components in the KVM environment.
Figure 2. oVirt Open Virtualization Management
The VM Portal enables the user to drill down into each virtual machine in the environment and make changes at that level. Figure 3 shows the details of a particular virtual machine.
Figure 3. VM Portal
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. Grafana comes preconfigured with a selection of dashboard categories and dashboards for oVirt, as shown in Figure 4:
Figure 4. oVirt dashboards
The individual dashboards offer great detail into the clusters, hosts, and individual VMs running in the environment. Figure 5 shows the host-level dashboard:
Figure 5. Host 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 – 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 known 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 Red Hat’s High Availability Add-On.
Note: For oVirt to support HA for the self-hosted implementation, a second KVM host in the cluster must be enabled as a Hosted Engine. see Adding a KVM host to a cluster. for more detail.
Figure 6 shows an example of a stand-alone implementation in which two physical hosts access the same shared storage.
Figure 6. Standalone oVirt Engine
[https://ovirt.org/documentation/installing_ovirt_as_a_standalone_manager_with_local_databases/index.html]
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.
Figure 7 shows the self-hosted example in which the oVirt Engine is deployed directly in the KVM environment:
Figure 7. Self-hosted oVirt Engine
[https://ovirt.org/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/index.html]
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, we used a self-hosted oVirt Engine due to resource limitations. Figure 8 shows that the hosted engine is displayed like any other virtual machine in the UI:
Figure 8. Self-hosted oVirt Engine VM
oVirt supports two types of hosts: oVirt node and Enterprise Linux.
An oVirt node is a pared-down Enterprise Linux OS (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.
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. Because Enterprise Linux 9.x continues to have issues, it is best only for test or lab purposes. Use 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. For example, Red Hat Virtualization (RHV) has ceased development and only provides maintenance updates, while Oracle Virtualization 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.