Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Grow LUN "live" Linux with SF 5.1 possible?

Created: 30 Jun 2011 • Updated: 09 Aug 2013 | 4 comments
This issue has been solved. See solution.

Hi,

I am running rhel 5.5 with SF 5.1 and an EMC SAN.  My EMC SAN has the capability (through pools) to increase the lun size dynamically.  I have not found a way to dynamically grow the volume on the SF side without rebooting.  Is this possible?   If so, how?  Please note that I am aware you can create a separate lun and put it in the Disk Group and grow the volume "live" - however this is not ideal as it creates a mess.

Regards,

Jim

Comments 4 CommentsJump to latest comment

Marianne's picture

You can use 'vxdisk resize'.

Please see http://sfdoccentral.symantec.com/sf/5.1/linux/html... for details.

Dynamic LUN expansion

Many modern disk arrays allow existing LUNs to be resized. The following form of the vxdisk command can be used to make VxVM aware of the new size of a LUN that has been resized:

# vxdisk [-f] [-g diskgroup] resize {accessname|medianame} \
  [length=value]

The device must have a SCSI interface that is presented by a smart switch, smart array or RAID controller. Following a resize operation to increase the length that is defined for a device, additional disk space on the device is available for allocation. You can optionally specify the new size by using the length attribute.

If a disk media name rather than a disk access name is specified, the disk group must either be specified using the -g option or the default disk group will be used. If the default disk group has not been set up, an error message will be generated.

This facility is provided to support dynamic LUN expansion by updating disk headers and other VxVM structures to match a new LUN size. It does not resize the LUN itself.

Any volumes on the device should only be grown after the LUN itself has first been grown.

Resizing should only be performed on LUNs that preserve data. Consult the array documentation to verify that data preservation is supported and has been qualified. The operation also requires that only storage at the end of the LUN is affected. Data at the beginning of the LUN must not be altered. No attempt is made to verify the validity of pre-existing data on the LUN. The operation should be performed on the host where the disk group is imported (or on the master node for a cluster-shared disk group).

Resizing of LUNs that are not part of a disk group is not supported. It is not possible to resize LUNs that are in the boot disk group (aliased as bootdg), in a deported disk group, or that are offline, uninitialized, being reinitialized, or in an error state.

Warning:

Do not perform this operation when replacing a physical disk with a disk of a different size as data is not preserved.

Before shrinking a LUN, first shrink any volumes on the LUN or more those volumes off the LUN. Then, resize the device using vxdisk resize. Finally, resize the LUN itself using the storage array's management utilities. By default, the resize fails if any subdisks would be disabled as a result of their being removed in whole or in part during a shrink operation.

If the device that is being resized has the only valid configuration copy for a disk group, the -f option may be specified to forcibly resize the device.

Resizing a device that contains the only valid configuration copy for a disk group can result in data loss if a system crash occurs during the resize.

Resizing a virtual disk device is a non-transactional operation outside the control of VxVM. This means that the resize command may have to be re-issued following a system crash. In addition, a system crash may leave the private region on the device in an unusable state. If this occurs, the disk must be reinitialized, reattached to the disk group, and its data resynchronized or recovered from a backup.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

SOLUTION
Jim Ganong's picture

unfortunately, i have already seen that and tried it.  It is fairly easy to get a lun to be recognized when it is new in linux without reboot (resan-scsi-bus or qlogic scan if you have qlogic hba's) but, in this case i am "growing" the lun, and need the OS to see the additonal space without rebooting.  Windows does this flawlessly (especially Windows 2008) so i was hoping that since i am using such an advanced kernel (5.5) that Linux could do it also.  So far I haven't found anything.

Jim

Gaurav Sangamnerkar's picture

Hi Jim,

What Marianne is saying is indeed the method to grow a Lun live without rebooting, since lun is rescanned to new size live , that's why it is called Dynamic Lun Expansion..

There are high chances of getting confused between running a vxresize & "vxdisk resize" .... former is used for a normal volume & FS resize operation .... later is used specifically for Dynamic Lun expansion.

In case you have already tried "vxdisk resize"  .. did you face any errors ? If yes, can u let us know the error messages

Also, DLE is a feature by Array, are you sure that array is supporing DLE ?

 

Gaurav

 

PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
 

Jim Ganong's picture

Yes, the EMC array supports DLE

There would be no errors since i cannot get it to recognize the added space in the first place.

I will test with the vxdisk resize command again shortly (hopefully today) and let you know.

Thanks!