Do I need to make changes to my GFS/GFS2 file systems when renaming the cluster in RHEL?

Environment

• Red Hat Enterprise Linux (RHEL) 5, 6, 7 or 8 with the Resilient Storage Add On
• GFS or GFS2

Issue

• Need to change the name of a pre-existing cluster that has associated GFS or GFS2 file-system(s)

• Changing A GFS2 locktable Name

• What changes should be done to a gfs2 filesystem after changing the cluster name ?

• After changing <cluster name> attribute in /etc/cluster/cluster.conf, GFS or GFS2 file system fails to mount:

  # mount -t gfs2 /dev/clust/lv1  /mnt/lv1
  fs is for a different cluster
  error mounting lockproto lock_dlm
  

Resolution

Please note that any changes to the superblock via gfs_tool, gfs2_tool, or tunegfs2 requires that the GFS/GFS2 is not mounted on any cluster node when changes are made.

After changing the name of a cluster and restarting all cluster nodes, the lock table name on each GFS/GFS2 file system must be updated to reflect the new name.

• For GFS2 file systems on RHEL 8 or 7, use tunegfs2:

  # tunegfs2 -o locktable=RHEL8Clu:gfsfs /dev/ha_vg/ha_lv
  

  • Related issue :

    • An LVM-activate resource fails to start with error lvmlockd[XXXX]: XXXXXX prepare_lockspace_dlm vg1 mismatching cluster names sys new_clustername arg old_clustername in a Pacemaker cluster

  • Note:
    From RHEL 7 onward gfs2_tool command is replaced by tunegfs2. For more comparable commands please see :

    • 1.5. Replacement Functions for gfs2_tool in Red Hat Enterprise Linux 7

    • If the commands above fail to change the locktable name then see the following article:

      • The tunegfs2 command fails to change the name of the "Lock table" for a gfs2 filesystem

• For for GFS2 file systems on RHEL 5 or 6, use gfs2_tool:

  # gfs2_tool sb <device> table <clustername>:<label>
  # gfs2_tool sb /dev/clustervg/lv1 table mycluster:lv1
  

• For GFS file systems, use gfs_tool:

  # gfs_tool sb <device> table <clustername>:<label>
  # gfs_tool sb /dev/clustervg/lv1 table mycluster:lv1
  

Root Cause

A GFS and GFS2 file system superblock contains some information that is specific to the cluster that created, such as the cluster name. If a cluster node attempts to mount one of these file systems and discovers a name that does not match the currently running cluster's name, it will refuse to mount it.

As such, if the cluster is renamed, the lock table in the superblock must also be updated to reflect the new name. It can be updated with gfs_tool or gfs2_tool.

Diagnostic Steps

• Below messages are observed in /var/log/messages :

  Mar 20 17:06:03 node1 kernel: gfs2: GFS2 installed
  Mar 20 17:06:03 node1 kernel: gfs2: fsid=old_cluster_name:gfs_lv: Trying to join cluster "lock_dlm", "old_cluster_name:gfs_lv"
  Mar 20 17:06:03 node1 kernel: dlm: dlm cluster name 'new_cluster_name' does not match the application cluster name 'old_cluster_name'
  Mar 20 17:06:03 node1 kernel: gfs2: fsid=old_cluster_name:gfs_lv: dlm_new_lockspace error -53
  

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.