1.2. Upgrading a Self-Hosted Engine from Red Hat Virtualization 4.2 to 4.3

Procedure

1. Install the Log Collection Analysis tool on the Manager machine:

   # yum install rhv-log-collector-analyzer

2. Run the tool:

   # rhv-log-collector-analyzer --live

   A detailed report is displayed.

   By default, the report is saved to a file called analyzer_report.html.

   To save the file to a specific location, use the --html flag and specify the location:

   # rhv-log-collector-analyzer --live --html=/directory/filename.html

3. You can use the ELinks text mode web browser to read the analyzer reports within the terminal. To install the ELinks browser:

   # yum install -y elinks

4. Launch ELinks and open analyzer_report.html.

   # elinks /home/user1/analyzer_report.html

   To navigate the report, use the following commands in ELinks:

   • Insert to scroll up
   • Delete to scroll down
   • PageUp to page up
   • PageDown to page down
   • Left Bracket to scroll left
   • Right Bracket to scroll right

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 global maintenance mode before proceeding:

   # hosted-engine --vm-status

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

Procedure

1. On the Manager machine, check if updated packages are available:

   # engine-upgrade-check

2. Update the setup packages:

   # yum update ovirt\*setup\* rh\*vm-setup-plugins

3. Update the Red Hat Virtualization Manager 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

   Note

   The engine-setup script is also used during the Red Hat Virtualization Manager 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.

   Important

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

4. Update the base operating system and any optional packages installed on the Manager:

   # yum update --nobest

   Important

   If you encounter a required Ansible package conflict during the update, see Cannot perform yum update on my RHV manager (ansible conflict).

   Important

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

Procedure

1. Enable the Red Hat Virtualization 4.3 repositories:

   # subscription-manager repos \
       --enable=rhel-7-server-rhv-4.3-manager-rpms \
       --enable=jb-eap-7.2-for-rhel-7-server-rpms

   All other repositories remain the same across Red Hat Virtualization releases.

2. Update the setup packages:

   # yum update ovirt\*setup\* rh\*vm-setup-plugins

3. Run engine-setup and follow the prompts to upgrade the Red Hat Virtualization Manager:

   # engine-setup

   When the script completes successfully, the following message appears:

   Execution of setup completed successfully

4. Disable the Red Hat Virtualization 4.2 repositories to ensure the system does not use any 4.2 packages:

   # subscription-manager repos \
       --disable=rhel-7-server-rhv-4.2-manager-rpms \
       --disable=jb-eap-7-for-rhel-7-server-rpms

5. Update the base operating system:

   # yum update

   Important

   If you encounter a required Ansible package conflict during the update, see Cannot perform yum update on my RHV manager (ansible conflict).

   Important

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

Procedure

1. Log in to the Manager 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 Manager virtual machine, and then the Manager automatically starts. It can take up to ten minutes for the Manager 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"}

   Note

   When the virtual machine is still booting and the Manager 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.

Procedure

1. In the Administration Portal, click Compute Clusters and select the cluster. The Upgrade status column shows if an upgrade is available for any hosts in 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 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.
5. Click Next.
6. Review the summary of the hosts and virtual machines that are affected.
7. Click Upgrade.
8. A cluster upgrade status screen displays with a progress bar showing the precentage of completion, and a list of steps in the upgrade process that have completed. You can click Go to Event Log to open the log entries for the upgrade. Closing this screen does not interrupt the upgrade process.

Procedure

1. In the Administration Portal, click Compute Clusters.
2. Select the cluster to change and click Edit.
3. On the General tab, change the Compatibility Version to the desired value.
4. Click OK. The Change Cluster Compatibility Version confirmation dialog opens.
5. Click OK to confirm.

Procedure

1. In the Administration Portal, click Compute Virtual Machines.

2. Check which virtual machines require a reboot. In the Vms: search bar, enter the following query:

   next_run_config_exists=True

   The search results show all virtual machines with pending changes.

3. Select each virtual machine and click Restart. Alternatively, if necessary you can reboot a virtual machine from within the virtual machine itself.

Procedure

1. In the Administration Portal, click Compute Data Centers.
2. Select the data center to change and click Edit.
3. Change the Compatibility Version to the desired value.
4. Click OK. The Change Data Center Compatibility Version confirmation dialog opens.
5. Click OK to confirm.

1. Log in to the Manager machine as the root user.

