Live resive an LVM PV (was RE: [ILUG] Booting a broken raid array)

[Kenn Humborg]

> Couldn't agree more, even an entry level one like the t100 or t300
> 
> In fact, I was on dell.ie only this morning to buy one for myself to
> replace this dodgy machine. I need one to reproduce issues (esx /
> Xenserver / xen on SLES & RHEL)
> 
> Personally I'd buy two and rsync between the two of them, oh and make
> sure you use a supported OS. SLES10 EM64T is dirt cheap, although I'd go
> with RHEL5 myself.

Conor,

Here's a slightly related thing that you might be able to answer.

Let's say I've got a PERC with some disks in a single RAID volume.
That single volume is an LVM physical volume (no partition
table - just a bare /dev/sdX).  I create an LVM volume group over
that PV and create one logical volume in that fills that volgroup.

Later I'm running out of disk space, so I buy another disk 
and do the MegaCli magic that expands the RAID volume onto the 
new disk.

How do I get LVM to see the larger space without downtime?

Last time I did this (CentOS 5.2 fully patched), I had to 
unmount the logical volume and deactivate the volume group.

Doing blockdev --rereadpt got the kernel to see the larger
size of the /dev/sdX disk, but pvresize wouldn't extend the
PV until the volgroup was deactivated.

So, instead of this expected sequence:

   MegaCli ... # re-construct RAID volume
   blockdev --rereadpt /dev/sdX
   pvresize /dev/sdX
   lvresize ...
   resize2fs ...

I had to do this:

   MegaCli ... # re-construct RAID volume
   blockdev --rereadpt /dev/sdX
   # stop all processes using /mnt/whatever
   # remove /etc/exports entry
   exportfs -r
   umount /mnt/whatever
   vgchange -a n volgroup # deactivate volgroup
   pvresize /dev/sdX
   vgchange -a y volgroup
   mount /mnt/whatever
   # restore /etc/exports entry
   exportfs -r
   # start processes using /mnt/whatever
   lvresize ...
   resize2fs ...

I was well irritated, let me tell you...

Is there any way around this?

Later,
Kenn