Hi,

I have never worked with HP-UX. I am actually dealing with IBM AIX.

I have a question about LVM on HP-UX.
For example, assume we have a VG with 1 PV which comes from a SAN
storage and we want to extend the size of that PV (LUN) from SAN disk
subsystem. Can HP-UX handle this? I mean, is it possible to extend the
size of PV being used in a VG online or offline? If so, what should the
procedure and the necessary LVM commands be?

Thanks and regards.

<mhmtzdmr@gmail.com> wrote in message 
news:1136308607.610715.251690@g49g2000cwa.googlegroups.com...
> Hi,
>
> I have never worked with HP-UX. I am actually dealing with IBM AIX.
>
> I have a question about LVM on HP-UX.
> For example, assume we have a VG with 1 PV which comes from a SAN
> storage and we want to extend the size of that PV (LUN) from SAN disk
> subsystem. Can HP-UX handle this? I mean, is it possible to extend the
> size of PV being used in a VG online or offline? If so, what should the
> procedure and the necessary LVM commands be?
>
> Thanks and regards.
>


Results 1 - 10 of about 23,600 for "lvm cookbook". (0.20 seconds)

The HPUX 'SAM' utility will do many LVM activities from a menu - no 
command-line struugles. 

Thanks it helped so much :(

Hi mhmtzdmr

> For example, assume we have a VG with 1 PV which comes from a SAN
> storage and we want to extend the size of that PV (LUN) from SAN disk
> subsystem. Can HP-UX handle this? 
No. LVM can't handle this, because there is a table in the LVM-header of 
the PV which describes the complete disk and assigns which physical 
extent contains which logical extent. This table cannot be extended.

LVM is a concept which is based on fixed physical disk sizes and extends 
on the virtual level of LVs. If you want use the extension possibilities 
of the SAN, then create the filesystem direct on the LUN without a LVM 
between.


Florian

True, you can't extend a SAN partition and have HPUX allow for it. You can 
however create a new, larger LVM, and pvmove off of the old SAN partition 
onto the new PV, and then extend your LV to use all of the space on the new 
SAN PV.

"Florian Anwander" <spam.interessiert.nicht@mnet-online.de> wrote in message 
news:421nvlF1dqpv7U1@individual.net...
> Hi mhmtzdmr
>
>> For example, assume we have a VG with 1 PV which comes from a SAN
>> storage and we want to extend the size of that PV (LUN) from SAN disk
>> subsystem. Can HP-UX handle this?
> No. LVM can't handle this, because there is a table in the LVM-header of 
> the PV which describes the complete disk and assigns which physical extent 
> contains which logical extent. This table cannot be extended. 

Hi Tom

> You can 
> however create a new, larger LVM, and pvmove off of the old SAN partition 
> onto the new PV, and then extend your LV to use all of the space on the new 
> SAN PV.
Cool trick! Though I'd not rely on pvmove. If pvmove is somehow 
disturbed (e.g. SAN error, or more bad: controlling terminal is gone) 
the data are lost.  I'd prefer to restore a backup to a new created lvol.

btw: an additional problem could be that the LVM-header(the vgda) of the 
Volumegroup is to small for large PVs. Then nothing helps but creating a 
new VG.

Florian

Yeah, there are lots of "gotchas" in doing this, but you get what you pay 
for. It can be done, but that doesn't mean there aren't problems (especially 
true with older HPUX versions). Did have a pvmove hit a bad HSC FWD 
controller once, and I picked up right where I was when it lbolt'd the 
system into oblivion. Sometimes doing online reorgs are the only way it can 
be done, due to inability to get extended downtimes for "safer" solutions.

"Florian Anwander" <spam.interessiert.nicht@mnet-online.de> wrote in message 
news:4228i2F1h3jqcU1@individual.net...
> Hi Tom
>
>> You can however create a new, larger LVM, and pvmove off of the old SAN 
>> partition onto the new PV, and then extend your LV to use all of the 
>> space on the new SAN PV.
> Cool trick! Though I'd not rely on pvmove. If pvmove is somehow disturbed 
> (e.g. SAN error, or more bad: controlling terminal is gone) the data are 
> lost.  I'd prefer to restore a backup to a new created lvol.
>
> btw: an additional problem could be that the LVM-header(the vgda) of the 
> Volumegroup is to small for large PVs. Then nothing helps but creating a 
> new VG.
>
> Florian 

On 2006-01-04, Florian Anwander <spam.interessiert.nicht@mnet-online.de> wrote:
> Hi Tom
>
>> You can 
>> however create a new, larger LVM, and pvmove off of the old SAN partition 
>> onto the new PV, and then extend your LV to use all of the space on the new 
>> SAN PV.
> Cool trick! Though I'd not rely on pvmove. If pvmove is somehow 
> disturbed (e.g. SAN error, or more bad: controlling terminal is gone) 
> the data are lost.  I'd prefer to restore a backup to a new created lvol.

Well, if you have MirrorDisk, you can mirror to the bigger PV and then
when that's done, drop the copy on the smaller PV ... should be a bit
safer.

> btw: an additional problem could be that the LVM-header(the vgda) of the 
> Volumegroup is to small for large PVs. Then nothing helps but creating a 
> new VG.

I've had that happen several times, yes. That taught me to always make
bigger headers than I'd think I'd ever need when I was first installing
anything ... _and_ to reinstall everything that came from HP as they had
by default only minimal extra room in the LVM headers, if any, at some
point.


-- 
Mikko Nahkola <mnahkola@trein.ntc.nokia.com>
#include <disclaimer.h>
#Not speaking for my employer. No warranty. YMMV. 

So what should I do? What commands should I concentrate on?

On 4 Jan 2006 12:40:02 -0800, mhmtzdmr@gmail.com wrote:

>So what should I do? What commands should I concentrate on?


First, use vgdisplay to see what the maximum physical volume (PV)
size is for the existing volume group. You may need to create a new
volume group that allows for a larger PV size - since your existing
max PV size is likely based on the largest PV that was present when
the current VG was created.

Note: You may use vgcreate options when a VG is created,  in
anticipation of larger PV's to come ie to specify a max PV size larger
than the default.

If MirrorDisk/UX is installed on the system, as previously suggested,
then a logical volume may be mirrored to another disk within the same
volume group. lvextend with the -m arg would be used. Then lvreduce,
also with the -m arg to reduce the original lvol copy off of the
original PV.

If you need to create a new VG for the larger PV, then consider
following up with  something like cpio pass through to copy the old
filesystems to new filesystems on the larger PV. Remember to use the
[find to cpio]  options that will retain ownership, mod and creation
times, links etc of the directories and files.

Also as previously suggested, pvmove may be an option - though I've
not used it in the context of what you're doing. pvmove uses a form of
mirroring that does not require the presence of MirrorDisk/UX. Also as
previously noted, if a pvmove operation has problems, recovery is not
always  simple - and not always  possible, depending upon the nature
of the problem. Sometimes such a recovery means reducing the failed
copy off of a PV, and then trying again after determining why the
failure occured.

There are many good LVM command examples in the ITRC knowledge base at
http://itrc.hp.com.


Eric Stahl

<mhmtzdmr@gmail.com> wrote in message
news:1136407202.125832.285710@g47g2000cwa.googlegroups.com...
> So what should I do? What commands should I concentrate on?
>

Is there any special reason against adding new PV to the existing VG (of
course, it means new LUN, but ...)?

M.

"Mario" <mario.jaksic@zg.htnet.hr> wrote:

>
><mhmtzdmr@gmail.com> wrote in message
>news:1136407202.125832.285710@g47g2000cwa.googlegroups.com...
>> So what should I do? What commands should I concentrate on?
>>
>
>Is there any special reason against adding new PV to the existing VG (of
>course, it means new LUN, but ...)?
>
>M.
>
This is what I have always done, have a new LUN set up and add it to
the vg. Can do this "on the fly", no reboot required.
Once the new LUN setup on the array and assigned to your fiber/scsi
channel run ioscan to detect the new device and then insf -e to set up
the device file. You can the use vgextend to add the new device to the
vg.

Ted.
==============================================================
| Ted Linnell                 <edlinnell@acslink.net.au>     |
|                                  |
| Nunawading, Victoria , Australia                           |
==============================================================