LVM gymnastics - Aix

This is a discussion on LVM gymnastics - Aix ; Hi everyone, *** Calling all LVMers *** p595 / AIX 5.3 / EMC DMX-3 We've kind of painted ourselves into a corner here and I was wondering if anyone had any bright ideas. Scenario: A standard AIX VG ( 32 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: LVM gymnastics

  1. LVM gymnastics

    Hi everyone,

    *** Calling all LVMers ***

    p595 / AIX 5.3 / EMC DMX-3

    We've kind of painted ourselves into a corner here and I was wondering if
    anyone had any bright ideas.

    Scenario:

    A standard AIX VG ( 32 PV limit ) currently has 26 PVs ( 8.6GB LUNs from EMC
    Symmetrix )

    We have created a further 4 x 8-way EMC metavolumes ( equivalent to 32 of
    the original LUNs ) intending to extendvg (add them into the VG), migratepv
    (to reposition the LVs) and then reducevg (to take the old PVs out).

    However, we can't add these metavolumes ( I guess you're all ahead of me
    here ) because of the 1016 PP limit:

    0516-1162 extendvg: Warning, The Physical Partition Size of 16 requires the
    creation of 4315 partitions for hdiskpower51. The limitation for
    volume group
    gl01prudp1vg is 1016 physical partitions per physical volume. Use
    chvg command
    with -t option to attempt to change the maximum Physical Partitions
    per
    Physical volume for this volume group.

    If we use chvg -t 2, 3 etc then this won't help because the current number
    of PVs ( 26 ) will be higher than that allowed in the VG once the chvg -t
    had taken effect.

    I really wanted to use migratepv, but now the only solution I can see is
    either:

    a) back up the entire VG, destroy it, recreate with new meta LUNs and
    restore

    b) create a new VG alongside the old one, use tar / cp / whatever to move
    data from old VG to new VG, remove old VG and rename old VG to new VG

    The question, therefore, is:

    Does anyone know a way of squeezing these large ( 69GB ) LUNs into a VG
    currently full of 8.6 GB LUNS whilst not offending AIX and without resorting
    to either of the two workarounds stated above ?

    Many thanks,

    Nick Buckley,
    Cardiff,
    UK





  2. Re: LVM gymnastics

    On Oct 11, 2:35 pm, "Nicholas Buckley"
    wrote:
    > Hi everyone,
    >
    > *** Calling all LVMers ***
    >
    > p595 / AIX 5.3 / EMC DMX-3
    >
    > We've kind of painted ourselves into a corner here and I was wondering if
    > anyone had any bright ideas.
    >
    > Scenario:
    >
    > A standard AIX VG ( 32 PV limit ) currently has 26 PVs ( 8.6GB LUNs from EMC
    > Symmetrix )
    >
    > We have created a further 4 x 8-way EMC metavolumes ( equivalent to 32 of
    > the original LUNs ) intending to extendvg (add them into the VG), migratepv
    > (to reposition the LVs) and then reducevg (to take the old PVs out).
    >
    > However, we can't add these metavolumes ( I guess you're all ahead of me
    > here ) because of the 1016 PP limit:
    >
    > 0516-1162 extendvg: Warning, The Physical Partition Size of 16 requires the
    > creation of 4315 partitions for hdiskpower51. The limitation for
    > volume group
    > gl01prudp1vg is 1016 physical partitions per physical volume. Use
    > chvg command
    > with -t option to attempt to change the maximum Physical Partitions
    > per
    > Physical volume for this volume group.
    >
    > If we use chvg -t 2, 3 etc then this won't help because the current number
    > of PVs ( 26 ) will be higher than that allowed in the VG once the chvg -t
    > had taken effect.
    >
    > I really wanted to use migratepv, but now the only solution I can see is
    > either:
    >
    > a) back up the entire VG, destroy it, recreate with new meta LUNs and
    > restore
    >
    > b) create a new VG alongside the old one, use tar / cp / whatever to move
    > data from old VG to new VG, remove old VG and rename old VG to new VG
    >
    > The question, therefore, is:
    >
    > Does anyone know a way of squeezing these large ( 69GB ) LUNs into a VG
    > currently full of 8.6 GB LUNS whilst not offending AIX and without resorting
    > to either of the two workarounds stated above ?
    >
    > Many thanks,
    >
    > Nick Buckley,
    > Cardiff,
    > UK


    change to a big volume group to allow more physical volumes in the
    volume group


  3. Re: LVM gymnastics

    On 2007-10-11, Nicholas Buckley wrote:

    > However, we can't add these metavolumes ( I guess you're all ahead of me
    > here ) because of the 1016 PP limit:

    [...]
    > If we use chvg -t 2, 3 etc then this won't help because the current number
    > of PVs ( 26 ) will be higher than that allowed in the VG once the chvg -t
    > had taken effect.

    [...]
    > Does anyone know a way of squeezing these large ( 69GB ) LUNs into a VG
    > currently full of 8.6 GB LUNS whilst not offending AIX and without resorting
    > to either of the two workarounds stated above ?


    I'm not quite sure whether this works (don't have access to any AIX box right
    now), but maybe you can convert the volume group to Scalable Volume
    Group-format?


    --
    Jurjen Oskam

    Savage's Law of Expediency:
    You want it bad, you'll get it bad.

  4. Re: LVM gymnastics

    Yes, I thought about big / scalable.

    But, as far as I understand it, this isn't possible once a VG is created.

    In other words:

    exportvg < old VG name >

    importvg < new VG name >

    Works fine if you want to rename a VG, but

    exportvg < old standard VG >

    importvg < same VG but as a Big / Scalable VG >

    Isn't permitted.

    That is, I would need to create a new VG with big / scalable attributes,
    rather than keep the existing one.

    Right ?

    Wrong ?

    Either way thanks for the rapid response.

    Nick


    wrote in message
    news:1192130451.614174.48430@50g2000hsm.googlegrou ps.com...
    > On Oct 11, 2:35 pm, "Nicholas Buckley"
    > wrote:
    >> Hi everyone,
    >>
    >> *** Calling all LVMers ***
    >>
    >> p595 / AIX 5.3 / EMC DMX-3
    >>
    >> We've kind of painted ourselves into a corner here and I was wondering if
    >> anyone had any bright ideas.
    >>
    >> Scenario:
    >>
    >> A standard AIX VG ( 32 PV limit ) currently has 26 PVs ( 8.6GB LUNs from
    >> EMC
    >> Symmetrix )
    >>
    >> We have created a further 4 x 8-way EMC metavolumes ( equivalent to 32 of
    >> the original LUNs ) intending to extendvg (add them into the VG),
    >> migratepv
    >> (to reposition the LVs) and then reducevg (to take the old PVs out).
    >>
    >> However, we can't add these metavolumes ( I guess you're all ahead of me
    >> here ) because of the 1016 PP limit:
    >>
    >> 0516-1162 extendvg: Warning, The Physical Partition Size of 16 requires
    >> the
    >> creation of 4315 partitions for hdiskpower51. The limitation for
    >> volume group
    >> gl01prudp1vg is 1016 physical partitions per physical volume.
    >> Use
    >> chvg command
    >> with -t option to attempt to change the maximum Physical
    >> Partitions
    >> per
    >> Physical volume for this volume group.
    >>
    >> If we use chvg -t 2, 3 etc then this won't help because the current
    >> number
    >> of PVs ( 26 ) will be higher than that allowed in the VG once the chvg -t
    >> had taken effect.
    >>
    >> I really wanted to use migratepv, but now the only solution I can see is
    >> either:
    >>
    >> a) back up the entire VG, destroy it, recreate with new meta LUNs and
    >> restore
    >>
    >> b) create a new VG alongside the old one, use tar / cp / whatever to move
    >> data from old VG to new VG, remove old VG and rename old VG to new VG
    >>
    >> The question, therefore, is:
    >>
    >> Does anyone know a way of squeezing these large ( 69GB ) LUNs into a VG
    >> currently full of 8.6 GB LUNS whilst not offending AIX and without
    >> resorting
    >> to either of the two workarounds stated above ?
    >>
    >> Many thanks,
    >>
    >> Nick Buckley,
    >> Cardiff,
    >> UK

    >
    > change to a big volume group to allow more physical volumes in the
    > volume group
    >




  5. Re: LVM gymnastics

    Thanks Jurjen,

    See first reply.

    I will try this tomorrow with a test VG ( it's 21:00 in the UK right now )

    However, nothing I've read says that changing the fundamental character of a
    VG via exportvg / importvg is supported...

    .... of course there may be some other way, but this type of VG modification
    ( e.g. change LTG size ) usually requires an exportvg / importvg.

    Regards,

    Nick


    "Jurjen Oskam" wrote in message
    news:slrnfgsu3l.5lj.jurjen@calvin.stupendous.org.. .
    > On 2007-10-11, Nicholas Buckley wrote:
    >
    >> However, we can't add these metavolumes ( I guess you're all ahead of me
    >> here ) because of the 1016 PP limit:

    > [...]
    >> If we use chvg -t 2, 3 etc then this won't help because the current
    >> number
    >> of PVs ( 26 ) will be higher than that allowed in the VG once the chvg -t
    >> had taken effect.

    > [...]
    >> Does anyone know a way of squeezing these large ( 69GB ) LUNs into a VG
    >> currently full of 8.6 GB LUNS whilst not offending AIX and without
    >> resorting
    >> to either of the two workarounds stated above ?

    >
    > I'm not quite sure whether this works (don't have access to any AIX box
    > right
    > now), but maybe you can convert the volume group to Scalable Volume
    > Group-format?
    >
    >
    > --
    > Jurjen Oskam
    >
    > Savage's Law of Expediency:
    > You want it bad, you'll get it bad.




  6. Re: LVM gymnastics

    On Oct 11, 3:44 pm, "Nicholas Buckley"
    wrote:
    > Yes, I thought about big / scalable.
    >
    > But, as far as I understand it, this isn't possible once a VG is created.
    >
    > In other words:
    >
    > exportvg < old VG name >
    >
    > importvg < new VG name >
    >
    > Works fine if you want to rename a VG, but
    >
    > exportvg < old standard VG >
    >
    > importvg < same VG but as a Big / Scalable VG >
    >
    > Isn't permitted.
    >
    > That is, I would need to create a new VG with big / scalable attributes,
    > rather than keep the existing one.
    >
    > Right ?
    >
    > Wrong ?
    >
    > Either way thanks for the rapid response.
    >
    > Nick
    >
    > wrote in message
    >
    > news:1192130451.614174.48430@50g2000hsm.googlegrou ps.com...
    >
    > > On Oct 11, 2:35 pm, "Nicholas Buckley"
    > > wrote:
    > >> Hi everyone,

    >
    > >> *** Calling all LVMers ***

    >
    > >> p595 / AIX 5.3 / EMC DMX-3

    >
    > >> We've kind of painted ourselves into a corner here and I was wondering if
    > >> anyone had any bright ideas.

    >
    > >> Scenario:

    >
    > >> A standard AIX VG ( 32 PV limit ) currently has 26 PVs ( 8.6GB LUNs from
    > >> EMC
    > >> Symmetrix )

    >
    > >> We have created a further 4 x 8-way EMC metavolumes ( equivalent to 32 of
    > >> the original LUNs ) intending to extendvg (add them into the VG),
    > >> migratepv
    > >> (to reposition the LVs) and then reducevg (to take the old PVs out).

    >
    > >> However, we can't add these metavolumes ( I guess you're all ahead of me
    > >> here ) because of the 1016 PP limit:

    >
    > >> 0516-1162 extendvg: Warning, The Physical Partition Size of 16 requires
    > >> the
    > >> creation of 4315 partitions for hdiskpower51. The limitation for
    > >> volume group
    > >> gl01prudp1vg is 1016 physical partitions per physical volume.
    > >> Use
    > >> chvg command
    > >> with -t option to attempt to change the maximum Physical
    > >> Partitions
    > >> per
    > >> Physical volume for this volume group.

    >
    > >> If we use chvg -t 2, 3 etc then this won't help because the current
    > >> number
    > >> of PVs ( 26 ) will be higher than that allowed in the VG once the chvg -t
    > >> had taken effect.

    >
    > >> I really wanted to use migratepv, but now the only solution I can see is
    > >> either:

    >
    > >> a) back up the entire VG, destroy it, recreate with new meta LUNs and
    > >> restore

    >
    > >> b) create a new VG alongside the old one, use tar / cp / whatever to move
    > >> data from old VG to new VG, remove old VG and rename old VG to new VG

    >
    > >> The question, therefore, is:

    >
    > >> Does anyone know a way of squeezing these large ( 69GB ) LUNs into a VG
    > >> currently full of 8.6 GB LUNS whilst not offending AIX and without
    > >> resorting
    > >> to either of the two workarounds stated above ?

    >
    > >> Many thanks,

    >
    > >> Nick Buckley,
    > >> Cardiff,
    > >> UK

    >
    > > change to a big volume group to allow more physical volumes in the
    > > volume group


    chvg -B to change to big


  7. Re: LVM gymnastics



    > chvg -B to change to big




    Interesting ... will indeed try this, but from IBM's "LVM A-Z" I think I see
    a showstopper:

    Notes:
    1. The -B flag cannot be used if there are any stale physical partitions or
    there are any open logical volumes in the volume group.

    No problem here

    2. Once the volume group is converted, it cannot be imported into AIX
    Version 4.3.1 or lower versions.

    No problem here.

    3. The -B flag cannot be used if the volume group is varied on in concurrent
    mode.

    No problem here.

    4. There must be enough free partitions available on each physical volume
    for the VGDA expansion for this operation to be successful.

    Ah. Most of the disks are full :-(

    Most of the LVs are too big to migratepv to a temporary 8.6GB LUN

    Still, it's worth a look - will report back with findings.

    All the best,

    Nick





  8. Re: LVM gymnastics


    > 4. There must be enough free partitions available on each physical volume
    > for the VGDA expansion for this operation to be successful.
    >
    > Ah. Most of the disks are full :-(>


    Hello



    There is quite useful lvm command to address that issue: "migratelp". You
    can use it to move an individual LP to another physical device, it's quite
    straightforward and doesn't require downtime. With this method one can
    regain that "precious" free PP so needed for various lvm operations, and
    after that migrate the LP back to the original PV. Just be careful when lvm
    mirroring between different storage boxes in use (not to have two copies of
    the same LP located on luns served by single storage device).



    regards



    Pawel W.



+ Reply to Thread