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

[Conor Wynne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kenn Humborg wrote:
>> 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?

Glad you figured it out, adding this to my list of usefull command
sequences :-)

I don't remember coming across that particular problem before, maybe a
reboot to runlevel1 or emergency mode could have sorted it.

Effectively doing your "blockdev --rereadpt /dev/sdX" / "partprobe" with
a "rescan scsi bus" for you.

Personally I avoid growing array's altogether, I prefer to add a second
LUN and then pvcreate /dev/sd(x), then the extents become magically
available to grow whatever lv you need.

I can have a look for this though (unless someone else has answered it
in the interim)

Mailing myself a reminder.

> Later,
> Kenn
> 

Conor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJcKMW0c4nF4jv4ukRAjTiAJ4g838oxICV5MmZ5kpkYvwOdSYXUgCdFrhB
kC2I/0cvdBzTu/BUIbHxleA=
=SyXx
-----END PGP SIGNATURE-----