Expand disk size on centos VM?
 

I have a VM with only 10GB of disk size avaliable.

I have expanded the disk size to 120GB from the VM tools, however, I only see 10GB of space from within Linux.

I have everything already installed on this VM as I need it and would like ot expand the logical volume to the entire 120GB that's now avaliable to it without losing everything on the disk.

Do I need to use the 'lvextend' tool as described on this page?

Maybe yes, maybe no. We need to figure out your config first.


Run the following commands as root or via sudo and give us the output:

I hope this gives the necessary information!

Your good to go, you will need to create a new partition, /dev/sda3, use pvcreate to make it a physical volume, use vgextend to extend your volume group, then use lvextend to extend your logical volume.

http://www.howtoforge.com/logical-vo...a-volume-group

http://linuxconfig.org/Linux_lvm_-_L...ate-partitions


MAKE SURE YOU SET THE PARTITION TYPE TO "8e" WHEN CREATING IT!


If you have specific questions about any of the commands or the syntax just let me know and I'll give you some examples

Before I dive off into this, I'm getting the following notification:

Am I to assume I need to do as suggested?

Thanks agian.

Not a big deal on that warning, just follow the steps.

Those will create the necessary partition for you. Then do a:

Now yo have another physical volume, lets add it to your volume group

Now you should have that extra space as free in your volume group, you can verify it with vgdisplay.


Finally, extend your current logical volume.

And to make the space available to the OS, resize the filesystem:

As seems to be the case just about any time I touch Linux, it's never straight forward.

1) Do I need to be worried about the note: Partition 1 does not end on cylinder boundary.
2) No Partition 3...I don't think I missed a step, did I?

Or, should the order be?

Yes, I usually use cfdisk so the commands were a bit out of order. The cylinder boundary error you can ignore as well. Plenty of info on google about it that explains why that happens.


So fdisk /dev/sda

