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. All managed hosts within a cluster must have the same CPU type. Intel and AMD CPUs cannot co-exist within the same cluster. For information about supported maximums and limits (e.g., the maximum number of hosts per Red Hat Virtualization Manager) see ( Supported Limits for Red Hat Virtualization . 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 web 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. 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 Each data center must have at least one data storage domain. An ISO storage domain per data center is also recommended. Export storage domains are deprecated, but can still be created if necessary. A storage domain can be made of either block devices (iSCSI or Fibre Channel) or a file system. By default, GlusterFS domains and local storage domains support 4K block size. 4K block size can provide better performance, especially when using large files, and it is also necessary when you use tools that require 4K compatibility, such as VDO. Important Red Hat Virtualization currently does not support block storage with a block size of 4K. You must configure block storage in legacy (512b block) mode. The storage types described in the following sections 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. See: Storage in the Administration Guide . Red Hat Enterprise Linux Storage Administration Guide 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: Network File System (NFS) in the Red Hat Enterprise Linux Storage Administration Guide . Preparing and Adding NFS Storage in the Administration Guide . 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. Red Hat Virtualization supports 1500 logical volumes per block-based storage domain. No more than 300 LUNs are permitted. See: Online Storage Management in the Red Hat Enterprise Linux Storage Administration Guide . Adding iSCSI Storage in the Administration Guide . ==== 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. Red Hat Virtualization supports 1500 logical volumes per block-based storage domain. No more than 300 LUNs are permitted. See: Online Storage Management in the Red Hat Enterprise Linux Storage Administration Guide . Adding FCP Storage in the Administration Guide . 3.2.3. 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. Red Hat Virtualization supports 1500 logical volumes per block-based storage domain. No more than 300 LUNs are permitted. See: Online Storage Management in the Red Hat Enterprise Linux Storage Administration Guide . How to Set Up Red Hat Virtualization Manager to Use FCoE in the Administration Guide . 3.2.4. 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: Red Hat Gluster Storage Documentation Configuring Red Hat Virtualization with Red Hat Gluster Storage 3.2.5. 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: Deploying Red Hat Hyperconverged Infrastructure for Virtualization Deploying Red Hat Hyperconverged Infrastructure for Virtualization On A Single Node Automating RHHI for Virtualization Deployment 3.2.6. 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: Red Hat Enterprise Linux Global File System 2 Adding POSIX Compliant File System Storage in the Administration Guide . 3.2.7. 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. For Red Hat Virtualization Hosts, local storage should always be defined on a file system that is separate from / (root). Red Hat recommends using a separate logical volume or disk. 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. Red Hat Virtualization is fully integrated with Cisco Application Centric Infrastructure (ACI), which provides comprehensive network management capabilities, thus mitigating the need to manually configure the Red Hat Virtualization networking infrastructure. The integration is performed by configuring Red Hat Virtualization on Cisco's Application Policy Infrastructure Controller (APIC) version 3.1(1) and later, according to the Cisco's documentation . 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-us/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 can improve the performance of both the Manager and Data Warehouse. Data Warehouse database and service 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 Installing Red Hat Virtualization as a standalone Manager with remote databases . To migrate Data Warehouse post-installation, see Migrating Data Warehouse to a Separate Machine in the Data Warehouse Guide . You can also host the Data Warehouse service and the Data Warehouse database separately from one another. 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 in Installing Red Hat Virtualization as a standalone Manager with remote databases 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 Installing Red Hat Virtualization as a standalone Manager with remote databases . 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 , 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.

Commands: