This chapter describes configuration that is not strictly required, but may improve the performance or stability of your environment.
General Recommendations
-
Take a full backup as soon as the deployment is complete, and store it in a separate location. Take regular backups thereafter. See Backups and Migration in the Administration Guide.
-
Avoid running any service that {virt-product-fullname} depends on as a virtual machine in the same environment. If this is done, it must be planned carefully to minimize downtime, if the virtual machine containing that service incurs downtime.
-
Ensure the bare-metal host or virtual machine that the {virt-product-fullname} {engine-name} will be installed on has enough entropy. Values below 200 can cause the {engine-name} setup to fail. To check the entropy value, run
cat /proc/sys/kernel/random/entropy_avail
. -
You can automate the deployment of hosts and virtual machines using PXE, Kickstart, Satellite, CloudForms, Ansible, or a combination thereof. However, installing a self-hosted engine using PXE is not supported. See:
-
Automating {hypervisor-fullname} Deployment for the additional requirements for automated {hypervisor-shortname} deployment using PXE and Kickstart.
-
Performing a Standard Installation.
-
Performing an Advanced Installation.
-
Automating Configuration Tasks using Ansible in the Administration Guide.
-
-
Set the system time zone for all machines in your deployment to UTC. This ensures that data collection and connectivity are not interrupted by variations in your local time zone, such as daylight savings time.
-
Use Network Time Protocol (NTP) on all hosts and virtual machines in the environment in order to synchronize time. Authentication and certificates are particularly sensitive to time skew.
-
Document everything, so that anyone who works with the environment is aware of its current state and required procedures.
Security Recommendations
-
Do not disable any security features (such as HTTPS, SELinux, and the firewall) on the hosts or virtual machines.
-
Register all hosts and {enterprise-linux} virtual machines to either the Red Hat Content Delivery Network or Red Hat Satellite in order to receive the latest security updates and errata.
-
Create individual administrator accounts, instead of allowing many people to use the default
admin
account, for proper activity tracking. -
Limit access to the hosts and create separate logins. Do not create a single
root
login for everyone to use. -
Do not create untrusted users on hosts.
-
When deploying the {enterprise-linux-host-fullname}s, only install packages and services required to satisfy virtualization, performance, security, and monitoring requirements. Production hosts should not have additional packages such as analyzers, compilers, or other components that add unnecessary security risk.
Host Recommendations
-
Standardize the hosts in the same cluster. This includes having consistent hardware models and firmware versions. Mixing different server hardware within the same cluster can result in inconsistent performance from host to host.
-
Although you can use both {enterprise-linux-host-fullname} and {hypervisor-fullname} in the same cluster, this configuration should only be used when it serves a specific business or technical requirement.
-
Configure fencing devices at deployment time. Fencing devices are required for high availability.
-
Use separate hardware switches for fencing traffic. If monitoring and fencing go over the same switch, that switch becomes a single point of failure for high availability.
Networking Recommendations
-
Bond network interfaces, especially on production hosts. Bonding improves the overall availability of service, as well as network bandwidth. See Network Bonding in the Administration Guide.
-
A stable network infrastructure configured with DNS and DHCP records.
-
If bonds will be shared with other network traffic, proper quality of service (QoS) is required for storage and other network traffic.
-
For optimal performance and simplified troubleshooting, use VLANs to separate different traffic types and make the best use of 10 GbE or 40 GbE networks.
-
If the underlying switches support jumbo frames, set the MTU to the maximum size (for example,
9000
) that the underlying switches support. This setting enables optimal throughput, with higher bandwidth and reduced CPU usage, for most applications. The default MTU is determined by the minimum size supported by the underlying switches. If you have LLDP enabled, you can see the MTU supported by the peer of each host in the NIC’s tool tip in the Setup Host Networks window.If you change the network’s MTU settings, you must propagate this change to the running virtual machines on the network: Hot unplug and replug every virtual machine’s vNIC that should apply the MTU setting, or restart the virtual machines. Otherwise, these interfaces fail when the virtual machine migrates to another host. For more information, see After network MTU change, some VMs and bridges have the old MTU and seeing packet drops and BZ#1766414.
-
1 GbE networks should only be used for management traffic. Use 10 GbE or 40 GbE for virtual machines and Ethernet-based storage.
-
If additional physical interfaces are added to a host for storage use, clear VM network so that the VLAN is assigned directly to the physical interface.
Recommended Practices for Configuring Host Networks
Always use the {virt-product-shortname} {engine-name} to modify the network configuration of hosts in your clusters. Otherwise, you might create an unsupported configuration. For details, see Network Manager Stateful Configuration (nmstate). |
If your network environment is complex, you may need to configure a host network manually before adding the host to the {virt-product-fullname} {engine-name}.
Consider the following practices for configuring a host network:
-
Configure the network with Cockpit. Alternatively, you can use
nmtui
ornmcli
. -
If a network is not required for a self-hosted engine deployment or for adding a host to the {engine-name}, configure the network in the Administration Portal after adding the host to the {engine-name}. See Creating a New Logical Network in a Data Center or Cluster.
-
Use the following naming conventions:
-
VLAN devices:
VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
-
VLAN interfaces:
physical_device.VLAN_ID
(for example,eth0.23
,eth1.128
,enp3s0.50
) -
Bond interfaces:
bondnumber
(for example,bond0
,bond1
) -
VLANs on bond interfaces:
bondnumber.VLAN_ID
(for example,bond0.50
,bond1.128
)
-
-
Use network bonding. Network teaming is not supported in {virt-product-fullname} and will cause errors if the host is used to deploy a self-hosted engine or added to the {engine-name}.
-
Use recommended bonding modes:
-
If the
ovirtmgmt
network is not used by virtual machines, the network may use any supported bonding mode. -
If the
ovirtmgmt
network is used by virtual machines, see Which bonding modes work when used with a bridge that virtual machine guests or containers connect to?. -
{virt-product-fullname}'s default bonding mode is
(Mode 4) Dynamic Link Aggregation
. If your switch does not support Link Aggregation Control Protocol (LACP), use(Mode 1) Active-Backup
. See Bonding Modes for details.
-
-
Configure a VLAN on a physical NIC as in the following example (although
nmcli
is used, you can use any tool):# nmcli connection add type vlan con-name vlan50 ifname eth0.50 dev eth0 id 50 # nmcli con mod vlan50 +ipv4.dns 8.8.8.8 +ipv4.addresses 123.123.0.1/24 +ipv4.gateway 123.123.0.254
-
Configure a VLAN on a bond as in the following example (although
nmcli
is used, you can use any tool):# nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100" ipv4.method disabled ipv6.method ignore # nmcli connection add type ethernet con-name eth0 ifname eth0 master bond0 slave-type bond # nmcli connection add type ethernet con-name eth1 ifname eth1 master bond0 slave-type bond # nmcli connection add type vlan con-name vlan50 ifname bond0.50 dev bond0 id 50 # nmcli con mod vlan50 +ipv4.dns 8.8.8.8 +ipv4.addresses 123.123.0.1/24 +ipv4.gateway 123.123.0.254
-
Do not disable
firewalld
. -
Customize the firewall rules in the Administration Portal after adding the host to the {engine-name}. See Configuring Host Firewall Rules.
Self-Hosted Engine Recommendations
-
Create a separate data center and cluster for the {virt-product-fullname} {engine-name} and other infrastructure-level services, if the environment is large enough to allow it. Although the {engine-name} virtual machine can run on hosts in a regular cluster, separation from production virtual machines helps facilitate backup schedules, performance, availability, and security.
-
A storage domain dedicated to the {engine-name} virtual machine is created during self-hosted engine deployment. Do not use this storage domain for any other virtual machines.
-
If you are anticipating heavy storage workloads, separate the migration, management, and storage networks to reduce the impact on the {engine-name} virtual machine’s health.
-
Although there is technically no hard limit on the number of hosts per cluster, limit self-hosted engine nodes to 7 nodes per cluster. Distribute the servers in a way that allows better resilience (such as in different racks).
-
All self-hosted engine nodes should have an equal CPU family so that the {engine-name} virtual machine can safely migrate between them. If you intend to have various families, begin the installation with the lowest one.
-
If the {engine-name} virtual machine shuts down or needs to be migrated, there must be enough memory on a self-hosted engine node for the {engine-name} virtual machine to restart on or migrate to it.