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

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.

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
>

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.

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

> 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

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