Red Hat Training

A Red Hat training course is available for Red Hat Virtualization

Chapter 3. Considerations

This chapter describes the advantages, limitations, and available options for various Red Hat Virtualization components.

3.1. Host Types

Use the host type that best suits your environment. You can also use both types of host in the same cluster if required.

3.1.1. Red Hat Virtualization Hosts

Red Hat Virtualization Hosts (RHVH) have the following advantages over Red Hat Enterprise Linux hosts:

  • RHVH is included in the subscription for Red Hat Virtualization. Red Hat Enterprise Linux hosts may require additional subscriptions.
  • RHVH is deployed as a single image. This results in a streamlined update process; the entire image is updated as a whole, as opposed to packages being updated individually.
  • Only the packages and services needed to host virtual machines or manage the host itself are included. This streamlines operations and reduces the overall attack vector; unnecessary packages and services are not deployed and, therefore, cannot be exploited.
  • The Cockpit user interface is available by default and includes extensions specific to Red Hat Virtualization, including virtual machine monitoring tools and a GUI installer for the self-hosted engine. Cockpit is supported on Red Hat Enterprise Linux hosts, but must be manually installed.
Note

Importing RHVH images into Satellite from configured repositories is not supported.

3.1.2. Red Hat Enterprise Linux Hosts

Red Hat Enterprise Linux hosts have the following advantages over Red Hat Virtualization Hosts:

  • Red Hat Enterprise Linux hosts are highly customizable, so may be preferable if, for example, your hosts require a specific file system layout.
  • Red Hat Enterprise Linux hosts are better suited for frequent updates, especially if additional packages are installed. Individual packages can be updated, rather than a whole image.

3.2. Storage Types

A storage domain can be made of either block devices (iSCSI or Fibre Channel) or a file system.

The following storage types are supported for use as data storage domains. ISO and export storage domains only support file-based storage types. The ISO domain supports local storage when used in a local storage data center.

Important

Red Hat Virtualization currently does not support storage with a block size of 4K. You must configure block storage in legacy (512b block) mode.

See:

3.2.1. NFS

NFS versions 3 and 4 are supported by Red Hat Virtualization 4. Production workloads require an enterprise-grade NFS server, unless NFS is only being used as an ISO storage domain. When enterprise NFS is deployed over 10GbE, segregated with VLANs, and individual services are configured to use specific ports, it is both fast and secure.

As NFS exports are grown to accommodate more storage needs, Red Hat Virtualization recognizes the larger data store immediately. No additional configuration is necessary on the hosts or from within Red Hat Virtualization. This provides NFS a slight edge over block storage from a scale and operational perspective.

See:

3.2.2. iSCSI

Production workloads require an enterprise-grade iSCSI server. When enterprise iSCSI is deployed over 10GbE, segregated with VLANs, and utilizes CHAP authentication, it is both fast and secure.

iSCSI can also use multipathing to improve high availability.

See:

3.2.3. Fibre Channel

Fibre Channel is both fast and secure, and should be taken advantage of if it is already in use in the target data center. It also has the advantage of low CPU overhead as compared to iSCSI and NFS.

Fibre Channel can also use multipathing to improve high availability.

See:

3.2.4. Fibre Channel over Ethernet

To use Fibre Channel over Ethernet (FCoE) in Red Hat Virtualization, you must enable the fcoe key on the Manager, and install the vdsm-hook-fcoe package on the hosts.

See:

3.2.5. Red Hat Gluster Storage

Red Hat Gluster Storage (RHGS) is a POSIX-compliant and open source file system. Three or more servers are configured as a Red Hat Gluster Storage cluster, instead of network-attached storage (NAS) appliances or a storage area network (SAN) array.

Red Hat Gluster Storage should be utilized over 10GbE and segregated with VLANs.

Check the compatibility matrix in https://access.redhat.com/articles/2356261 before using RHGS with Red Hat Virtualization.

See:

3.2.6. Red Hat Hyperconverged Infrastructure

Red Hat Hyperconverged Infrastructure (RHHI) combines Red Hat Virtualization and Red Hat Gluster Storage on the same infrastructure, instead of connecting Red Hat Virtualization to a remote Red Hat Gluster Storage server. This compact option reduces operational expenses and overhead.

See:

3.2.7. Red Hat Ceph File System

Red Hat Ceph File System (CephFS) is a file system compatible with POSIX standards that uses a Ceph Storage Cluster to store its data. No special configuration is required on the Red Hat Virtualization side when adding CephFS as a storage domain; it is added the same way as any other POSIX-compliant FS storage.

See: Ceph File System Guide

3.2.8. POSIX-Compliant FS

Other POSIX-compliant file systems can be used as storage domains in Red Hat Virtualization, as long as they are clustered file systems, such as Red Hat Global File System 2 (GFS2), and support sparse files and direct I/O. The Common Internet File System (CIFS), for example, does not support direct I/O, making it incompatible with Red Hat Virtualization.

See:

3.2.9. Local Storage

Local storage is set up on an individual host, using the host’s own resources. When you set up a host to use local storage, it is automatically added to a new data center and cluster that no other hosts can be added to. Virtual machines created in a single-host cluster cannot be migrated, fenced, or scheduled.

