此内容没有您所选择的语言版本。

Making open source more inclusive


Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

1. Overview of upgrading RHHI for Virtualization

Upgrading involves moving from one version of a product to a newer major release of the same product. This section shows you how to upgrade to Red Hat Hyperconverged Infrastructure for Virtualization 1.7 from version 1.5 or 1.6.

From a component standpoint, this involves the following:

  • Upgrading the Hosted Engine virtual machine to Red Hat Virtualization Manager version 4.3.8.
  • Upgrading the physical hosts to Red Hat Virtualization 4.3.8.

2. Major changes in version 1.7

Be aware of the following differences between Red Hat Hyperconverged Infrastructure for Virtualization 1.7 and previous versions:

Underlying software updates

The software underlying Red Hat Hyperconverged Infrastructure for Virtualization has been updated to the following:

  • Red Hat Gluster Storage 3.5
  • Red Hat Virtualization 4.3.8
Support for 4 KB block size
Storage domains hosted on Gluster volumes now support disks with a block size of 4 KB.
4 KB block size on VDO devices

Previously, VDO devices emulated a 512 byte block size by default. As of Red Hat Hyperconverged Inrastructure for Virtualization 1.7, newly created VDO devices use a block size of 4 KB.

Important

Bricks in the same Gluster volume must share the same block size. Do not place the bricks of a Gluster volume across both an older VDO volume with a block size of 512 bytes and a new VDO volume with a block size of 4 KB.

Specify nodes for volume creation during automated deploy
Previously, during an automated deployment, volumes were created across all nodes. In deployments larger than three nodes, you can now specify which nodes you want volumes to be deployed across during an automated deployment.

3.1. Upgrade workflow

Red Hat Hyperconverged Infrastructure for Virtualization is a software solution comprised of several different components. Upgrade the components in the following order to minimize disruption to your deployment:

3.2. Preparing to upgrade

3.2.1. Update to the latest version of the previous release

If you are upgrading from Red Hat Hyperconverged Infrastructure for Virtualization 1.5, ensure that you are using the latest version (4.2.8) of Red Hat Virtualization Manager 4.2 on the hosted engine virtual machine, and the latest version of Red Hat Virtualization 4.2 on the hosted engine node.

See the Red Hat Virtualization Self-Hosted Engine Guide for the Red Hat Virtualization 4.2 update process.

Important

Do not proceed with the following prerequisites until you have updated to the latest version of Red Hat Virtualization 4.2.

3.2.2. Update subscriptions

You can check which repositories a machine has access to by running the following command as the root user:

# subscription-manager repos --list-enabled
  • Verify that the Hosted Engine virtual machine is subscribed to the following repositories:

    • rhel-7-server-rpms
    • rhel-7-server-supplementary-rpms
    • rhel-7-server-rhv-4.3-manager-rpms
    • rhel-7-server-rhv-4-manager-tools-rpms
    • rhel-7-server-ansible-2.9-rpms
    • jb-eap-7.2-for-rhel-7-server-rpms
  • Verify that the Hosted Engine virtual machine is not subscribed to previous versions of the required repositories.

    • The jb-eap-7.2-for-rhel-7-server-rpms repository replaces the previously used jb-eap-7-for-rhel-7-server-rpms repository.
    • If you are upgrading from Red Hat Hyperconverged Infrastructure for Virtualization 1.5, rhel-7-server-rhv-4.3-manager-rpms replaces the previously used rhel-7-server-rhv-4.2-manager-rpms repository.

Subscribe a machine to a repository by running the following command on that machine:

# subscription-manager repos --enable=<repository>
  • Click the Tasks tab at the bottom right of the Manager. Ensure that there are no ongoing tasks related to Data Synchronization. If data synchronization tasks are present, wait until they are complete before beginning the update.
  • Stop all geo-replication sessions so that synchronization will not occur during the update. Click the Geo-replication subtab and select the session that you want to stop, then click Stop.

    Alternatively, run the following command to stop a geo-replication session:

    # gluster volume geo-replication <MASTER_VOL> <SLAVE_HOST>::<SLAVE_VOL> stop

