Solaris Cluster 3.x Syncing a VxVM Diskgroup may Affect Another VxVM Diskgroup
Last updated on FEBRUARY 22, 2017
Applies to:Solaris Cluster - Version 3.0 to 3.3 U2 [Release 3.0 to 3.3]
Solaris Cluster Geographic Edition - Version 3.1 to 3.3 U2 [Release 3.1 to 3.3]
Oracle Solaris on SPARC (64-bit)
Oracle Solaris on x86-64 (64-bit)
This document describe the interactions between VxVM diskgroup and Solaris Cluster device service. It should provide a clear picture how the VxVM disk group will be synced with the device tree and the cluster CCR (Cluster Configuration Repository).
Let's assume you have two diskgroups datadg and oradg.
You have made some changes to oradg (e.g. created a new volume, or changed permissions of volume) and then run
SC 3.x: # scconf -c -D name=oradg,sync
SC 3.2 and above: # cldg sync oradg
The changes of the diskgroup oradg are now in sync with the cluster CCR
But if you do changes to another disk group in this example datadg before doing the 'cldg sync oradg' the following issues can occur:
If you have previously renamed /dev/vx/dsk/datadg/vol to /dev/vx/dsk/datadg/vol2 via "vxedit rename" and you have NOT run "cldg sync datadg" but you now run "cldg sync oradg", then the following is observed in /var/adm/messages:
Cluster.CCR: [ID 869698 daemon.warning] scvxvmlg warning - found no matching volume for device node /global/.devices/node@1/dev/vx/rdsk/datadg/vol, removing it@
Cluster.CCR: [ID 209540 daemon.warning] scvxvmlg warning - /global/.devices/node@1/dev/vx/dsk/datadg/vol does not exist, creating it
Cluster.CCR: [ID 209540 daemon.warning] scvxvmlg warning - /global/.devices/node@1/dev/vx/rdsk/ariel-dg/vol does not exist, creating it
This means that some device links of datadg in /dev/vx will be removed but the volume vol2 is still available in VxVM configuration. And if you now run "cldg sync datadg" then the following is observed in /var/adm/messages:
Cluster.CCR: [ID 209540 daemon.warning] scvxvmlg warning - /global/.devices/node@1/dev/vx/rdsk/datadg/vol2 does not exist, creating it
Additionally the following lines can came up when there are problems in the device tree. See Alert 1019694.1 for details.
Cluster.CCR: [ID 996230 daemon.warning] scvxvmlg error - mknod(/global/.devices/node@1/dev/vx/rdsk/datadg/vol2) failed
For more details see below "EXAMPLE A of volume rename and behavior of cldg sync command"
If you have previously changed owner and/or group and/or permissions on special file say /dev/vx/dsk/datadg/vol2 and you have NOT run "cldg sync datadg" but you now run "cldg sync oradg" THEN you get NO ERRORS in /var/adm/messages but owner and/or group and/or permissions are restored to the previous settings in /dev/vx.
If you have previously manipulated some volumes in a disk group datadg, such that they are destroyed and recreated in different order there is no guarantee that same (name, minor) combination will be used as before so if you have NOT run "cldg sync datadg" at manipulation time but you run it now "cldg sync oradg" for another disk group THEN the old (name <---> minor) mapping will be restored in the /dev/vx tree while the new (name <---> minor) mapping is stored inside the private region.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms