Extending a physical volume - HP UX

This is a discussion on Extending a physical volume - HP UX ; 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 ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Extending a physical volume

  1. Extending a physical volume

    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.


  2. Re: Extending a physical volume

    wrote in message
    news:1136308607.610715.251690@g49g2000cwa.googlegr oups.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.



  3. Re: Extending a physical volume

    Thanks it helped so much


  4. Re: Extending a physical volume

    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

  5. Re: Extending a physical volume

    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" 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.




  6. Re: Extending a physical volume

    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

  7. Re: Extending a physical volume

    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" 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




  8. Re: Extending a physical volume

    On 2006-01-04, Florian Anwander 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
    #include
    #Not speaking for my employer. No warranty. YMMV.

  9. Re: Extending a physical volume

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


  10. Re: Extending a physical volume

    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




  11. Re: Extending a physical volume


    wrote in message
    news:1136407202.125832.285710@g47g2000cwa.googlegr oups.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.



  12. Re: Extending a physical volume

    "Mario" wrote:

    >
    > wrote in message
    >news:1136407202.125832.285710@g47g2000cwa.googlegr oups.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 |
    | |
    | Nunawading, Victoria , Australia |
    ================================================== ============

+ Reply to Thread