2.7. Upgrading RHVH while preserving Gluster storage

Environments with Gluster as storage can take a backup of Gluster storage and be restored after the RHVH upgrade. Try to keep workloads on all virtual machines using Gluster storage as light as possible to shorten the time required to upgrade. If there are highly write-intensive workloads, expect more time to restore.


  • If there are geo-replication schedules on the storage domains, remove those schedules to avoid upgrade conflicts.
  • No geo-replication sync are currently running.
  • Additional disk space of 100 GB is required on 3 hosts for creating a new volume for the new RHVH 4.4 Manager deployment.
  • All data centers and clusters in the environment must have a cluster compatibility level of 4.3 before you start the procedure.


  • Network-Bound Disk Encryption (NBDE) is supported only with new deployments with Red Hat Virtualization 4.4. This feature cannot be enabled during the upgrade.


  1. Create a new Gluster volume for RHVH 4.4 Manager deployment.

    1. Create a new brick on each host for the new RHVH 4.4 self-hosted engine virtual machine(VM).
    2. If you have a spare disk in the setup, follow the document Create Volume from the web console.
    3. If there is enough space for a new Manager 100GB brick in the existing Volume Group(VG), it can be used as a new Manager Logical Volume (LV).

      Run the following commands on all the hosts, unless specified otherwise explicitly:

    4. Check the free size of the Volume Group (VG).

      # vgdisplay <VG_NAME> | grep -i free
    5. Create one more Logical Volume in this VG.

      # lvcreate -n gluster_lv_newengine -L 100G <EXISTING_VG>
    6. Format the new Logical Volume (LV) as XFS.

      # mkfs.xfs  <LV_NAME>
    7. Create the mount point for the new brick.

      # mkdir /gluster_bricks/newengine
    8. Create an entry corresponding to the newly created filesystem in /etc/fstab and mount the filesystem.
    9. Set the SELinux Labels on the brick mount points.

      # semanage fcontext -a -t glusterd_brick_t /gluster_bricks/newengine
       restorecon -Rv /gluster_bricks/newengine
    10. Create a new gluster volume by executing the gluster command on one of the hosts in the cluster:

      # gluster volume create newengine replica 3 host1:/gluster_bricks/newengine/newengine host2:/gluster_bricks/newengine/newengine host3:/gluster_bricks/newengine/newengine
    11. Set the required volume options on the newly created volume. Run the following commands on one of the hosts in the cluster:

      # gluster volume set newengine group virt
       gluster volume set newengine network.ping-timeout 30
       gluster volume set newengine cluster.granular-entry-heal enable
       gluster volume set newengine network.remote-dio off
       gluster volume set newengine performance.strict-o-direct on
       gluster volume set newengine storage.owner-uid 36
       gluster volume set newengine storage.owner-gid 36
    12. Start the newly created Gluster volume. Run the following command on one of the hosts in the cluster.

      # gluster volume start newengine
  2. Backup the Gluster configuration on all RHVH 4.3 nodes using the backup playbook.

    1. The backup playbook is available with the latest version of RHVH 4.3. If this playbook is not available, create a playbook and inventory file:



          backup_dir: /archive
          nbde_setup: false
          upgrade: true
    2. Edit the backup inventory file with correct details.

        Common variables
        backup_dir ->  Absolute path to directory that contains the extracted contents of the backup archive
        nbde_setup -> Set to ‘false’ as the Red Hat Virtualization 4.3 setup doesn’t support NBDE
        upgrade -> Default value ‘true’ . This value will make no effect with backup
    3. Switch to the directory and execute the playbook.

      ansible-playbook -i archive_config_inventory.yml archive_config.yml --tags backupfiles
    4. The generated backup configuration tar file is generated under /root with the name RHVH-<HOSTNAME>-backup.tar.gz. On all the hosts, copy the backup configuration tar file to the backup host.
  3. Using the Manager Administration Portal, migrate the VMs running on the first host to other hosts in the cluster.
  4. Backup Manager configurations.

    # engine-backup --mode=backup --scope=all --file=<backup-file.tar.gz> --log=<logfile>

    Before creating a backup, do the following:

    • Enable Global Maintenance for the self-hosted engine(SHE).
    • Log in to the Manager VM using SSH and stop the ovirt-engine service.
    • Copy the backup file from the self-hosted engine VM to the remote host.
    • Shut down the Manager.
  5. Check for any pending self-heal tasks on all the replica 3 volumes. Wait for the heal to be completed.
  6. Run the following command on one of the hosts:

    # gluster volume heal <volume> info summary
  7. Stop the glusterfs brick process and unmount all the bricks on the first host to maintain file system consistency. Run the following on the first host:

    # pkill glusterfsd; pkill glusterfs
    # systemctl stop glusterd
    # umount /gluster_bricks/*
  8. Reinstall the host with RHVH 4.4 ISO, only formatting the OS disk.


    Make sure that the installation does not format the other disks, as bricks are created on top of those disks.

  9. Once the node is up following the RHVH 4.4 installation reboot, subscribe to RHVH 4.4 repos as outlined in the Installation Guide, or install the downloaded RHVH 4.4 appliance.

    # yum install <appliance>
  10. Blacklist the devices used for Gluster bricks.

    1. Create the new SSH private and public key pairs.
    2. Establish SSH public key authentication ( passwordless SSH ) to the same host, using frontend and backend network FQDN.
    3. Create the inventory file:



               - sda
               - sdb
    4. Run the playbook

      ansible-playbook -i blacklist_inventory.yml /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/tasks/gluster_deployment.yml --tags blacklistdevices*
  11. Copy the Manager backup and host config tar files from the backup host to the newly installed host and untar the content using scp.
  12. Restore the Gluster configuration files.

    1. Extract the contents of the Gluster configuration files

       # mkdir /archive
       # tar -xvf /root/ovirt-host-host1.example.com.tar.gz -C /archive/
    2. Edit the inventory file to perform restoration of the configuration files. The Inventory file is available at /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/archive_config_inventory.yml

      Example playbook content:

       	backup_dir: /archive
       	nbde_setup: false
       	upgrade: true
      Use only one host under ‘hosts’ section of restoration playbook.
    3. Execute the playbook to restore configuration files

      ansible-playbook -i archive_config_inventory.yml archive_config.yml --tags restorefiles
  13. Perform Manager deployment with the option --restore-from-file pointing to the backed-up archive from the Manager. This Manager deployment can be done interactively using the hosted-engine --deploy command, providing the storage corresponds to the newly created Manager volume. The same can also be done using ovirt-ansible-hosted-engine-setup in an automated procedure. The following procedure is an automated method for deploying a HostedEngine VM using the backup:

    1. Create a playbook for HostedEngine deployment in the newly installed host:


      - name: Deploy oVirt hosted engine
        hosts: localhost
          - role: ovirt.hosted_engine_setup
    2. Update the HostedEngine related information using the template file:



      # cat /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/he_gluster_vars.json
        "he_appliance_password": "<password>",
        "he_admin_password": "<password>",
        "he_domain_type": "glusterfs",
        "he_fqdn": "<hostedengine.example.com>",
        "he_vm_mac_addr": "<00:18:15:20:59:01>",
        "he_default_gateway": "<>",
        "he_mgmt_network": "ovirtmgmt",
        "he_storage_domain_name": "HostedEngine",
        "he_storage_domain_path": "</newengine>",
        "he_storage_domain_addr": "<host1.example.com>",
        "he_mount_options": "backup-volfile-servers=<host2.example.com>:<host3.example.com>",
        "he_bridge_if": "<eth0>",
        "he_enable_hc_gluster_service": true,
        "he_mem_size_MB": "16384",
        "he_cluster": "Default",
        "he_restore_from_file": "/root/engine-backup.tar.gz",
        "he_vcpus": 4
      • In the above he_gluster_vars.json, There are 2 important values: “he_restore_from_file” and “he_storage_domain_path”. The first option “he_restore_from_file” should point to the absolute file name of the Manager backup archive copied to the local machine. The second option “he_storage_domain_path” should refer to the newly created Gluster volume.
      • Also note that the previous version of RHVH Version running inside the Manager VM is down and that will be discarded. MAC Address and FQDN corresponding to the older Manager VM can be reused for the new Manager as well.
    3. For static Manager network configuration, add more options as listed below:

        “he_vm_ip_addr”:  “<engine VM ip address>”
        “he_vm_ip_prefix”:  “<engine VM ip prefix>”
        “he_dns_addr”:  “<engine VM DNS server>”
        “he_default_gateway”:  “<engine VM default gateway>”

      If there is no specific DNS available, try to include 2 more options: “he_vm_etc_hosts”: true and “he_network_test”: “ping”

    4. Run the playbook to deploy HostedEngine Deployment.

      # cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment
      ansible-playbook he.yml --extra-vars='@he_gluster_vars.json'
    5. Wait for the self-hosted engine deployment to complete.


      If there are any failures during self-hosted engine deployment, find the problem looking at the log messages under /var/log/ovirt-hosted-engine-setup, fix the problem. Clean the failed self-hosted engine deployment using the command ovirt-hosted-engine-cleanup and rerun the deployment.

  14. Log in to the RHVH 4.4 Administration Portal on the newly installed Red Hat Virtualization manager. Make sure all the hosts are in the ‘up’ state, and wait for the self-heal on the Gluster volumes to be completed.
  15. Upgrade the next host

    1. Move the next host (ideally, the next one in order), to Maintenance mode from the Administration Portal. Stop the Gluster service while moving this host to Maintenance mode.
    2. From the command line of the host, unmount Gluster bricks

      # umount /gluster_bricks/*
    3. Reinstall this host with RHVH 4.4.


      Make sure that the installation does not format the other disks, as bricks are created on top of those disks.

    4. If multipath configuration is not available on the newly installed host, blacklist the Gluster devices. The inventory file is already created in the first host as part of the step Blacklist the devices used for Gluster bricks.

      1. Set up SSH public key authentication from the first host to the newly installed host.
      2. Update the inventory with the new host name.
      3. Execute the playbook.
    5. Copy the Gluster configuration tar files from the backup host to the newly installed host and untar the content.
    6. Restore Gluster configuration on the newly installed host by executing the playbook as described in the step Restoring the Gluster configurations files on this host.


      Edit the playbook on the newly installed host and execute it as described in the step Perform manager deployment with the option --restore-from-file…​. Do not change hostname and execute on the same host.

    7. Reinstall the host in RHVH Administration Portal Copy the authorized key from the first deployed host in RHVH 4.4

      # scp root@host1.example.com:/root/.ssh/authorized_keys /root/.ssh/
      1. In the Administration Portal, The host will be in ‘Maintenance’. Go to ComputeHostsInstallationReinstall.
      2. In the New Host dialog box HostedEngine tab, and select the deploy self-hosted engine deployment action.
      3. Wait for the host to reach Up status.
    8. Make sure that there are no errors in the volumes related to GFID mismatch. If there are any errors, resolve them.

      grep -i ‘gfid mismatch’ /var/log/glusterfs/*
  16. Repeat the step Upgrade the next host for all the RHVH in the cluster.
  17. (optional) If a separate Gluster logical network exists in the cluster, attach the Gluster logical network to the required interface on each host.
  18. Remove the old Manager storage domain. Identify the old Manager storage domain by the name hosted_storage with no gold star next to it, listed under StorageDomains.

    1. Go to the StorageDomainshosted_storageData center tab, and select Maintenance.
    2. Wait for the storage domain to move into Maintenance mode.
    3. Once the storage domain moves into Maintenance mode, click Detach, the storage domain will move to unattached.
    4. Select the unattached storage domain, click Remove, and confirm OK.
  19. Stop and remove the old Manager volume.

    1. Go to StorageVolumes, and select the old Manager volume. Click Stop, and confirm OK.
    2. Select the same volume, click Remove, and confirm OK.
  20. Update the cluster compatibility version.

    1. Go to ComputeClusters and select the cluster Default, click Edit, update the Compatibility Version to 4.4 and click OK.


      There will be a warning for changing compatibility version, which requires VMs on the cluster to be restarted. Click OKto confirm.

  21. There are new Gluster volume options available with RHVH 4.4, apply those volume options on all the volumes. Execute the following on one of the nodes in the cluster:

    # for vol in gluster volume list; do gluster volume set $vol group virt; done
  22. Remove the archives and extracted the contents of the backup configuration files on all nodes.

Creating an additional Gluster volume using the Web Console

  1. Log in to the Manager web console.
  2. Go to VirtualizationHosted Engine and click Manage Gluster.
  3. Click Create Volume. In the Create Volume window, do the following:

    1. In the Hosts tab, select three different ovirt-ng-nodes with unused disks and click Next.
    2. In the Volumes tab, specify the details of the volume you want to create and click Next.
    3. In the Bricks tab, specify the details of the disks to be used to create the volume and click Next.
    4. In the Review tab, check the generated configuration file for any incorrect information. When you are satisfied, click Deploy.

You can now update the cluster compatibility version.