Chapter 3. Known Issues

Virtual Data Optimizer (VDO) volumes are comprised of up to 8096 slabs. The default slab size is 2GB, which limits VDO volumes to a maximum physical size of 16TB, and a maximum supported logical size of 160TB. This means that creating a VDO volume on a physical device that is larger than 16TB fails.

To work around this issue, specify a larger slab size at VDO volume creation.

When bricks are configured asymmetrically, and a logical cache volume is configured, the cache volume is attached to only one brick. This is because the current implementation of asymmetric brick configuration creates a separate volume group and thin pool for each device, so asymmetric brick configurations would require a cache volume per device. However, this would use a large number of cache devices, and is not currently possible to configure using the Web Console.

To work around this issue, first remove any cache volumes that have been applied to an asymmetric brick set.

# lvconvert --uncache volume_group/logical_cache_volume

Then, follow the instructions in Configuring a logical cache volume to create a logical cache volume manually.

During RHHI for Virtualization setup, two separate network interfaces are required to set up Red Hat Gluster Storage. After storage configuration is complete, the hosted engine is deployed and the host is added to Red Hat Virtualization as a managed host. During host deployment, the storage network is altered, and BOOTPROTO=dhcp is removed. This means that the storage network does not have IP addresses assigned automatically, and is not available after the hosted engine is deployed.

To work around this issue, add the line BOOTPROTO=dhcp to the network interface configuration file for your storage network after deployment of the hosted engine is complete.

The vdsm service makes various configuration changes after Red Hat Virtualization is first installed. One such change makes multipath entries for devices visible on RHHI for Virtualization, including local devices. This causes issues on hosts that are updated or rebooted before the RHHI for Virtualization deployment process is complete.

To work around this issue, add all devices to the multipath blacklist:

When the profiling window is opened, NFS profile statistics are queried even when a volume does not have any NFS clients or NFS access enabled. This results in the brick profile UI reporting the following error: Could not fetch brick profile stats.

To work around this issue, select a brick from the profile information window and refresh details to see profiling details for the brick.

When you attempt to configure a logical volume cache for a thickly provisioned volume using the Web Console, the deployment fails. You can manually configure a logical volume cache after deployment by adding a faster disk to your volume group using the following procedure. Note that device names are examples.

When a node reboots, including as part of upgrades or updates, subsequent runs of gluster volume status sometimes incorrectly report that bricks are not running, even when the relevant glusterfsd processes are running as expected.

To work around this issue, restart glusterd on the hyperconverged node after the node is upgraded, updated, or rebooted.

When IPv6 addresses are used to deploy Red Hat Hyperconverged Infrastructure for Virtualization, the second and third hyperconverged hosts are not automatically configured to be managed by the hosted engine virtual machine during the deployment process.

To work around this issue, manually add the second and third hosts to Red Hat Virtualization Manager when deployment is complete: Adding a host.

The ansible-based deployment process introduced in Red Hat Hyperconverged Infrastructure for Virtualization uses the dig tool to verify FQDNs. This means that when static IP addresses are used and defined in the /etc/hosts file instead of a DHCP server being used, dig cannot detect them.

To work around this issue, add gluster_features_fqdn_check: false to each host definition in the generated playbook file, like so:

hosts:
    rhhihost1.example.com:
      gluster_features_fqdn_check: false
      gluster_infra_volume_groups:
        - vgname: gluster_vg_sdb
          pvname: /dev/sdb
        - vgname: gluster_vg_sdc
          pvname: /dev/mapper/vdo_sdc

When you create a new volume using the Web Console using the Create Volume button, the value for hosts is populated from gluster peer list, and the first host is an IP address instead of an FQDN. As part of volume creation, this value is passed to an FQDN validation process, which fails with an IP address.

To work around this issue, edit the generated variable file and manually insert the FQDN instead of the IP address.

If pending heals exist or gluster quorum cannot be maintained when you attempt to upgrade an online host, the host upgrade fails with a message that indicates the host could not be moved to maintenance, but does not specify the exact cause of error.

To work around this issue, move the host into maintenance mode before attempting to upgrade.

When adding a new volume using the Expand Cluster feature in the Web Console, the new volume is added as a new cluster instead of adding a new volume to an existing cluster.

To work around this issue, peer probe the new hyperconverged hosts from hosts in the existing cluster before using Expand Cluster.

Log in to a host that is part of the cluster you wanted to expand, and run the following command for each host to be added:

# gluster peer probe <new-host-fqdn>

Then use Expand Cluster in the Web Console, using the same FQDN used with the peer probe command.

When you attempt to use Remote data sync setup to configure geo-replication for a storage domain that was created automatically during RHHI for Virtualization deployment, GetGeoRepSessionsForStorageDomainQuery throws a null pointer exception. This issue does not occur for manually created storage domains.

To work around this issue, edit the storage domain and check the Use managed gluster volume checkbox.

The installer cannot clean some kinds of metadata from existing logical volumes. This means that reinstalling a hyperconverged host fails unless the disks have been manually cleared beforehand.

To work around this issue, run the following commands to remove all data and metadata from disks attached to the physical machine.

# pvremove /dev/* --force -y
# for disk in $(ls /dev/{sd*,nv*}); do wipefs -a -f $disk; done