SERVING UP LVs, PVs and PAVs
Since we've got redundant arrays on SANs these days, it may seem almost quaint to speak about software mirroring using the AIX Logical Volume Manager. Even so, LVM is very useful when you want to move data around. If you need to move to a new storage subsystem or just to a new LUN, and you're not able to do it on the backend, the LVM may be just the ticket.
For example, supposing you are using a LUN that's a whole lot bigger than you need. There might be a lot of reasons how it came to that but the most common one is you may have slightly overestimated the amount of disk you needed
when you first went with your begging bowl to the storage team. Admit it. You asked for thirty times more disk than you needed, just in case
. And the reason you did that is because you never listened to your mum when you couldn't finish your pavlova
("pav" in Aussie-land). Don't you remember her telling you: "Your eyes are bigger than your stomach"
Well now's your chance to
Make IT history!
and hand back some storage you don't need.LV to new PV in same VG
First you allocate a new, leaner (smaller!) LUN to AIX then add it to the volume group using extendvg
. (You may need to change its queue depth
, preferred path
, health check interval
etc). Once it's a member of the VG, you can mirror at the logical volume level using mklvcopy
You can mirror a whole volume group, (mirrorvg
), and that's really the best way to do it with rootvg, because it has boot disks and dump devices which need special treatment. For other volume groups I often use mklvcopy
because it allows me to mirror one logical volume at a time. You don't need to synchronise the two copies immediately (using the -k flag), but until you do, the lslv
command (and the lsvg
command) will show some partitions are stale. You can create the copies and wait for a quieter time to run the synchronise. It's a lot faster if the disks aren't busy, but it's perfectly legitimate to synchronise them while they're in use.
If you want to synchronise the two copies, use syncvg
. You can synchronise the whole volume group using
syncvg -v VGNAME
command (which activates a volume group) will do the same thing, and
you can run that command - varyonvg - even if the volume group is
already active. With both varyonvg and syncvg, if there are no stale
partitions to be synchronised, the shell prompt will come back in a jif
If you want to synchronise a single logical volume, use
Not seven years' bad luck
Once you've synchronised the mirror to the new LUN, you can break the mirror to the old one, by using
where N refers to the disk with the copy you're removing.
And you'll be stopped from running rmlvcopy if there will be only stale partitions left afterwards; you're not allowed to remove the last good copy of a physical partition. That's nice, isn't it? You also get a big warning if you try to remove a pv from a volume group when it still has any partitions on it.
The oft-quoted Chris Gibson has an article showing how he migrated to a new SAN using LVM
. The same principle applies for a single LUN. There is also the migratepv
command which is a simple way of moving everything off one pv to another. As with mirrorvg and mklvcopy, the target pv has to be a member of the volume group first.
These commands are so much fun that it's a shame to use SMIT, but you can do it that way if you want to.Shock the SAN team
Once you've run rmlvcopy
which will remove your seven years of bad luck), you can remove the PV from the volume group (reducevg
) before taking it out of the ODM using
rmdev -dl hdiskN
If you've removed the old giant LUN from the configuration all along the way (VG, ODM, VIO server), you can hand it back to your SAN team for them to recycle. Once they realise you're not playing some sort of practical joke, they'll be grateful. Shocked, but grateful. They may need the disk for someone else who didn't listen to his mum when she served up the pav.