Storage Foundations/Sun Solaris 10/EMC CX500 - expand questions

[SpiritRocks]

Greetings:

I am writing this from a SAN perspective so apologies in advance if I misinterpret any of the storage foundations areas.

We have a Clariion CX500 with attached hosts of Windows clients and Sun solaris.  We dual HBA all hosts and path management is PowerPath on all.

We expand LUN's on the SAN side for Windows hosts often.  I am able to then run disk manager in windows, the partition sees the "expanded area of space" and I can then simply right-click and "extend volume" from the expanded LUN, use as much space as I want and it works just like that.  No data lost, no reformats, easy going.

We have a Solaris 10 server with Storage Foundations installed (ver 5.1 I believe) and we are having extensive issues with our unix staff regarding expanding LUN's once issued.  In this case I had initially issued a 1TB LUN and feedback from the unix staff was Solaris picks it up fine and it was brought under the storage foundations control (file system, etc).  According to them all was great and we can dynamically grow this at any point we wish.

Next was I expanded that 1TB lun to 1.5TB.  At this point I have received conficting feedback from the unix sys admin that Solaris saw it, Solaris didnt see it, Veritas can expand it to this is not possible via any volume manager to dynamically grows LUN's as we wish. 

First off, based on the Solaris scenario above, what would be the proper steps to take in the initial 1TB LUN in regards to Solaris and storage foundations?  Next, what would be the proper steps after the 1TB is brought under and ready and the LUN is expanded to 1.5TB?  Can this be done without any type of reformat and is this process destructive in nature?  Would it ever be possible this is easily done in Windows but not possible in Solaris/Storage foundations?? (NOT saying it cannot be done, I am asking how).

NOTE:  Currently the storage foundations was downloaded and installed, I would say there is 99% chance this is a 'trial version' at this time.  Does that impact this?

Feedback is greatly appreciated as we need to be 100% comfortable we can expand LUN's down the road that are currently issued to existing attached Solaris hosts.

Many thanks in advance!!!

[Javier_E_Rodrig]

Hi

1. To resize

First change the size of the lun using the format command and enter in the type sub menu. Once Solaris sees the bigger lun you will have to go in Veritas and resize the disk, as my experience you have to enter the new size manually. This works for smaller luns, but


A. I always use luns smaller that 1Tb IF I am goind to use veritas, because of the labels you use when the lun is 1Tb or more. SMI vs EFI labels (you can see these usign the option -e in the format "format -e"). So if you need to resize a volume in Veritas, the just add another lun and user vxresize.

B. When resizing luns in Solaris I move all volumes from the lun before, just in case. I know this lun you have is huge so I guess that is not a option for you.

In summary , if you need to resize a file system or a volume, assign another lun and add it with the vxresize command. Or user ZFS ;p

[g_lee · Accepted solution]

It is possible to resize the LUN with Solaris and Storage Foundation non-destructively, although sometimes it's not entirely straightforward.

The size (>1TB, etc) isn't overly relevant as VxVM can handle EFI labels; the main problem I've seen/encountered is getting Solaris to pick up the size of the new LUN - in most cases people resort to relabelling the disk to get it to recognise the new size. While this is fine for getting Solaris to see the new size, relabelling tends to wipe out the private region slice so it needs to be put back/relabelled manually for VxVM to be able to do anything with the disk again.
Note: provided you put the private region back correctly (ie: don't reinitialise the disk to do this) this isn't destructive/data should still be on the disk.

Overview of resizing a LUN (modified from the following technote):  http://seer.entsupport.symantec.com/docs/286950.htm
Note: recommend doing this while disk is not active/not in use in case of issues.

1. Verify original size of LUN, save copy of vtoc
# prtvtoc /dev/rdsk/c#t#d#s2 > vtoc.orig.out

2. Preserve the below VXVM configuration information.
# vxprint -ht > vxprint.out
# vxprint -m -g <dg> > vxprint-m.<dg>.out
# vxdisk -o alldgs list > vxdisk.out
# echo|format > format.out

3. Resize the LUN on Solaris
(in most cases this is done via relabelling in format)

3a. Check the new disk vtoc, compare to output from Step 1.
# prtvtoc /dev/rdsk/c#t#d#s2
The only thing that should have changed is slice 2 (should be longer), the slices/layout from Step 1 should still be there
If slice tagged 15 has gone missing, this is a problem!

Workaround to fix if slices/layout has changed (ie: apart from slice 2)
Copy the old vtoc, edit to update length of slice 2 since this should be the only change:
# cp -p vtoc.orig.out vtoc.new.out
# vi vtoc.new.out
Write vtoc.new.out to the disk with fmthard
# fmthard -s vtoc.new.out /dev/rdsk/c#t#d#s2

4. Re-scan device tree once LUN(s) have been expanded.
# devfsadm

5. Resize LUN in VXVM to match new size in OS (note: length is optional, should be picked up automatically)
# vxdisk -g <diskgroup> resize <disk>
See MAN page for additional options/details.

6. Check LUN showing new size in vxvm
# vxdisk list <disk>
# vxprint -htrg <dg>   ### should show new length
# vxdg -g <dg> free  ### should show new additional space

7. Resize volumes, filesystems, etc as needed (vxresize)


See also Dynamic LUN expansion from VxVM Administrator's guide (link to 5.0MP3 below):
http://sfdoccentral.symantec.com/sf/5.0MP3/solaris/html/vxvm_admin/ch02s14.htm

re: your version being downloaded, this doesn't necessarily mean it's a "trial" version; online software can still be licensed, which is what should be checked here as, per the VxVM Admin guide:
"Note: A Storage Foundation license is required to use the dynamic LUN expansion feature."
(check with # vxlicrep -e )

Is it necessary to grow the LUNs as opposed to adding new LUNs / growing the volume over additional disks as Javier mentioned? As he pointed out, the additional disk option is somewhat more straightforward / less fiddly. That isn't to say the LUN expansion can't be done, it's just that from previous experience it can require greater manual intervention to put things back without inadvertently breaking things (mainly due to difficulty picking up the new size on the Solaris side - once the OS picks up the new size, vxdisk resize generally works without issue if licensing, etc is all in order.)

Hope that helps