10.5. Host Tasks
10.5.1. Adding Standard Hosts to the Red Hat Virtualization Manager
Adding a host to your Red Hat Virtualization environment can take some time, as the following steps are completed by the platform: virtualization checks, installation of packages, and creation of a bridge.
When creating a management bridge that uses a static IPv6 address, disable network manager control in its interface configuration (ifcfg) file before adding a host. See https://access.redhat.com/solutions/3981311 for more information.
Procedure
-
From the Administration Portal, click
. - Click .
- Use the drop-down list to select the Data Center and Host Cluster for the new host.
- Enter the Name and the Address of the new host. The standard SSH port, port 22, is auto-filled in the SSH Port field.
Select an authentication method to use for the Manager to access the host.
- Enter the root user’s password to use password authentication.
- Alternatively, copy the key displayed in the SSH PublicKey field to /root/.ssh/authorized_keys on the host to use public key authentication.
Optionally, click the Advanced Parameters button to change the following advanced host settings:
- Disable automatic firewall configuration.
- Add a host SSH fingerprint to increase security. You can add it manually, or fetch it automatically.
- Optionally configure power management, where the host has a supported power management card. For information on power management configuration, see Host Power Management Settings Explained in the Administration Guide.
- Click .
The new host displays in the list of hosts with a status of Installing
, and you can view the progress of the installation in the Events section of the Notification Drawer (
). After a brief delay the host status changes to Up
.
10.5.2. Adding a Satellite Host Provider Host
The process for adding a Satellite host provider host is almost identical to that of adding a Red Hat Enterprise Linux host except for the method by which the host is identified in the Manager. The following procedure outlines how to add a host provided by a Satellite host provider.
Adding a Satellite Host Provider Host
-
Click
. - Click New.
- Use the drop-down menu to select the Host Cluster for the new host.
- Select the Foreman/Satellite check box to display the options for adding a Satellite host provider host and select the provider from which the host is to be added.
Select either Discovered Hosts or Provisioned Hosts.
- Discovered Hosts (default option): Select the host, host group, and compute resources from the drop-down lists.
Provisioned Hosts: Select a host from the Providers Hosts drop-down list.
Any details regarding the host that can be retrieved from the external provider are automatically set, and can be edited as desired.
- Enter the Name and SSH Port (Provisioned Hosts only) of the new host.
Select an authentication method to use with the host.
- Enter the root user’s password to use password authentication.
- Copy the key displayed in the SSH PublicKey field to /root/.ssh/authorized_hosts on the host to use public key authentication (Provisioned Hosts only).
You have now completed the mandatory steps to add a Red Hat Enterprise Linux host. Click the Advanced Parameters drop-down button to show the advanced host settings.
- Optionally disable automatic firewall configuration.
- Optionally add a host SSH fingerprint to increase security. You can add it manually, or fetch it automatically.
- You can configure the Power Management, SPM, Console, and Network Provider using the applicable tabs now; however, as these are not fundamental to adding a Red Hat Enterprise Linux host, they are not covered in this procedure.
- Click OK to add the host and close the window.
The new host displays in the list of hosts with a status of Installing
, and you can view the progress of the installation in the details view. After installation is complete, the status will update to Reboot
. The host must be activated for the status to change to Up
.
10.5.3. Configuring Satellite Errata Management for a Host
Red Hat Virtualization can be configured to view errata from Red Hat Satellite. This enables the host administrator to receive updates about available errata, and their importance, in the same dashboard used to manage host configuration. For more information about Red Hat Satellite see the Red Hat Satellite Documentation.
Red Hat Virtualization 4.3 supports errata management with Red Hat Satellite 6.5.
Hosts are identified in the Satellite server by their FQDN. Hosts added using an IP address will not be able to report errata. This ensures that an external content host ID does not need to be maintained in Red Hat Virtualization.
The Satellite account used to manage the host must have Administrator permissions and a default organization set.
Configuring Satellite Errata Management for a Host
- Add the Satellite server as an external provider. See Section 14.2.1, “Adding a Red Hat Satellite Instance for Host Provisioning” for more information.
Associate the required host with the Satellite server.
NoteThe host must be registered to the Satellite server and have the
katello-agent
package installed.For information on how to configure a host registration and how to register a host and install the katello-agent package see Registering Hosts in the Red Hat Satellite document Managing Hosts.
-
Click
and select the host. - Click Edit.
- Select the Use Foreman/Satellite check box.
- Select the required Satellite server from the drop-down list.
- Click OK.
-
Click
The host is now configured to show the available errata, and their importance, in the same dashboard used to manage host configuration.
10.5.4. Explanation of Settings and Controls in the New Host and Edit Host Windows
10.5.5. Host General Settings Explained
These settings apply when editing the details of a host or adding new Red Hat Enterprise Linux hosts and Satellite host provider hosts.
The General settings table contains the information required on the General tab of the New Host or Edit Host window.
Field Name | Description |
---|---|
Host Cluster | The cluster and data center to which the host belongs. |
Use Foreman/Satellite | Select or clear this check box to view or hide options for adding hosts provided by Satellite host providers. The following options are also available: Discovered Hosts
Provisioned Hosts
|
Name | The name of the host. This text field has a 40-character limit and must be a unique name with any combination of uppercase and lowercase letters, numbers, hyphens, and underscores. |
Comment | A field for adding plain text, human-readable comments regarding the host. |
Hostname | The IP address or resolvable host name of the host. If a resolvable hostname is used, you must ensure for all addresses (IPv4 and IPv6) that the hostname is resolved to match the IP addresses (IPv4 and IPv6) used by the management network of the host. |
Password | The password of the host’s root user. This can only be given when you add the host; it cannot be edited afterwards. |
SSH Public Key | Copy the contents in the text box to the /root/.ssh/authorized_hosts file on the host to use the Manager’s SSH key instead of a password to authenticate with a host. |
Automatically configure host firewall | When adding a new host, the Manager can open the required ports on the host’s firewall. This is enabled by default. This is an Advanced Parameter. |
SSH Fingerprint | You can fetch the host’s SSH fingerprint, and compare it with the fingerprint you expect the host to return, ensuring that they match. This is an Advanced Parameter. |
10.5.6. Host Power Management Settings Explained
The Power Management settings table contains the information required on the Power Management tab of the New Host or Edit Host windows. You can configure power management if the host has a supported power management card.
Field Name | Description |
---|---|
Enable Power Management | Enables power management on the host. Select this check box to enable the rest of the fields in the Power Management tab. |
Kdump integration | Prevents the host from fencing while performing a kernel crash dump, so that the crash dump is not interrupted. In Red Hat Enterprise Linux 7.1 and later, kdump is available by default. If kdump is available on the host, but its configuration is not valid (the kdump service cannot be started), enabling Kdump integration will cause the host (re)installation to fail. If this is the case, see Section 10.6.4, “fence_kdump Advanced Configuration”. |
Disable policy control of power management | Power management is controlled by the Scheduling Policy of the host’s cluster. If power management is enabled and the defined low utilization value is reached, the Manager will power down the host machine, and restart it again when load balancing requires or there are not enough free hosts in the cluster. Select this check box to disable policy control. |
Agents by Sequential Order | Lists the host’s fence agents. Fence agents can be sequential, concurrent, or a mix of both.
Fence agents are sequential by default. Use the up and down buttons to change the sequence in which the fence agents are used. To make two fence agents concurrent, select one fence agent from the Concurrent with drop-down list next to the other fence agent. Additional fence agents can be added to the group of concurrent fence agents by selecting the group from the Concurrent with drop-down list next to the additional fence agent. |
Add Fence Agent | Click the + button to add a new fence agent. The Edit fence agent window opens. See the table below for more information on the fields in this window. |
Power Management Proxy Preference | By default, specifies that the Manager will search for a fencing proxy within the same cluster as the host, and if no fencing proxy is found, the Manager will search in the same dc (data center). Use the up and down buttons to change the sequence in which these resources are used. This field is available under Advanced Parameters. |
The following table contains the information required in the Edit fence agent window.
Field Name | Description |
---|---|
Address | The address to access your host’s power management device. Either a resolvable hostname or an IP address. |
User Name | User account with which to access the power management device. You can set up a user on the device, or use the default user. |
Password | Password for the user accessing the power management device. |
Type | The type of power management device in your host. Choose one of the following:
For more information about power management devices, see Power Management in the Technical Reference. |
Port | The port number used by the power management device to communicate with the host. |
Slot | The number used to identify the blade of the power management device. |
Service Profile |
The service profile name used to identify the blade of the power management device. This field appears instead of Slot when the device type is |
Options | Power management device specific options. Enter these as 'key=value'. See the documentation of your host’s power management device for the options available.
For Red Hat Enterprise Linux 7 hosts, if you are using cisco_ucs as the power management device, you also need to append |
Secure | Select this check box to allow the power management device to connect securely to the host. This can be done via ssh, ssl, or other authentication protocols depending on the power management agent. |
10.5.7. SPM Priority Settings Explained
The SPM settings table details the information required on the SPM tab of the New Host or Edit Host window.
Field Name | Description |
---|---|
SPM Priority | Defines the likelihood that the host will be given the role of Storage Pool Manager (SPM). The options are Low, Normal, and High priority. Low priority means that there is a reduced likelihood of the host being assigned the role of SPM, and High priority means there is an increased likelihood. The default setting is Normal. |
10.5.8. Host Console Settings Explained
The Console settings table details the information required on the Console tab of the New Host or Edit Host window.
Field Name | Description |
---|---|
Override display address | Select this check box to override the display addresses of the host. This feature is useful in a case where the hosts are defined by internal IP and are behind a NAT firewall. When a user connects to a virtual machine from outside of the internal network, instead of returning the private address of the host on which the virtual machine is running, the machine returns a public IP or FQDN (which is resolved in the external network to the public IP). |
Display address | The display address specified here will be used for all virtual machines running on this host. The address must be in the format of a fully qualified domain name or IP. |
10.5.9. Network Provider Settings Explained
The Network Provider settings table details the information required on the Network Provider tab of the New Host or Edit Host window.
Field Name | Description |
---|---|
External Network Provider | If you have added an external network provider and want the host’s network to be provisioned by the external network provider, select one from the list. |
10.5.10. Kernel Settings Explained
The Kernel settings table details the information required on the Kernel tab of the New Host or Edit Host window. Common kernel boot parameter options are listed as check boxes so you can easily select them.
For more complex changes, use the free text entry field next to Kernel command line to add in any additional parameters required. If you change any kernel command line parameters, you must reinstall the host.
If the host is attached to the Manager, you must place the host into maintenance mode before making changes. After making the changes, reinstall the host to apply the changes.
Field Name | Description |
---|---|
Hostdev Passthrough & SR-IOV | Enables the IOMMU flag in the kernel to allow a host device to be used by a virtual machine as if the device is a device attached directly to the virtual machine itself. The host hardware and firmware must also support IOMMU. The virtualization extension and IOMMU extension must be enabled on the hardware. See Configuring a Host for PCI Passthrough. IBM POWER8 has IOMMU enabled by default. |
Nested Virtualization |
Enables the vmx or svm flag to allow you to run virtual machines within virtual machines. This option is only intended for evaluation purposes and not supported for production purposes. The |
Unsafe Interrupts | If IOMMU is enabled but the passthrough fails because the hardware does not support interrupt remapping, you can consider enabling this option. Note that you should only enable this option if the virtual machines on the host are trusted; having the option enabled potentially exposes the host to MSI attacks from the virtual machines. This option is only intended to be used as a workaround when using uncertified hardware for evaluation purposes. |
PCI Reallocation | If your SR-IOV NIC is unable to allocate virtual functions because of memory issues, consider enabling this option. The host hardware and firmware must also support PCI reallocation. This option is only intended to be used as a workaround when using uncertified hardware for evaluation purposes. |
Kernel command line | This field allows you to append more kernel parameters to the default parameters. |
If the kernel boot parameters are grayed out, click the reset button and the options will be available.
10.5.11. Hosted Engine Settings Explained
The Hosted Engine settings table details the information required on the Hosted Engine tab of the New Host or Edit Host window.
Field Name | Description |
---|---|
Choose hosted engine deployment action | Three options are available:
|
10.5.12. Configuring Host Power Management Settings
Configure your host power management device settings to perform host life-cycle operations (stop, start, restart) from the Administration Portal.
You must configure host power management in order to utilize host high availability and virtual machine high availability. For more information about power management devices, see Power Management in the Technical Reference.
Configuring Power Management Settings
-
Click
and select a host. -
Click
, and click OK to confirm. - When the host is in maintenance mode, click Edit.
- Click the Power Management tab.
- Select the Enable Power Management check box to enable the fields.
Select the Kdump integration check box to prevent the host from fencing while performing a kernel crash dump.
ImportantIf you enable or disable Kdump integration on an existing host, you must reinstall the host for kdump to be configured.
- Optionally, select the Disable policy control of power management check box if you do not want your host’s power management to be controlled by the Scheduling Policy of the host’s cluster.
- Click the plus (+) button to add a new power management device. The Edit fence agent window opens.
- Enter the User Name and Password of the power management device into the appropriate fields.
- Select the power management device Type in the drop-down list.
- Enter the IP address in the Address field.
- Enter the SSH Port number used by the power management device to communicate with the host.
- Enter the Slot number used to identify the blade of the power management device.
Enter the Options for the power management device. Use a comma-separated list of 'key=value' entries.
- If both IPv4 and IPv6 IP addresses can be used (default), leave the Options field blank.
-
If only IPv4 IP addresses can be used, enter
inet4_only=1
. -
If only IPv6 IP addresses can be used, enter
inet6_only=1
.
- Select the Secure check box to enable the power management device to connect securely to the host.
- Click Test to ensure the settings are correct. Test Succeeded, Host Status is: on will display upon successful verification.
- Click OK to close the Edit fence agent window.
- In the Power Management tab, optionally expand the Advanced Parameters and use the up and down buttons to specify the order in which the Manager will search the host’s cluster and dc (datacenter) for a fencing proxy.
- Click OK.
- For IPv6, Red Hat Virtualization supports only static addressing.
- Dual-stack IPv4 and IPv6 addressing is not supported.
The
10.5.13. Configuring Host Storage Pool Manager Settings
The Storage Pool Manager (SPM) is a management role given to one of the hosts in a data center to maintain access control over the storage domains. The SPM must always be available, and the SPM role will be assigned to another host if the SPM host becomes unavailable. As the SPM role uses some of the host’s available resources, it is important to prioritize hosts that can afford the resources.
The Storage Pool Manager (SPM) priority setting of a host alters the likelihood of the host being assigned the SPM role: a host with high SPM priority will be assigned the SPM role before a host with low SPM priority.
Configuring SPM settings
-
Click
. - Click Edit.
- Click the SPM tab.
- Use the radio buttons to select the appropriate SPM priority for the host.
- Click OK.
10.5.14. Configuring a Host for PCI Passthrough
This is one in a series of topics that show how to set up and configure SR-IOV on Red Hat Virtualization. For more information, see Setting Up and Configuring SR-IOV
Enabling PCI passthrough allows a virtual machine to use a host device as if the device were directly attached to the virtual machine. To enable the PCI passthrough function, you must enable virtualization extensions and the IOMMU function. The following procedure requires you to reboot the host. If the host is attached to the Manager already, ensure you place the host into maintenance mode first.
Prerequisites
- Ensure that the host hardware meets the requirements for PCI device passthrough and assignment. See PCI Device Requirements for more information.
Configuring a Host for PCI Passthrough
- Enable the virtualization extension and IOMMU extension in the BIOS. See Enabling Intel VT-x and AMD-V virtualization hardware extensions in BIOS in the Red Hat Enterprise Linux Virtualization Deployment and Administration Guide for more information.
Enable the IOMMU flag in the kernel by selecting the Hostdev Passthrough & SR-IOV check box when adding the host to the Manager or by editing the grub configuration file manually.
- To enable the IOMMU flag from the Administration Portal, see Adding Standard Hosts to the Red Hat Virtualization Manager and Kernel Settings Explained.
- To edit the grub configuration file manually, see Enabling IOMMU Manually.
- For GPU passthrough, you need to run additional configuration steps on both the host and the guest system. See GPU device passthrough: Assigning a host GPU to a single virtual machine in Setting up an NVIDIA GPU for a virtual machine in Red Hat Virtualization for more information.
Enabling IOMMU Manually
Enable IOMMU by editing the grub configuration file.
NoteIf you are using IBM POWER8 hardware, skip this step as IOMMU is enabled by default.
For Intel, boot the machine, and append
intel_iommu=on
to the end of theGRUB_CMDLINE_LINUX
line in the grub configuration file.# vi /etc/default/grub ... GRUB_CMDLINE_LINUX="nofb splash=quiet console=tty0 ... intel_iommu=on ...
For AMD, boot the machine, and append
amd_iommu=on
to the end of theGRUB_CMDLINE_LINUX
line in the grub configuration file.# vi /etc/default/grub ... GRUB_CMDLINE_LINUX="nofb splash=quiet console=tty0 ... amd_iommu=on ...
NoteIf
intel_iommu=on
oramd_iommu=on
works, you can try addingiommu=pt
oramd_iommu=pt
. Thept
option only enables IOMMU for devices used in passthrough and provides better host performance. However, the option might not be supported on all hardware. Revert to previous option if thept
option doesn’t work for your host.If the passthrough fails because the hardware does not support interrupt remapping, you can consider enabling the
allow_unsafe_interrupts
option if the virtual machines are trusted. Theallow_unsafe_interrupts
is not enabled by default because enabling it potentially exposes the host to MSI attacks from virtual machines. To enable the option:# vi /etc/modprobe.d options vfio_iommu_type1 allow_unsafe_interrupts=1
Refresh the grub.cfg file and reboot the host for these changes to take effect:
# grub2-mkconfig -o /boot/grub2/grub.cfg
# reboot
To enable SR-IOV and assign dedicated virtual NICs to virtual machines, see https://access.redhat.com/articles/2335291.
10.5.15. Moving a Host to Maintenance Mode
Many common maintenance tasks, including network configuration and deployment of software updates, require that hosts be placed into maintenance mode. Hosts should be placed into maintenance mode before any event that might cause VDSM to stop working properly, such as a reboot, or issues with networking or storage.
When a host is placed into maintenance mode the Red Hat Virtualization Manager attempts to migrate all running virtual machines to alternative hosts. The standard prerequisites for live migration apply, in particular there must be at least one active host in the cluster with capacity to run the migrated virtual machines.
Virtual machines that are pinned to the host and cannot be migrated are shut down. You can check which virtual machines are pinned to the host by clicking Virtual Machines tab of the host’s details view.
in thePlacing a Host into Maintenance Mode
-
Click
and select the desired host. -
Click
to open the Maintenance Host(s) confirmation window. Optionally, enter a Reason for moving the host into maintenance mode, which will appear in the logs and when the host is activated again.
NoteThe host maintenance Reason field will only appear if it has been enabled in the cluster settings. See Section 8.2.2, “General Cluster Settings Explained” for more information.
Optionally, select the required options for hosts that support Gluster.
Select the Ignore Gluster Quorum and Self-Heal Validations option to avoid the default checks. By default, the Manager checks that the Gluster quorum is not lost when the host is moved to maintenance mode. The Manager also checks that there is no self-heal activity that will be affected by moving the host to maintenance mode. If the Gluster quorum will be lost or if there is self-heal activity that will be affected, the Manager prevents the host from being placed into maintenance mode. Only use this option if there is no other way to place the host in maintenance mode.
Select the Stop Gluster Service option to stop all Gluster services while moving the host to maintenance mode.
NoteThese fields will only appear in the host maintenance window when the selected host supports Gluster. See Replacing the Primary Gluster Storage Node in Maintaining Red Hat Hyperconverged Infrastructure for more information.
- Click OK to initiate maintenance mode.
All running virtual machines are migrated to alternative hosts. If the host is the Storage Pool Manager (SPM), the SPM role is migrated to another host. The Status field of the host changes to Preparing for Maintenance
, and finally Maintenance
when the operation completes successfully. VDSM does not stop while the host is in maintenance mode.
If migration fails on any virtual machine, click
10.5.16. Activating a Host from Maintenance Mode
A host that has been placed into maintenance mode, or recently added to the environment, must be activated before it can be used. Activation may fail if the host is not ready; ensure that all tasks are complete before attempting to activate the host.
Activating a Host from Maintenance Mode
-
Click
and select the host. -
Click
.
The host status changes to Unassigned
, and finally Up
when the operation is complete. Virtual machines can now run on the host. Virtual machines that were migrated off the host when it was placed into maintenance mode are not automatically migrated back to the host when it is activated, but can be migrated manually. If the host was the Storage Pool Manager (SPM) before being placed into maintenance mode, the SPM role does not return automatically when the host is activated.
10.5.17. Configuring Host Firewall Rules
You can configure the host firewall rules so that they are persistent, using Ansible. The cluster must be configured to use firewalld
, not iptables
.
iptables
is deprecated.
Configuring Firewall Rules for Hosts
On the Manager machine, edit ovirt-host-deploy-post-tasks.yml.example to add a custom firewall port:
# vi /etc/ovirt-engine/ansible/ovirt-host-deploy-post-tasks.yml.example --- # # Any additional tasks required to be executing during host deploy process can # be added below # - name: Enable additional port on firewalld firewalld: port: "12345/tcp" permanent: yes immediate: yes state: enabled
- Save the file to another location as ovirt-host-deploy-post-tasks.yml.
New or reinstalled hosts are configured with the updated firewall rules.
Existing hosts must be reinstalled by clicking
10.5.18. Removing a Host
Remove a host from your virtualized environment.
Removing a host
-
Click
and select the host. -
Click
. - when the host is in maintenance mode, click Remove to open the Remove Host(s) confirmation window.
- Select the Force Remove check box if the host is part of a Red Hat Gluster Storage cluster and has volume bricks on it, or if the host is non-responsive.
- Click OK.
10.5.19. Updating Hosts Between Minor Releases
You can update all hosts in a cluster, or update individual hosts.
10.5.19.1. Updating All Hosts in a Cluster
You can update all hosts in a cluster instead of updating hosts individually. This is particularly useful during upgrades to new versions of Red Hat Virtualization. See https://github.com/oVirt/ovirt-ansible-cluster-upgrade/blob/master/README.md for more information about the Ansible role used to automate the updates.
Red Hat recommends updating one cluster at a time.
Limitations
-
On RHVH, the update only preserves modified content in the
/etc
and/var
directories. Modified data in other paths is overwritten during an update. - If migration is enabled at the cluster level, virtual machines are automatically migrated to another host in the cluster.
- In a self-hosted engine environment, the Manager virtual machine can only migrate between self-hosted engine nodes in the same cluster. It cannot migrate to standard hosts.
- The cluster must have sufficient memory reserved for its hosts to perform maintenance. Otherwise, virtual machine migrations will hang and fail. You can reduce the memory usage of host updates by shutting down some or all virtual machines before updating hosts.
- You cannot migrate a pinned virtual machine (such as a virtual machine using a vGPU) to another host. Pinned virtual machines are shut down during the update, unless you choose to skip that host instead.
Procedure
-
In the Administration Portal, click
and select the cluster. - Click Upgrade.
- Select the hosts to update, then click Next.
Configure the options:
- Stop Pinned VMs shuts down any virtual machines that are pinned to hosts in the cluster, and is selected by default. You can clear this check box to skip updating those hosts so that the pinned virtual machines stay running, such as when a pinned virtual machine is running important services or processes and you do not want it to shut down at an unknown time during the update.
-
Upgrade Timeout (Minutes) sets the time to wait for an individual host to be updated before the cluster upgrade fails with a timeout. The default is
60
. You can increase it for large clusters where 60 minutes might not be enough, or reduce it for small clusters where the hosts update quickly. - Check Upgrade checks each host for available updates before running the upgrade process. It is not selected by default, but you can select it if you need to ensure that recent updates are included, such as when you have configured the Manager to check for host updates less frequently than the default.
- Reboot After Upgrade reboots each host after it is updated, and is selected by default. You can clear this check box to speed up the process if you are sure that there are no pending updates that require a host reboot.
-
Use Maintenance Policy sets the cluster’s scheduling policy to
cluster_maintenance
during the update. It is selected by default, so activity is limited and virtual machines cannot start unless they are highly available. You can clear this check box if you have a custom scheduling policy that you want to keep using during the update, but this could have unknown consequences. Ensure your custom policy is compatible with cluster upgrade activity before disabling this option.
- Click Next.
- Review the summary of the hosts and virtual machines that will be affected.
- Click Upgrade.
You can track the progress of host updates in the
You can track the progress of individual virtual machine migrations in the Status column of the
10.5.19.2. Updating Individual Hosts
Use the host upgrade manager to update individual hosts directly from the Administration Portal.
The upgrade manager only checks hosts with a status of Up or Non-operational, but not Maintenance.
Limitations
-
On RHVH, the update only preserves modified content in the
/etc
and/var
directories. Modified data in other paths is overwritten during an update. - If migration is enabled at the cluster level, virtual machines are automatically migrated to another host in the cluster. Update a host when its usage is relatively low.
- In a self-hosted engine environment, the Manager virtual machine can only migrate between self-hosted engine nodes in the same cluster. It cannot migrate to standard hosts.
- The cluster must have sufficient memory reserved for its hosts to perform maintenance. Otherwise, virtual machine migrations will hang and fail. You can reduce the memory usage of host updates by shutting down some or all virtual machines before updating hosts.
- Do not update all hosts at the same time, as one host must remain available to perform Storage Pool Manager (SPM) tasks.
- You cannot migrate a pinned virtual machine (such as a virtual machine using a vGPU) to another host. Pinned virtual machines must be shut down before updating the host.
Procedure
Ensure that the correct repositories are enabled. To view a list of currently enabled repositories, run
yum repolist
.For Red Hat Virtualization Hosts:
# subscription-manager repos --enable=rhel-7-server-rhvh-4-rpms
For Red Hat Enterprise Linux hosts:
# subscription-manager repos \ --enable=rhel-7-server-rpms \ --enable=rhel-7-server-rhv-4-mgmt-agent-rpms \ --enable=rhel-7-server-ansible-2.9-rpms
-
In the Administration Portal, click
and select the host to be updated. Click
and click . Open the Notification Drawer ( ) and expand the Events section to see the result.
-
If an update is available, click
. Click
to update the host. Running virtual machines are migrated according to their migration policy. If migration is disabled for any virtual machines, you are prompted to shut them down.The details of the host are updated in
and the status transitions through these stages: Maintenance > Installing > Reboot > Up
NoteIf the update fails, the host’s status changes to Install Failed. From Install Failed you can click
again.
Repeat this procedure for each host in the Red Hat Virtualization environment.
Red Hat recommends updating the hosts from the Administration Portal. However, you can update the hosts using yum update
instead:
10.5.19.3. Manually Updating Hosts
You can use the yum
command to update your hosts. Update your systems regularly, to ensure timely application of security and bug fixes.
Limitations
-
On RHVH, the update only preserves modified content in the
/etc
and/var
directories. Modified data in other paths is overwritten during an update. - If migration is enabled at the cluster level, virtual machines are automatically migrated to another host in the cluster. Update a host when its usage is relatively low.
- In a self-hosted engine environment, the Manager virtual machine can only migrate between self-hosted engine nodes in the same cluster. It cannot migrate to standard hosts.
- The cluster must have sufficient memory reserved for its hosts to perform maintenance. Otherwise, virtual machine migrations will hang and fail. You can reduce the memory usage of host updates by shutting down some or all virtual machines before updating hosts.
- Do not update all hosts at the same time, as one host must remain available to perform Storage Pool Manager (SPM) tasks.
- You cannot migrate a pinned virtual machine (such as a virtual machine using a vGPU) to another host. Pinned virtual machines must be shut down before updating the host.
Procedure
Ensure the correct repositories are enabled. You can check which repositories are currently enabled by running
yum repolist
.For Red Hat Virtualization Hosts:
# subscription-manager repos --enable=rhel-7-server-rhvh-4-rpms
For Red Hat Enterprise Linux hosts:
# subscription-manager repos \ --enable=rhel-7-server-rpms \ --enable=rhel-7-server-rhv-4-mgmt-agent-rpms \ --enable=rhel-7-server-ansible-2.9-rpms
-
In the Administration Portal, click
and select the host to be updated. -
Click
. Update the host:
# yum update
Reboot the host to ensure all updates are correctly applied.
NoteCheck the imgbased logs to see if any additional package updates have failed for a Red Hat Virtualization Host. If some packages were not successfully reinstalled after the update, check that the packages are listed in /var/imgbased/persisted-rpms. Add any missing packages then run
rpm -Uvh /var/imgbased/persisted-rpms/*
.
Repeat this process for each host in the Red Hat Virtualization environment.
10.5.20. Reinstalling Hosts
Reinstall Red Hat Virtualization Hosts (RHVH) and Red Hat Enterprise Linux hosts from the Administration Portal. The procedure includes stopping and restarting the host.
Prerequisites
- If migration is enabled at cluster level, virtual machines are automatically migrated to another host in the cluster; as a result, it is recommended that host reinstalls are performed at a time when the host’s usage is relatively low.
- Ensure that the cluster has sufficient memory reserve in order for its hosts to perform maintenance. If a cluster lacks sufficient memory, the virtual machine migration operation will hang and then fail. You can reduce the memory usage of this operation by shutting down some or all virtual machines before moving the host to maintenance.
- Ensure that the cluster contains more than one host before performing a reinstall. Do not attempt to reinstall all the hosts at the same time, as one host must remain available to perform Storage Pool Manager (SPM) tasks.
Procedure
-
Click
and select the host. -
Click
. -
Click
to open the Install Host window. - Click OK to reinstall the host.
Once successfully reinstalled, the host displays a status of Up. Any virtual machines that were migrated off the host can now be migrated back to it.
After a Red Hat Virtualization Host is successfully registered to the Red Hat Virtualization Manager and then reinstalled, it may erroneously appear in the Administration Portal with the status of Install Failed. Click
10.5.21. Viewing Host Errata
Errata for each host can be viewed after the host has been configured to receive errata information from the Red Hat Satellite server. For more information on configuring a host to receive errata information see Section 10.5.3, “Configuring Satellite Errata Management for a Host”
Viewing Host Errata
-
Click
. - Click the host’s name to open the details view.
- Click the Errata tab.
10.5.22. Viewing the Health Status of a Host
Hosts have an external health status in addition to their regular Status. The external health status is reported by plug-ins or external systems, or set by an administrator, and appears to the left of the host’s Name as one of the following icons:
- OK: No icon
- Info:
- Warning:
- Error:
- Failure:
To view further details about the host’s health status, click the host’s name to open the details view, and click the Events tab.
The host’s health status can also be viewed using the REST API. A GET
request on a host will include the external_status
element, which contains the health status.
You can set a host’s health status in the REST API via the events
collection. For more information, see Adding Events in the REST API Guide.
10.5.23. Viewing Host Devices
You can view the host devices for each host in the Host Devices tab in the details view. If the host has been configured for direct device assignment, these devices can be directly attached to virtual machines for improved performance.
For more information on the hardware requirements for direct device assignment, see Additional Hardware Considerations for Using Device Assignment in Hardware Considerations for Implementing SR-IOV.
For more information on configuring the host for direct device assignment, see Section 10.5.14, “Configuring a Host for PCI Passthrough”.
For more information on attaching host devices to virtual machines, see Host Devices in the Virtual Machine Management Guide.
Viewing Host Devices
-
Click
. - Click the host’s name to open the details view.
- Click Host Devices tab.
This tab lists the details of the host devices, including whether the device is attached to a virtual machine, and currently in use by that virtual machine.
10.5.24. Accessing Cockpit from the Administration Portal
Cockpit is available by default on Red Hat Virtualization Hosts (RHVH) and Red Hat Enterprise Linux hosts. You can access the Cockpit web interface by typing the address into a browser, or through the Administration Portal.
Accessing Cockpit from the Administration Portal
-
In the Administration Portal, click
and select a host. - Click Host Console.
The Cockpit login page opens in a new browser window.
10.5.25. Setting a Legacy SPICE Cipher
SPICE consoles use FIPS-compliant encryption by default, with a cipher string. The default SPICE cipher string is: kECDHE+FIPS:kDHE+FIPS:kRSA+FIPS:!eNULL:!aNULL
This string is generally sufficient. However, if you have a virtual machine with an older operating system or SPICE client, where either one or the other does not support FIPS-compliant encryption, you must use a weaker cipher string. Otherwise, a connection security error may occur if you install a new cluster or a new host in an existing cluster and try to connect to that virtual machine.
You can change the cipher string by using an Ansible playbook.
Changing the cipher string
On the Manager machine, create a file in the directory
/usr/share/ovirt-engine/playbooks
. For example:# vim /usr/share/ovirt-engine/playbooks/change-spice-cipher.yml
Enter the following in the file and save it:
name: oVirt - setup weaker SPICE encryption for old clients hosts: hostname vars: host_deploy_spice_cipher_string: 'DEFAULT:-RC4:-3DES:-DES' roles: - ovirt-host-deploy-spice-encryption
Run the file you just created:
# ansible-playbook -l hostname /usr/share/ovirt-engine/playbooks/change-spice-cipher.yml
Alternatively, you can reconfigure the host with the Ansible playbook ovirt-host-deploy
using the --extra-vars
option with the variable host_deploy_spice_cipher_string
, as follows:
# ansible-playbook -l hostname \
--extra-vars host_deploy_spice_cipher_string=”DEFAULT:-RC4:-3DES:-DES” \
/usr/share/ovirt-engine/playbooks/ovirt-host-deploy.yml