See: Preparing and Adding Local Storage in the Administration Guide.

3.3. Networking Considerations

Familiarity with network concepts and their use is highly recommended when planning and setting up networking in a Red Hat Virtualization environment. Read your network hardware vendor’s guides for more information on managing networking.

Logical networks may be supported using physical devices such as NICs, or logical devices such as network bonds. Bonding improves high availability, and provides increased fault tolerance, because all network interface cards in the bond must fail for the bond itself to fail. Bonding modes 1, 2, 3, and 4 support both virtual machine and non-virtual machine network types. Modes 0, 5, and 6 only support non-virtual machine networks. Red Hat Virtualization uses Mode 4 by default.

It is not necessary to have one device for each logical network, as multiple logical networks can share a single device by using Virtual LAN (VLAN) tagging to isolate network traffic. To make use of this feature, VLAN tagging must also be supported at the switch level.

The limits that apply to the number of logical networks that you may define in a Red Hat Virtualization environment are:

  • The number of logical networks attached to a host is limited to the number of available network devices combined with the maximum number of Virtual LANs (VLANs), which is 4096.
  • The number of networks that can be attached to a host in a single operation is currently limited to 50.
  • The number of logical networks in a cluster is limited to the number of logical networks that can be attached to a host as networking must be the same for all hosts in a cluster.
  • The number of logical networks in a data center is limited only by the number of clusters it contains in combination with the number of logical networks permitted per cluster.
Important

Take additional care when modifying the properties of the Management network (ovirtmgmt). Incorrect changes to the properties of the ovirtmgmt network may cause hosts to become unreachable.

Important

If you plan to use Red Hat Virtualization to provide services for other environments, remember that the services will stop if the Red Hat Virtualization environment stops operating.

3.4. Directory Server Support

During installation, Red Hat Virtualization Manager creates a default admin user in a default internal domain. This account is intended for use when initially configuring the environment, and for troubleshooting. You can create additional users on the internal domain using ovirt-aaa-jdbc-tool. User accounts created on local domains are known as local users. See Administering User Tasks From the Command Line in the Administration Guide.

You can also attach an external directory server to your Red Hat Virtualization environment and use it as an external domain. User accounts created on external domains are known as directory users. Attachment of more than one directory server to the Manager is also supported.

The following directory servers are supported for use with Red Hat Virtualization. For more detailed information on installing and configuring a supported directory server, see the vendor’s documentation.

Active Directory
https://docs.microsoft.com/en-us/windows-server/identity/identity-and-access
Identity Management (IdM - based on IPA)
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html
Red Hat Directory Server 9 (RHDS 9 - based on 389DS)
https://access.redhat.com/documentation/en/red-hat-directory-server/
OpenLDAP
http://www.openldap.org/doc/
IBM Security (Tivoli) Directory Server
https://www.ibm.com/support/knowledgecenter/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/welcome.html
Important

A user with permissions to read all users and groups must be created in the directory server specifically for use as the Red Hat Virtualization administrative user. Do not use the administrative user for the directory server as the Red Hat Virtualization administrative user.

See: Users and Roles in the Administration Guide.

3.5. Infrastructure Considerations

3.5.1. Local or Remote Hosting

The following components can be hosted on either the Manager or a remote machine. Keeping all components on the Manager machine is easier and requires less maintenance, so is preferable when performance is not an issue. Moving components to a remote machine requires more maintenance, but it improves the performance of both the Manager and the Data Warehouse.

Data Warehouse

To host Data Warehouse on the Manager, select Yes when prompted by engine-setup.

To host Data Warehouse on a remote machine, select No when prompted by engine-setup, and see Installing and Configuring Data Warehouse on a Separate Machine in the Data Warehouse Guide.

To migrate Data Warehouse post-installation, see Migrating Data Warehouse to a Separate Machine in the Data Warehouse Guide.

Manager database

To host the Manager database on the Manager, select Local when prompted by engine-setup.

To host the Manager database on a remote machine, see Preparing a Remote PostgreSQL Database for Use with the Red Hat Virtualization Manager in the Installation Guide before running engine-setup on the Manager.

To migrate the Manager database post-installation, see Migrating the Engine Database to a Remote Server Database in the Administration Guide.

Websocket proxy

To host the websocket proxy on the Manager, select Yes when prompted by engine-setup.

To host the websocket proxy on a remote machine, select No when prompted by engine-setup, and see Installing a Websocket Proxy on a Separate Machine in the Installation Guide.

To migrate the websocket proxy post-installation, see Migrating the Websocket Proxy to a Separate Machine in the Administration Guide.

Important

Self-hosted engine environments use an appliance to install and configure the Manager virtual machine, so Data Warehouse, the Manager database, and the websocket proxy can only be made external post-installation.

3.5.2. Remote Hosting Only

The following components must be hosted on a remote machine:

DNS
Due to the extensive use of DNS in a Red Hat Virtualization environment, running the environment’s DNS service as a virtual machine hosted in the environment is not supported.
Storage
With the exception of local storage and Red Hat Hyperconverged Infrastructure, the storage service must not be on the same machine as the Manager or any host.
Identity Management
IdM (ipa-server) is incompatible with the mod_ssl package, which is required by the Manager.