Expanding a disk exported by an EVA 6100 (and the underlying FS)

[compiler]

Hi.

I have a 20GB disk exported by an EVA 6100. The previous system administrator used pvcreate over that disk, and created a volume group (/dev/vg01) for it, and a logical volume (/dev/vg01/lvol1) using 100% of the disk (there are no more PE available).

That logical volume was formatted with VxFS and mounted in an HP-UX 11v23 system as /u01/app/oracle.

Now were are running out of space in that volume, and I've been asked to allocate more space for it.

I imagine that I can:

- Create a new disk in the EVA 6100. HP-UX will see it as a new scsi disk.
- Run pvcreate on it and add it to the /dev/vg01 volume group.
- Extend the /dev/vg01/lvol1 logical volume and filesystem so that the new space becomes available.

But, I would like to know if it would be possible to:

- In the EVA, make the original disk larger (10 extra GB).
- "Extend" the PV so that it uses the new extra space.
- Extend the filesystem.

Under Windows 2003, as an example, shrinking the disk in the EVA makes appear new, unpartitioned space at the end of the disk. Then you just extend the FS and you're done.

But, under HP-UX, I don't know:

- Extending the disk (the LUN) ... can produce troubles to the currently mounted disk?
- System would detect the new size "automatically"?
- Would hardware path of the disk change?
- How do I extend the PE, VG and LV so that the new space can be used for my volume?

Summarizing: I would like to "extend" the disk in the EVA and use that "extra" space in my current LVM volume... is that possible?

Thanks a lot.

[Duncan Edmonstone · Accepted solution]

Assuming by HP-UX 11v23 you mean HP-UX 11iv2 which is 11.23 from "uname -r", then the answer is "maybe"

You'll need to check whether you have the relevant patches to enable Dynamic LUN Expansion (DLE) as it's called. The whole process is described in some detail in the following whitepaper:

http://docs.hp.com/en/vgmodify/vgmodify_wp_modified_final.pdf

HTH

Duncan

[Jannik]

Another dynamic solution to this could be a move.
Create a new disk on the EVA.
Activate it and login to the hp box and then:

(if the old disk is c1t0d0 and the new are c2t0d0 and you lvolname is lvol1)

# ioscan -fnC disk
# insf -e
# pvcreate /dev/rdsk/c2t0d0
# vgextend vg01 /dev/dsk/c2t0d0
# pvmove -n /dev/vg01/lvol1 /dev/dsk/c1t0d0 /dev/dsk/c2t0d0
# vgreduce vg01 /dev/dsk/c1t0d0
# pvremove /dev/rdsk/c1t0d0

Then remove the disk from the EVA and remove the special file from the server on the disk that have the NO_HW in your ioscan.

# ioscan -funC disk | grep NO_HW
# rmsf -H

[compiler]

D. Edmonstone:
> You'll need to check whether you have the
> relevant patches to enable Dynamic LUN
> Expansion (DLE) as it's called.

So, DLE is supposed to be what I'm looking for, right? A way to expand a LUN so that LVM can use all the space in that disk after resizing it.


Jaton:
> # ioscan -fnC disk
> # insf -e
> # pvcreate /dev/rdsk/c2t0d0
> # vgextend vg01 /dev/dsk/c2t0d0
> # pvmove -n /dev/vg01/lvol1 /dev/dsk/c1t0d0 /dev/dsk/c2t0d0
> # vgreduce vg01 /dev/dsk/c1t0d0
> # pvremove /dev/rdsk/c1t0d0

Oh, that's creating a new PV, adding it to my current VG, and MOVING all the data from the previous disk to the new one. Then I extract the previous and now empty PV from the VG and all the data should be in the new one... right?

Can this be done "online"? (without dismounting any FS?)

But, after this ... I will still need to extend the LV and the filesystem, right? This will only ends with "Available Physical Extends" for the "standard" LVM extend process, right?

Thanks a lot to both for your answers :-)

[Duncan Edmonstone]

jaton's approach will *onl* work if your predecessor had some forethought and created the VG to allow for larger disks.

Run:

vgdisplay /dev/vg01

Look at the values "Max PE per PV" and "PE Size (Mbytes)"

The product of these two values gives you the largest disk you can have in your VG. So if:

(Max PR per PV) * (PE Size) < (Desired Size of new LUN)

Then you won't be able to add that new disk to the VG without going through some of the steps described in the WP I pointed you at anyway (i.e. using vgmodify)

HTH

Duncan

[Duncan Edmonstone]

gah! fat fingers. That forumal should have read:

(Max PE per PV) * (PE Size) < (Desired Size of new LUN)

And if the above is not true then yes you can do what Jaton suggests online

HTH

Duncan

[compiler]

> (Max PE per PV) * (PE Size) < (Desired Size of new LUN)
>
> And if the above is not true then yes you can do what Jaton suggests online

So, currently:

(vg01):
Max PE per PV 5119
PE Size (Mbytes) 4

5119*9 (*1024) = 20967424

And:

/dev/vg01/lvol1 20967424 20936846 30578 100% /u01/app/oracle

This means that I won't be able to create a new LUN larger than 20967424, and I must go with DLE, right?

Is not able to change Max PE per PV? :?

[Duncan Edmonstone]

>> Is not able to change Max PE per PV? :?

Yes it is - via the vgmodify command which is the tool through which DLE is implemented(you have to increase Max PE per PV as part of a DLE operation anyway)

But if you need to do a vgmodify operation anyway, you masy as well just follow the process described in the WP.

HTH

Duncan

[compiler]

Thanks a lot for your help :-)

Very useful and quick answers... great forum and great people reading it :-)

[Jannik]

then you are back with vgmodify i would use the -t option to view you possibilities. This would create a table for max_pe and max_pv and maximum disk size.

You could still just add a new disk of 20GB to the old vg. That is the solemn idea of LVM to create and extra abstraction layer. This is a powerful tool when you are working with disk and performance.