n -- Create new partition
p -- make it a primary partition(you would want to make it an extended one if this was your 4th partition so you don't limit yourself)
3 - Set the partition number
Enter through to get the default sizes which should take up all the free space.
t - modify type
3 - select partition three
8e - make it a linux lvm type partition
w - write the partition

OK, done, and I get the following:

I rebooted the machine and was able to do everything else without error, until I reached resizing the filesystem:

I'm not sure where to go at this point. A quick search tells me it might be a different file system type?

Thanks so much for your continued help. If you were local, I would buy you a beer...or two.

Wait a second! We extended the wrong lv here...

Do the following:

If that gives you an error then you will need to resize the filesystem off of a rescue CD, as you may get an error that you can't resize a file system that is mounted.

I think this was my fault as I told you do the lvextend on your 01 lv and not the 00 lv which doesnt appear to be in use or have a filesystem on it, it's was only 256MB before you added the other 100GB.

:(

Do I just need to follow the same methods as you listed above?

Try running lvremove with the -f option, you're not going to break anything here..

lvremove -f /dev/VolGroup00/LogVol01

If that doesn't work, add the -vvvv option and give us the output.

I did this and it returned the following


I ran the following:

and a whole bunch of text populated the screen. Unfortunately, this is on a VM and I can't copy the text over (since i'm not able to putty in while it's running from the rescue cd).

Is there a particular part that you are looking for?

Try doing:

See if there are any processes that have a lock on it. You don't have it mounted, so it shouldn't be giving you this error. Did you see anything in the verbose output in regards to the cause of the error? I know the -vvvv gives you alot of output but it should tell us at what point it errors.

If you don't see any open file locks run the following:

If it shows a number "1" for the open status run the following:

You should then be able to execute the lvremove.

Is LogVol01 mounted by any chance?

It shouldnt be mounted, from the discussion we had this new lv got created. Unless it got mounted, which I can't see it from the steps the issue here is likely a file lock or the dmsetup.

I do see the following:

I'm not sure how to check if I have any open file locks, but in the output of the previous command, I do see the following:

Sorry if this might seem dense, is the code you inserted to be followed? It seems that you're creating a 'test' logical volume and mounting it to /mnt then removing it. I'm not sure I understand the purpose (just trying to learn).

When I run df -h, I don't have LogVol01, I only have LogVol00, along with some other partitions. LogVol00 is still at 9.5G in size and is at 100% use.

Also, /dev/loop0 is at 100% of 130M in use. I'm not sure if that matters?

Thank you again for all of the help.

Did you run the dmsetup commands I provided? What was the output of those? I think that is the issue here preventing the LV from being removed.

I apologise for the confusion - the commands were not meant to be run (but is good that you questioned it rather than blindly running commands). It was merely to demonstrate that trying to lvremove a volume whilst it was mounted produced the same error you were/are having.

I'll take a step back and allow the thread to continue with Kustom42.

Regards

Now, I suppose I need to know how to check for locked files. I found a few references to 'lsof' and 'lslk', however, being that I'm running on a LiveCD, I cannot install these. :(

Well, this is interesting...

That should allow you to remove it, add the -f option to the remove command.

dmsetup remove -f VolGroup00-LogVol01

result as follows:

Ok, well since you don't have access to lsof try this:

Let us know what the output of that is, something is locking this device and in all honesty it shouldnt unless you mounted it or started a process within that directory. This may be something related to the multipath daemon or udev but I'm not sure at this point. The ps command should show us whats happening.

I'm guessing this means that there is something locking it as root, but I'm not sure how to figure out what? is it pid 1618?

if I do the following:

I get the following:

Which I'm assuming is saying essentially the same as the previous output, that tty1 is using it?

When I do 'df -H', I don't see LogVol01 listed, only LogVol00??

The ps output you are getting is for the grep process you are running. This is very odd, there are no processes with a file open so you should have no issue removing the logical volume.

I have seen this is in wierd situation before where the device was suspended, not sure if thats the case but its something to try.

result as follows:

If I understood more about what was happening I would attempt to research, but I'm not even sure what's causing this at this point. :(

Actually, I just had a thought that LogVol01 could be the swap volume for your CentOS system. It's possible that the LiveCD you are using has automatically started using it as swap and could explain why it wasn't able to be removed. This might be shown by:

For now, I'd say forget about LogVol01 and simply carry on with extending the main volume LogVol00 as Kustom42 previously described. Unless you have already extended LogVol01 (lvs will show LVM volume sizes).

If I do a 'lvdisplay', I see where LogVol01 has a LV size of 100.24 GB while LogVol00 has a LV size of 9.65 GB. Is this showing that the LogVol01 has already been extended?


If all looks ok, at this point, I need to stay in recovery and do the following:

?

So this will need to be undone first with lvreduce to reclaim the space. To be thorough I propose the following commands, checking progress as you go ( at a pinch just the lvreduce would suffice for now ):

( Note: that it is not '-L -100G' because the original lvextend must have been executed as '-L 100G'. Subtle, but important if using other commands like lvresize, for example )

You can check progress with vgs (or vgdisplay) to ensure that the volume group has enough free storage.

That looks correct.

I'm assuming I want to hit yes, but the fact that it couldn't find swapoff makes me want to verify before I go through with this.

Can you try just swapoff on it's own (in case the path is different in your evironment) ?

The warning is great (!) since the command is a sure way to kill a system if typos are ever made in the volume name :). In this case we will be ok since we know there isn't anything important on LogVol01 ( /proc/swaps show Used = 0 ) but I would prefer swapoff to work first.

that seems to have worked (no errors).

I have successfully extended the LV to 109.65 GB and am now able to see that /VolGroup00-LogVol00 has a size of 108G with only 9.6G used!

Now I get to see if I can restore a Nagios install to this VM.

THANK YOU!!! This forum has been invaluable!!

Glad to see you go there, thanks for your eyes whizzit I was hitting the wall on this one. didn't think about it being set up as swap by the rescue CD, I'll have to keep that in mind.

Thanks for all of your help as well Kustom!