Hi guys,

I need to expand one logical volume which is now in 99% utilization. The volume group only have 5GB and they need 25GB more so that I can add 30GB. The disks will be coming from SAN Storage. If the SAN Admin can successfully add the disks to the server and I can see it, should I still partition it and change the type to Linux LVM?

I have tried just doing a pvcreate without partitioning and do a vgextend and it works without actually partitioning the disks. But when I do "fdisk -l", it actually shows that the disk don't have partition.

Can you please confirm whether I need to partition the drive to 8e (Linux LVM) before doing? Which one is better? Below are my steps and please let me know if this the correct one.

Here's my steps:

1.) dmesg | grep sd (to check the newly added disks)
2.) fdisk /dev/sdx (create primary partition and assign Linux LVM to type)
3.) pvcreate /dev/sdx
4.) vgextend VolumeName /dev/sdx
5.) lvextend -L+30G Volume01 /dev/Volume01/lv01
6.) umount /dev/Volume01/lv01
7.) resize2fs /dev/Volume01/lv01
8.) mount /dev/Volume01/lv01 /lv01
9.) df -h (check if resized successfully)

Thanks.

Looks okay to me
You might want to do a e2fsck (no fix) after the resize, to make sure the fs is healthy.

You technically don't need a partition, but it's good practice to create one on there.
Later you will be able to add other partitions to the same disk, grow the disk or resize the partition.
I'm not really sure if you can do the same trick on a pv that's created on the top level device node...

Hi kurwongbah,

Thanks for the response. Yeah, I think I need to do 'e2fsck -f /dev/Volume01/test01' before I do resizing since this will be prompted and cannot proceed with resize2fs. What are the chances that when I do e2fsck that it will prompt for a fix? This is kinda scary if I do fix, will it automatically corrupt the data? Thanks.

Hi depam,
Don't be scared of filesystem checking, it's your friend...
And after all: this is Linux =)

But seriously, you've only got a 5Gb volume, it would be easy to get a quick backup and TEST IT.
You could:
- umount /dev/Volume01/lv01
- dd if=/dev/Volume01/lv01 of=/tmp/somefile (be sure to have 5Gb free om /tmp)
- Create new temp pv
- Create new temp vg, using new temp pv
- Create new temp lv (same size), using new temp vg
- dd if=/tmp/somefile /dev/VolumeGroupNewTemp/lvNewTemp
- mount /dev/VolumeGroupNewTemp/lvNewTemp /mnt/tempmountpoint
- check data on /mnt/tempmountpoint
- umount and trash lv, vg and pv

Now you will be safe to do all the checking and fixing required.

THINGS TO NOT DO WITHOUT A PROPER BACKUP IN A PRODUCTION ENVIRONMENT:
e2fsck -f (To be used as last resort, usually does a good job in case of emergency, better to rely on the backup)
resize2fs (Usually works perfect, but read the man page: BACK UP)
lvextend (Usually works)
vgextend (Usually works)

Good luck!

Hi kurwongbah,

Thanks again for the info. For your information, the kernel level of the one I will be doing is very old 2.4. My activity will be on the 22nd of May. What I have done so far is to simulate it in VMWare. I have installed RH9 and added some virtual scsi disks and played with LVM.

What I notice is that in RH9 with kernel 2.4, you will be prompted to do "e2fsck -f /dev/Volume01/test01" before you can do "resize2fs /dev/Volume01/test01". This is different on newer kernels such as in RHE 4.5 and CentOS. It seems that e2fsck -f in 2.4 is a must before doing actual resizing. We have everything backed up in TSM and CBMR so I can restore the data whenever something goes wrong. I could not do a "dd" on the VG because the local drive is also maxed out. It has two disks but the second disk is also a PV of another LVM.

I wish everything will be smooth.

Thanks a lot for your help.

RH9 is extremely old and cannot be compared to a modern system like RHEL/Centos 4.x or 5.x.
It prob still uses LVM v1 (if it does LVM at all). Modern systems have LVM v2. If you want to test, use a comparable system.

Okay, RH9 is a bit ancient but it will do the job.
LVM has not changed much from an administration point of view, stability has. Especially in the kind of things you are going to do...
I agree with chrism01 there; use comparable systems for testing.
Since you are on vmware, this will be a good time to test that tsm backup you've got going.
DO NOT WORK ON THE ASSUMPTION YOUR BACKUP WILL BE RESTORABLE; TEST IT!!!

My initial thought was:
You will be getting an extra 25Gb for the expansion, why not use that to create a 5Gb pv and a new vg/lv for the restore testing.
You can also create an extra normal linux partition on it to dd the backup output file onto.

The VM I am using is the closest version to our production. Yes its quite old. The reason why I used Red Hat9 VM is because it is the only image that I have that has 2.4 kernel. I will check the system and test if there is still space left on it. Probably this will be on the root filesystem.

I will try to test it out again and let you know. By the way, do you know the command to split the image files into 2GB? This is what I got from the posts but I am unable to test this one out:

dd if=/dev/Volume01/test01 of=/tmp/test01lv.img | split -b 2000M

Thanks a lot for your help guys you have been very helpful to me.

Hi kurwongbah and chrism01,

Thanks a lot for your advice. It worked as expected. I was able to extend the VG and LV. Though, since it is using LVM1 I need to do some extra caution. But everything worked fine.

Thanks a lot for your help.