To update from your current version of 4.4 to the latest version of 4.4, update the Engine and then update the hosts.

To update a standalone Engine, follow the standard procedure for minor updates:

1. Updating the oVirt Engine

Updates to the oVirt Engine are released through the Content Delivery Network.

Procedure
  1. Log in to the Engine machine.

  2. Check if updated packages are available:

    # engine-upgrade-check
  3. Update the setup packages:

    # yum update ovirt\*setup\*
  4. Update the oVirt Engine with the engine-setup script. The engine-setup script prompts you with some configuration questions, then stops the ovirt-engine service, downloads and installs the updated packages, backs up and updates the database, performs post-installation configuration, and starts the ovirt-engine service.

    # engine-setup

    When the script completes successfully, the following message appears:

    Execution of setup completed successfully

    The engine-setup script is also used during the oVirt Engine installation process, and it stores the configuration values supplied. During an update, the stored values are displayed when previewing the configuration, and might not be up to date if engine-config was used to update configuration after installation. For example, if engine-config was used to update SANWipeAfterDelete to true after installation, engine-setup will output "Default SAN wipe after delete: False" in the configuration preview. However, the updated values will not be overwritten by engine-setup.

    The update process might take some time. Do not stop the process before it completes.

  5. Update the base operating system and any optional packages installed on the Engine:

    # yum update

    If any kernel packages were updated, reboot the machine to complete the update.

2. Updating a Self-Hosted Engine

To update a self-hosted engine from your current version to the latest version, you must place the environment in global maintenance mode and then follow the standard procedure for updating between minor versions.

Enabling Global Maintenance Mode

You must place the self-hosted engine environment in global maintenance mode before performing any setup or upgrade tasks on the Engine virtual machine.

Procedure
  1. Log in to one of the self-hosted engine nodes and enable global maintenance mode:

    # hosted-engine --set-maintenance --mode=global
  2. Confirm that the environment is in maintenance mode before proceeding:

    # hosted-engine --vm-status

    You should see a message indicating that the cluster is in maintenance mode.

Updating the oVirt Engine

Updates to the oVirt Engine are released through the Content Delivery Network.

Procedure
  1. Log in to the Engine virtual machine.

  2. Log in to the Engine machine.

  3. Check if updated packages are available:

    # engine-upgrade-check
  4. Update the setup packages:

    # yum update ovirt\*setup\*
  5. Update the oVirt Engine with the engine-setup script. The engine-setup script prompts you with some configuration questions, then stops the ovirt-engine service, downloads and installs the updated packages, backs up and updates the database, performs post-installation configuration, and starts the ovirt-engine service.

    # engine-setup

    When the script completes successfully, the following message appears:

    Execution of setup completed successfully

    The engine-setup script is also used during the oVirt Engine installation process, and it stores the configuration values supplied. During an update, the stored values are displayed when previewing the configuration, and might not be up to date if engine-config was used to update configuration after installation. For example, if engine-config was used to update SANWipeAfterDelete to true after installation, engine-setup will output "Default SAN wipe after delete: False" in the configuration preview. However, the updated values will not be overwritten by engine-setup.

    The update process might take some time. Do not stop the process before it completes.

  6. Update the base operating system and any optional packages installed on the Engine:

    # yum update

    If any kernel packages were updated:

    1. Disable global maintenance mode

    2. Reboot the machine to complete the update.

Related Information

Disabling Global Maintenance Mode

Disabling Global Maintenance Mode

Procedure
  1. Log in to the Engine virtual machine and shut it down.

  2. Log in to one of the self-hosted engine nodes and disable global maintenance mode:

    # hosted-engine --set-maintenance --mode=none

    When you exit global maintenance mode, ovirt-ha-agent starts the Engine virtual machine, and then the Engine automatically starts. It can take up to ten minutes for the Engine to start.

  3. Confirm that the environment is running:

    # hosted-engine --vm-status

    The listed information includes Engine Status. The value for Engine status should be:

    {"health": "good", "vm": "up", "detail": "Up"}

    When the virtual machine is still booting and the Engine hasn’t started yet, the Engine status is:

    {"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}

    If this happens, wait a few minutes and try again.

3. 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 oVirt. 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.

Update one cluster at a time.

Limitations
  • On oVirt Node, the update only preserves modified content in the /etc and /var directories. Modified data in other paths is overwritten during an update.

  • If the cluster has migration enabled, virtual machines are automatically migrated to another host in the cluster.

  • In a self-hosted engine environment, the Engine 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
  1. In the Administration Portal, click Compute  Clusters and select the cluster.

  2. Click Upgrade.

  3. Select the hosts to update, then click Next.

  4. 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 Engine 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.

  5. Click Next.

  6. Review the summary of the hosts and virtual machines that will be affected.

  7. Click Upgrade.

You can track the progress of host updates in the Compute  Hosts view, and in the Events section of the Notification Drawer (EventsIcon).

You can track the progress of individual virtual machine migrations in the Status column of the Compute  Virtual Machines view. In large environments, you may need to filter the results to show a particular group of virtual machines.

You can also update hosts individually:

4. 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 oVirt Node, the update only preserves modified content in the /etc and /var directories. Modified data in other paths is overwritten during an update.

  • If the cluster has migration enabled, 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 Engine 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
  1. Ensure that the correct repositories are enabled. To view a list of currently enabled repositories, run yum repolist.

  2. In the Administration Portal, click Compute  Hosts and select the host to be updated.

  3. Click Installation  Check for Upgrade and click OK.

    Open the Notification Drawer (EventsIcon) and expand the Events section to see the result.

  4. If an update is available, click Installation  Upgrade.

  5. Click OK 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 Compute  Hosts and the status transitions through these stages:

    Maintenance > Installing > Reboot > Up

    If the update fails, the host’s status changes to Install Failed. From Install Failed you can click Installation  Upgrade again.

Repeat this procedure for each host in the oVirt environment.

You should update the hosts from the Administration Portal. However, you can update the hosts using yum update instead:

5. 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 oVirt Node, the update only preserves modified content in the /etc and /var directories. Modified data in other paths is overwritten during an update.

  • If the cluster has migration enabled, 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 Engine 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
  1. Ensure the correct repositories are enabled. You can check which repositories are currently enabled by running yum repolist.

  2. In the Administration Portal, click Compute  Hosts and select the host to be updated.

  3. Click Management  Maintenance.

  4. Update the host:

    # yum update
  5. Reboot the host to ensure all updates are correctly applied.

    Check the imgbased logs to see if any additional package updates have failed for a oVirt Node. 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 oVirt environment.