7.5. Host Tasks
7.5.1. Adding a Host 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. Use the details view to monitor the process as the host and the Manager establish a connection.
Adding a Host to the Red Hat Virtualization Manager
-
Click
. - Click New.
- Use the drop-down list to select the Data Center and Host Cluster for the new host.
- Enter the Name and the Hostname 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 Public Key field to /root/.ssh/authorized_keys on the host to use public key authentication.
Click the Advanced Parameters button to expand 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.
- Optionally configure Power Management, SPM, Console, Network Provider, and Kernel. See Section 7.5.4, “Explanation of Settings and Controls in the New Host and Edit Host Windows” for more information. Hosted Engine is used when deploying or undeploying a host for a self-hosted engine deployment.
- Click OK.
The new host displays in the list of hosts with a status of Installing
, and you can see the progress of the installation in the details view. After a brief delay the host status changes to Up.
Keep the environment up-to-date. See https://access.redhat.com/articles/2974891 for more information. Since bug fixes for known issues are frequently released, Red Hat recommends using scheduled tasks to update the hosts and the Manager.
7.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
.
7.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 User Guide.
Red Hat Virtualization 4.2 supports errata management with Red Hat Satellite 6.1.
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 11.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 more information on how to configure host registration see Configuring a Host for Registration in the Red Hat Satellite User Guide. For more information on how to register a host and install the
katello-agent
package see Registration in the Red Hat Satellite User Guide.-
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.
7.5.4. Explanation of Settings and Controls in the New Host and Edit Host Windows
7.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. |
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. |
7.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 7.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. |
7.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. |
7.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. |
7.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. |
7.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 in the Installation Guide. 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.
7.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:
|
7.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.
The
7.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.
7.5.14. 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 5.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
7.5.15. 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.
7.5.16. 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
.
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
7.5.17. 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.
7.5.18. Updating a Host Between Minor Releases
7.5.18.1. Updating the Hosts
Use the host upgrade manager to update individual hosts directly from the Red Hat Virtualization Manager.
The upgrade manager only checks hosts with a status of Up or Non-operational, but not Maintenance.
On RHVH, the update only preserves modified content in the /etc and /var directories. Modified data in other paths is overwritten during an update.
Prerequisites
- 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.
- Ensure that the cluster contains more than one host before performing an update. Do not update all hosts at the same time, as one host must remain available to perform Storage Pool Manager (SPM) tasks.
- Ensure that the cluster to which the host belongs has sufficient memory reserve for its hosts to perform maintenance. Otherwise, the virtual machine migration operation will hang and fail. You can reduce the memory usage of this operation by shutting down some or all virtual machines before updating the host.
- You cannot migrate a virtual machine using a vGPU to a different host. Virtual machines with vGPUs installed must be shut down before updating the host.
Procedure
Ensure that the correct repositories are enabled (to view a list of currently enabled repositories, type
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 . Click the Events and alerts notification icon ( ) and expand the Events section to see the result.
-
If an update is available, click
. Click
to update the host. Running virtual machines will be migrated according to their migration policy. If migration is disabled for any virtual machines, you will be prompted to shut them down.The details of the host are updated in
and the status transitions through these stages: - Maintenance
- Installing
- Reboot
Up
If any virtual machines were migrated off the host, they are now migrated back.
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.
7.5.18.2. 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.
On RHVH, the update only preserves modified content in the /etc and /var directories. Modified data in other paths is overwritten during an update.
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 updates are performed at a time when the host’s usage is relatively low.
- Ensure that the cluster contains more than one host before performing an update. Do not attempt to update all the hosts at the same time, as one host must remain available to perform Storage Pool Manager (SPM) tasks.
- Ensure that the cluster to which the host belongs 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 updating the host.
- You cannot migrate a virtual machine using a vGPU to a different host. Virtual machines with vGPUs installed 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.
7.5.19. 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
7.5.20. Customizing Hosts with Tags
You can use tags to store information about your hosts. You can then search for hosts based on tags. For more information on searches, see Searching for Hosts in the Introduction to the Administration Portal.
Customizing hosts with tags
-
Click
and select a host. -
Click
. - Select the check boxes of applicable tags.
- Click OK.
You have added extra, searchable information about your host as tags.
7.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 7.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.
7.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.
7.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 Configuring a Host for PCI Passthrough in the Installation Guide.
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.
7.5.24. Preparing Host and Guest Systems for GPU Passthrough
The Graphics Processing Unit (GPU) device from a host can be directly assigned to a virtual machine. Before this can be achieved, both the host and the virtual machine require amendments to their grub configuration files. You can edit the host grub configuration file using the Kernel command line free text entry field in the Administration Portal. Both the host machine and the virtual machine require reboot for the changes to take effect.
This procedure is relevant for hosts with either x86_64 or ppc64le architecture.
For more information on the hardware requirements for direct device assignment, see PCI Device Requirements in the Planning and Prerequisites Guide.
If the host is attached to the Manager already, ensure you place the host into maintenance mode before applying any changes.
Preparing a Host for GPU Passthrough
-
In the Administration Portal, click
. - Click the host’s name to open the details view.
-
Click the General tab, and click Hardware. Locate the GPU device vendor ID:product ID. In this example, the IDs are
10de:13ba
and10de:0fbc
. - Right-click the host and select Edit. Click the Kernel tab.
In the Kernel command line free text entry field, enter the IDs located in the previous steps.
pci-stub.ids=10de:13ba,10de:0fbc
Blacklist the corresponding drivers on the host. For example, to blacklist nVidia’s nouveau driver, next to pci-stub.ids=xxxx:xxxx, enter rdblacklist=nouveau.
pci-stub.ids=10de:13ba,10de:0fbc rdblacklist=nouveau
- Click OK.
-
Click
to commit the changes to the host. - Reboot the host after the reinstallation is complete.
To confirm the device is bound to the pci-stub
driver, run the lspci
command:
# lspci -nnk ... 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107GL [Quadro K2200] [10de:13ba] (rev a2) Subsystem: NVIDIA Corporation Device [10de:1097] Kernel driver in use: pci-stub 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:0fbc] (rev a1) Subsystem: NVIDIA Corporation Device [10de:1097] Kernel driver in use: pci-stub ...
For instructions on how to make the above changes by editing the grub configuration file manually, see Preparing Host and Guest Systems for GPU Passthrough in the 3.6 Administration Guide.
Proceed to the next procedure to configure GPU passthrough on the guest system side.
Preparing a Guest Virtual Machine for GPU Passthrough
For Linux
Only proprietary GPU drivers are supported. Black list the corresponding open source driver in the grub configuration file. For example:
$ vi /etc/default/grub ... GRUB_CMDLINE_LINUX="nofb splash=quiet console=tty0 ... rdblacklist=nouveau" ...
Locate the GPU BusID. In this example, is BusID is
00:09.0
.# lspci | grep VGA 00:09.0 VGA compatible controller: NVIDIA Corporation GK106GL [Quadro K4000] (rev a1)
Edit the /etc/X11/xorg.conf file and append the following content:
Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BusID "PCI:0:9:0" EndSection
- Restart the virtual machine.
For Windows
- Download and install the corresponding drivers for the device. For example, for Nvidia drivers, go to NVIDIA Driver Downloads.
- Restart the virtual machine.
The host GPU can now be directly assigned to the prepared virtual machine. For more information on assigning host devices to virtual machines, see Host Devices in the Virtual Machine Management Guide.
7.5.25. 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 user 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.
7.5.26. 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