3.3.1. Upgrading the Hosted Engine virtual machine

  1. Place the cluster into Global Maintenance mode

    1. Log in to the Web Console.
    2. Click Virtualization Hosted Engine.
    3. Click Put this cluster into global maintenance.
  2. Upgrade Red Hat Virtualization Manager.

    1. Log in to the Hosted Engine virtual machine.
    2. Upgrade the setup packages:

      # yum update ovirt-engine\*setup\* rh\*vm-setup-plugin
    3. Run engine-setup and follow the prompts to upgrade the Manager.

      This process can take a while and cannot be aborted, so Red Hat recommends running it inside a screen session. See How to use the screen command for more information about this function.

    4. Upgrade all other packages.

      # yum update
    5. Reboot the Hosted Engine virtual machine to ensure all updates are applied.

      # reboot
  3. Restart the Hosted Engine virtual machine.

    1. Log in to any hyperconverged host.
    2. Start the Hosted Engine virtual machine.

      # hosted-engine --vm-start
    3. Verify the status of the Hosted Engine virtual machine.

      # hosted-engine --vm-status
  4. Remove the cluster from Global Maintenance mode.

    1. Log in to the Web Console.
    2. Click Virtualization Hosted Engine.
    3. Click Remove this cluster from global maintenance.

3.3.2. Upgrading the hyperconverged hosts

Important

If you are upgrading a host from Red Hat Virtualization 4.2.7 or 4.2.7-1, ensure that the hosted engine virtual machine is not running on that host during the upgrade process. This is related to a bug introduced in Red Hat Enterprise Linux 7.6, BZ#1641798, which affects these versions of Red Hat Virtualization.

To work around this issue, stop the hosted engine virtual machine before upgrading a host, and start it on another host.

[root@host1] # hosted-engine --vm-shutdown
[root@host2] # hosted-engine --vm-start
  1. Upgrade one host at a time

    Perform the following steps to upgrade each hyperconverged host.

    1. Disable self-healing on each hosted volume.

      Run the following commands to disable self-healing for each volume on this hyperconverged host.

      # gluster volume set <volname> cluster.self-heal-daemon off

      For example:

      # gluster volume set engine cluster.self-heal-daemon off
      # gluster volume set vmstore cluster.self-heal-daemon off
      # gluster volume set data cluster.self-heal-daemon off
    2. Upgrade the hyperconverged host.

      1. In the Manager, click Compute Hosts and select a node.
      2. Click Installation Upgrade.
      3. Click OK to confirm the upgrade.

        Wait for the upgrade to complete, and for the host to become available again.

    3. Enable self-healing on each hosted volume.

      Run the following commands to enable self-healing for each volume on this hyperconverged host.

      # gluster volume set <volname> cluster.self-heal-daemon on

      For example:

      # gluster volume set engine cluster.self-heal-daemon on
      # gluster volume set vmstore cluster.self-heal-daemon on
      # gluster volume set data cluster.self-heal-daemon on
    4. Verify self-healing is complete before upgrading the next host.

      1. Click the name of the host.
      2. Click the Bricks tab.
      3. Verify that the Self-Heal Info column of all bricks is listed as OK before upgrading the next host.

        If self-heal does not complete, there could be a Gluster file ID (GFID) mismatch. See the Self-heal does not complete section in Maintaining Red Hat Hyperconverged Infrastructure for Virtualization for assistance resolving this issue.

  2. Update cluster compatibility

    When all hosts are upgraded, update cluster compatibility setting.

    1. In the Manager, click Cluster and select the cluster (Default).
    2. Click Edit.
    3. Update the value of Cluster compatibility to 4.3 and save.
  3. Update cluster operating version

    When all hosts are upgraded, run the following command on any host to update the operating version of all volumes in the cluster.

    # gluster volume set all cluster.op-version 70200
    1. Restart all virtual machines

      This ensures that the new cluster compatibility setting takes effect.

      1. Click Compute Virtual Machines and select a running virtual machine.
      2. Click Reboot.
      3. Click OK in the Reboot Virtual Machine(s) confirmation window.

        The Status of the virtual machine changes to Reboot In Progress before returning to Up.

