Error Message

n/a

1) To avoid these issues, the customers shall strictly avoid any Rolling Upgrades to any of the below mentioned patches in the FSS (Flexible Storage Sharing) configuration:

vm-aix-Patch-7.3.1.100 
vm-aix-Patch-7.3.1.2200 
vm-rhel6_x86_64-Patch-7.3.1.2100 
vm-rhel7_x86_64-Patch-7.3.1.200  
vm-rhel7_x86_64-Patch-7.3.1.2100 
vm-sles12_x86_64-Patch-7.3.1.2100
vm-sles11_x86_64-Patch-7.3.1.2100
vm-sol11_sparc-Patch-7.3.1.100 
vm-sol11_sparc-Patch-7.3.1.2300  

2) The customers shall avoid rolling upgrade from any of the below mentioned patches to higher releases in the FSS configuration:

vm-aix-Patch-7.3.1.100  
vm-aix-Patch-7.3.1.2200 
vm-sol11_sparc-Patch-7.3.1.100
vm-rhel6_x86_64-Patch-7.3.1.2100  
vm-rhel7_x86_64-Patch-7.3.1.200 
vm-rhel7_x86_64-Patch-7.3.1.2100
vm-sles12_x86_64-Patch-7.3.1.2100
vm-sles11_x86_64-Patch-7.3.1.2100

For example:

Avoid rolling upgrade FROM Infoscale 7.3.1 to vm-sol11_sparc-Patch-7.3.1.100
Avoid rolling upgrade from vm-sol11_sparc-Patch-7.3.1.100 TO 7.4

Currently this rolling upgrade issue is resolved on Solaris only in below patch through incident e3970129:
vm-sol11_sparc-Patch-7.3.1.2300 which is  included in the latest public patch

infoscale-sol11.4_sparc-Patch-7.3.1.100.tar.gz

Click here to download : https://downloads.infoscale.com/infoscale/REL384171/7.3.1.100?q=7.3.1.100&fileNumber=FILE597309&updateNumber=UPD261422

The fix would allow rolling upgrade from vm-sol11_sparc-Patch-7.3.1.2300 to higher releases. However it's NOT recommended to perform rolling upgrade from any lower release to vm-sol11_sparc-Patch-7.3.1.2300 in FSS configuration.

If in any doubt, please contact InfoscaleTechnical Support.

For some specific arrays, the UDID (Unique Disk Identifier) of a disk directly connected to a cluster node might not be globally unique across the cluster, but it's only locally unique to the node to which the disk is attached. That is, another disk which is connected to a different node in the cluster might have a similar UDID. For example suppose disk A has udid A on node 1 then a separate disk B will have udid A on node 2. Because of this non-uniqueness of UDID, the disk could not be properly exported in the FSS (Flexible Storage Sharing) cluster environment due to two different disks having same UDID. In order to fix this issue, while adding the disks in the JBOD category, a new option "localdisks=yes” was added as an additional parameter to the "vxddladm addjbod" command. If the "localdisks=yes" option is used then a unique hostguid is appended to the UDID of the disks. The addition of hostguid ensures that the UDID is globally unique in the CVM cluster. These changes were implemented in following Infoscale/VxVM patches through incident 3933899 (disks directly attached to the system cannot be exported in FSS environment): vm-aix-Patch-7.3.1.100,
vm-aix-Patch-7.3.1.2200,
vm-sol11_sparc-Patch-7.3.1.100,
vm-sol11_sparc-Patch-7.3.1.2300,
vm-rhel6_x86_64-Patch-7.3.1.2100,
vm-rhel7_x86_64-Patch-7.3.1.200,
vm-rhel7_x86_64-Patch-7.3.1.2100,
vm-sles12_x86_64-Patch-7.3.1.2100,
vm-sles11_x86_64-Patch-7.3.1.2100
After the fix 3933899, the length of the VxVM disk UDID is increased because the hostguid string is appended to the UDID string. If some customer performs a rolling upgrade to/from the above mentioned patches in the FSS (Flexible Storage Sharing) configuration, then it may cause inconsistent issues like system hang/panic.