2. Check whether /etc/pki/ovirt-engine/openssl.conf includes the line default_md = sha256:

   # cat /etc/pki/ovirt-engine/openssl.conf

   If it still includes default_md = sha1, back up the existing configuration and change the default to sha256:

   # cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")"
   # sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.conf

3. Define the certificate that should be re-signed:

   # names="apache"

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

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

5. On the Manager, save a backup of the /etc/ovirt-engine/engine.conf.d and /etc/pki/ovirt-engine directories, and re-sign the certificates:

   # . /etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf
   # for name in $names; do
       subject="$(
           openssl \
               x509 \
               -in /etc/pki/ovirt-engine/certs/"${name}".cer \
               -noout \
               -subject \
               -nameopt compat \
           | sed \
               's;subject=\(.*\);\1;' \
       )"
      /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
           --name="${name}" \
           --password=mypass \ <1>
           --subject="${subject}" \
           --san=DNS:"${ENGINE_FQDN}" \
           --keep-key
   done

   Do not change this the password value.

6. Restart the httpd service:

   # systemctl restart httpd

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

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

8. Connect to the Administration Portal to confirm that the warning no longer appears.
9. If you previously imported a CA or https certificate into the browser, find the certificate(s), remove them from the browser, and reimport the new CA certificate. Install the certificate authority according to the instructions provided by your browser. To get the certificate authority’s certificate, navigate to http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA, replacing your-manager-fqdn with the fully qualified domain name (FQDN).

1. Log in to the Manager machine as the root user.

2. Check whether /etc/pki/ovirt-engine/openssl.conf includes the line default_md = sha256:

   # cat /etc/pki/ovirt-engine/openssl.conf

   If it still includes default_md = sha1, back up the existing configuration and change the default to sha256:

   # cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")"
   # sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.conf

3. Re-sign the CA certificate by backing it up and creating a new certificate in ca.pem.new:

   # cp -p /etc/pki/ovirt-engine/private/ca.pem /etc/pki/ovirt-engine/private/ca.pem."$(date +"%Y%m%d%H%M%S")"
   # openssl x509 -signkey /etc/pki/ovirt-engine/private/ca.pem -in /etc/pki/ovirt-engine/ca.pem -out /etc/pki/ovirt-engine/ca.pem.new -days 3650 -sha256

4. Replace the existing certificate with the new certificate:

   # mv /etc/pki/ovirt-engine/ca.pem.new /etc/pki/ovirt-engine/ca.pem

5. Define the certificates that should be re-signed:

   # names="engine apache websocket-proxy jboss imageio-proxy"

   If you replaced the Red Hat Virtualization Manager SSL Certificate after the upgrade, run the following instead:

   # names="engine websocket-proxy jboss imageio-proxy"

   For more details see Replacing the Red Hat Virtualization Manager CA Certificate in the Administration Guide.

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

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

7. On the Manager, save a backup of the /etc/ovirt-engine/engine.conf.d and /etc/pki/ovirt-engine directories, and re-sign the certificates:

   # . /etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf
   # for name in $names; do
       subject="$(
           openssl \
               x509 \
               -in /etc/pki/ovirt-engine/certs/"${name}".cer \
               -noout \
               -subject \
               -nameopt compat \
           | sed \
               's;subject=\(.*\);\1;' \
       )"
      /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
           --name="${name}" \
           --password=mypass \ <1>
           --subject="${subject}" \
           --san=DNS:"${ENGINE_FQDN}" \
           --keep-key
   done

   Do not change this the password value.

8. Restart the following services:

   # systemctl restart httpd
   # systemctl restart ovirt-engine
   # systemctl restart ovirt-websocket-proxy
   # systemctl restart ovirt-imageio

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

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

10. Connect to the Administration Portal to confirm that the warning no longer appears.
11. If you previously imported a CA or https certificate into the browser, find the certificate(s), remove them from the browser, and reimport the new CA certificate. Install the certificate authority according to the instructions provided by your browser. To get the certificate authority’s certificate, navigate to http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA, replacing your-manager-fqdn with the fully qualified domain name (FQDN).

12. Enroll the certificates on the hosts. Repeat the following procedure for each host.

    1. In the Administration Portal, click Compute Hosts.
    2. Select the host and click Management Maintenance and OK.
    3. Once the host is in maintenance mode, click Installation Enroll Certificate.
    4. Click Management Activate.