Important

Disable the gluster volume option cluster.lookup-optimize on all the gluster volumes after the upgrade.

# for volume in `gluster volume list`; do gluster volume set $volume cluster.lookup-optimize off; done

Troubleshooting

  • If upgrading a hyperconverged host fails because of a conflict with the rhvm-appliance package, log in to the hyperconverged host and follow the steps in RHV: RHV-H Upgrade failed before continuing.

4. Post-upgrade tasks

4.1. Migrating to new storage after an upgrade

As of RHHI for Virtualization 1.7, storage that uses a 4 KB block size is supported. However, the block size of an existing device cannot be changed, and devices that comprise a Gluster volume must all share the same block size.

Therefore to take advantage of the new 4 KB block size support you must create a new storage domain and migrate your data to it.

To do so, you must:

  1. Connect storage devices with 4 KB block size to the machines you intend to use as hosts for the new storage domain.
  2. Create a new volume using devices with a 4 KB block size.
  3. Create a new storage domain.
  4. Migrate data to the new storage domain.

Follow these instructions to use the Web Console to create a new Red Hat Gluster Storage volume using raw disks that are available on hyperconverged hosts in your cluster.

Prerequisites

  • Verify that the raw disk drives you plan to use for the new volume are visible under the Drives section of the Storage Dashboard, and do not have any file systems listed on their Drive Overview page.

Procedure

  1. Log in to the Web Console.
  2. Click Virtualization Hosted Engine and then click Manage Gluster.
  3. Click Create Volume. The Create Volume window opens.

    1. On the Hosts tab, select three different hyperconverged hosts with unused disks and click Next.

      The Hosts tab of the Create Volume window

    2. On the Volumes tab, specify the details of the volume you want to create and click Next.

      The Volumes tab of the Create Volume window

    3. On the Bricks tab, specify the details of the disks to be used to create the volume and click Next.

      The Bricks tab of the Create Volume window

    4. On the Review tab, check the generated configuration file for any incorrect information. When you are satisfied, click Deploy.

      The Success message after correct creation of a new volume

      Successfully created volume is displayed when deployment completes successfully.

4.1.2. Creating a new storage domain

Prerequisites

Procedure

  1. In the Administration Portal, click the Storage tab and then click New Domain.
  2. Ensure that the new storage domain is in the same data center as the existing storage domain.
  3. Provide a Name for the domain, for example, vmstore2.
  4. Set the Domain function to Data.
  5. Set the Storage Type to GlusterFS.
  6. Check the Use managed gluster volume option.
  7. Set the Gluster dropdown to the new volume.
  8. Click OK.

4.1.3. Migrating data to a different storage domain

Prerequisites

  • A storage domain with sufficient free space for the contents that you want to migrate.

Procedure

  1. In the Administration Portal, click Storage > Domains and click the name of the old storage domain.
  2. Click the Disks tab.
  3. Select the disks that you want to move and click Move.
  4. From the Target list, select the storage domain to which the disks will move.
  5. Optionally, from the Disk Profile list, select a profile.
  6. Click OK.

    The virtual disks are moved to the target storage domain. During the move procedure, the Status column displays Locked and a progress bar indicating the progress of the move operation.

The procedure to update Red Hat Virtualization Manager ( RHVM ) and Red Hat Virtualization host involves the following steps:

Procedure

  1. Update the Red Hat Virtualization Manager ( RHVM )
  2. Update the Hosted Engine Virtual Machine ( HE ) for any updates
  3. Update the Red Hat Virtualization Host (RHVH) one after the other

    Follow the steps from Upgrading to Red Hat Hyperconverged Infrastructure for Virtualization 1.7 to update to the latest Red Hat Hyperconverged Infrastructure for Virtualization 1.7.

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部