After upgrade to 5.1SP1 or greater diskgroup with luns greater than 1TB may fail to import

Description

Error Message

During this migration the luns that are greater than 1TB will get an

EFI/GPT label

vxdisk list will display

"cdsdisk: - - online invalid"

Any attempt to import the diskgroup will fail with "no valid configuration copy"

Cause

Symantec code did not support luns greater than 1Terabyte as cdsdisk format but code did not prevent customers from being able to do so. Symantec did not put code to prevent this from happening until 5.0MP3RP4.

The reason for this limitation was due to a limitation in the OS when using an SMI label(vtoc). The maximum allowable size was 1 Terabyte. All OS's, except for Solaris and Linux, do not rely on SMI labels to determine lun capacity. HP and AIX use scsi mode sense data to determine Lun Capacity. Linux maximum size supported with an SMI label is 2 Terabytes. Luns greater than 1TB require an EFI/GPT. Symantec attempted to make the transition from SMI labels to EFI/GPT labels seamless during the upgrade to 5.1SP1. This migration would sometime fail causing the diskgroup to not be importable.

In 5.1SP1RP2 Symantec decided to remove the automatic migration functionality from SMI to EFI/GPT. In order to get to 5.1SP1RP2 or greater you must first install 5.1SP1. Using the CPI install vxconfigd will automatically start vxconfigd after completing the upgrade possibly leaving the diskgroup un-importable and corrupted.In pre VxVM 5.0MP4 initialization of device did not check for 16^bit maximum limitation. VxVM cdsdisk format is a cross data format that has to ably by all OS ie {HP -AIX- LIN- Sol } due to this restriction Solaris SUN Label max size is 1TB until solaris 10 update 8, attempting to use a SUN Label on a lun greater than 1TB will fail. All other OS's did not have this restrictions and VxVM placed a Sun SMI label on luns pre VxVM5.0MP4 when initualized as cdsdisk format and the lun was greater than 1TB. VxVM documents stated that lun greater than 1TB must be initialized as sliced format and have a gpt/efi label.

Resolution

Please refer to TECH194936 for correct upgrade path.

If customer has already upgrade and is currently running into this issue please have him do the following:

They have two options:

1) Downgrade vxvm to 5.0Mp3 and rerun vxdisksetup. In this version of vxvm the 1TB limitation is not there. So we can initialized a lun with a standard SUN DISK Label as large as 2TB

2) keep the version they are running and relabel the lun as an EFI/GPT Label. Note: EFI/GPT label is supported with cdsdisk format

To get around this we have to relabel the lun using format, fdisk, parted .

Note: Having the wrong offset can lead to vxfs corruption.

You must have access to a previous vxdisk list . Directory /etc/vx/cbr/ should be a good place to look.

According to CBR used the public: offset=2034 to figure out what the new privlen will be

1 ) vxdisk list sda to get public offset

OLD vxdisk list output

public: slice=0 offset=65792 len=4294639360 disk_offset=0 <<< puboffset value

private: slice=0 offset=256 len=65536 disk_offset=0

With the new version and the introduction of EFI/GPT labels we cannot touch blocks 0-48. This will be reflected in the disk_offset .

2) Use parted to place a gpt label this is different for every OS. Contact backline is further assistance is needed.

#parted /dev/sda

#mklabel

#gpt

3) Run vxdisksetup with the following options Keep in mind when gpt labeled vxdisksetup will not go past the puboffset. In some cases you will have to shrink the size of the private region but never shrink the puboffset value

Note: You must subtract the "disk_offset=48" from the current "public: offset=" to get the correct "puboffset="

"public: offset=" - "disk_offset=48" = "puboffset="

Puboffset: 65792 - 48 = 65744

Privoffset: 256 - 48 = 208

# /etc/vx/bin/vxdisksetup -fvi sdb privoffset=208 privlen=65536 puboffset=65744

4) Compare the old label with the new one.

OLD vxdisk list output

public: slice=0 offset=65792 len=4294639360 disk_offset=0

private: slice=0 offset=256 len=65536 disk_offset=0

With the new version and the introduction of EFI/GPT labels we cannot touch blocks 0-48. This will be reflected in the disk_offset .

NEW vxdisk list output

public: slice=0 offset=65744 len=4294901200 disk_offset=48

private: slice=0 offset=208 len=65536 disk_offset=48

public offset + disk_offset = puboffset ...

5) Remove the failed disk from the diskgroup

vxdg -g -k rmdisk

6) add the disk to the diskgroup

vxdg -g -k adddisk =

Review the vxdisk list of the device an compare the disk_offset.

Applies To

This applies if all the following conditions are meet:

1) Must be using Linux, AIX, or HP Operating systems

2) Must have luns greater than 1 Terabyte

3) Luns must be initialize as cdsdisk format

4) Must be initialize in VxVM version 5.0MP3RP3 or below

Issue/Introduction

Upgrading from 5.0MP3RP3 or below to 5.1SP1 when vxconfigd first starts up, a defect in vxconfigd code that changes the VTOC label to a GPT label is lacking code changes similar to vxdisk resize and fails to update other related information. Due to the failure of updating relevant information causes the private region to be corrupted and renders the diskgroup un-importable after upgrade.Code enhancements in VxVM 5.1SP1 to convert SMI label luns greater than 1TB, initialized as cdsdisk format, to and EFI label. This code enhancements could fail during initial boot up and startup of vxconfigd. It caused diskgroup to fail to import and disk in a failed state

Welcome to "KB Articles"