Expand partition on Linux KVM Client (ext4 / raw)

boot on ubuntu live cd and use gparted to extend
just tried in a test environment with the partition layout the way you have it and it worked fine

The Howto in your post is fairly outdated. Since qemu v1.3 resize is supported. Please check your qemu version for the the resize command (run qemu-img without parameters). In the howto, parted is only used to illustrate the changes.

Can you please clarify some things:
1. You want to extend a virtual disk in a client vm
2. You assigned a qemu image (raw/qcow) as boot disk to the VM
3. The VM's FS is ext4

If the former is true, you have no need to use parted at all. You should:
1. Stop the guest
2. Use qemu-img to resize the the image file in your Hypervisor
3. Use resize2fs to extent the partition inside the running VM:

# Stop the guest
$ virsh shutdown <yourvmname>
# resize the image; add 20GB for instance
$ qemu-img resize /path/to/boot.img +20GB
#start VM
$ virsh start <yourvmname>
# Switch to your guest
$ ssh <yourvmname>
# resize the partition; this works on active mount points only with extend
$ resize2fs /

Select allOpen in new window

The last command will claim all available space on the root partition. Check this with

$ df -h

Select allOpen in new window

With regard to seth2740's thoughts:
When you boot to gparted, it only shows mounted physical drives via the dropdown menu in the top right corner. I use gparted often at our shop.

It doesn't even see the VM image and I am uncertain how to point it to that image file for expanding the partition.

Your thoughts on this ?

With regard to helge000's comments:

When I try to ssh into my VM using the method you have provided, it fails with:

ssh: Could not resolve hostname VM-Staging: Name or service not known


I happen to know the IP of this VM is 192.168.0.43 however, if I type this I receive
ssh: connect to host 192.168.0.43 port 22: No route to host

I also cannot ping it.

So I suppose something is not quite right with your instruction.

Your thoughts ?

With regard to helge000's comments:

I would enjoy your answer to my previous comment.  However I also have a follow up observation.

If i log into my VM using virt-manager I am able to go to the command line and run resize2fs as you suggested.  Howver, this also yields an error as follows:

jay@staging:~$ resize2fs /
resize2fs 1.42 (29-Nov-2011)
open: Is a directory while opening /

Your thoughts ?

Jay

Hello compu523,
the SSH command is only an example, since I have no knowledge how you generally access your VM; I just assumed you access it with ssh because this is the most common way. If you use virt-manager; this will work the same. You can also use virt-manager to start and shutdown machines. I used virsh because you need to do the resize of the image via command line anyway and can provide an easy step by step operation; there is nothing wrong - but of course you need to adapt it for your needs.

The important part is, you need to do the final resize operation inside the VM. Because this for ext4 and your VM knowing the filesystem size. Please keep in mind you not only need to extend the device but the file system as well.

So, first: Did you manage to extend your image with qemu-img? Please confirm this with:

$ qemu-img info /path/to/boot.img

Select allOpen in new window

Remember to shutdown the VM prior to resizing.

Second: If resize2fs with mount points does not work, then just substitute it with a device. Back in your running / restarted VM terminal do the filesystem resize:

$ resize2fs /dev/vda1

Select allOpen in new window

Attention! This is an example - like in my previous sippets. I cannot know your boot device; I assumed the first partition of vda because of your post. So, please find your root dev from the output of mount or df, you need the device mounted at /.

helge000:

Yes, that extension of the image went fast and smooth.  This is excellent of course.

Regarding your 2nd portion.  You mention 'remember to shutdown the VM prior to resizing'.   I assume that the resize2fs needs to be run from inside that same VM so that is confusing.  I believe you just wanted me to to be sure to close it before reopening with the larger image size.  Please clarify on this one line.

Beyond that, assuming you want me to reopen the VM I have done so and from inside I have run resize2fs /dev/vda1 (you are correct as this is my device) I receive the message "The filesystem is already 7339776 blocks long, Nothing to do!"

I think you are trying to extend the filesystem before you extend the partition.  The partition must first be extended isn't that correct ?

Your thoughts ?

Jay Lepore
CompuMatter

Hello,
Sorry, but I think I need to go more deeply into the whole resize/VM thing - I hope I do you not wrong:
Resizing a partition, no matter if you are in a VM or not, breaks down in two steps:
1. Extend the physical volume (Eg. add hard disk space, in a VM with qemu-img). In this step you need to change/modify your hardware. In a Hypervisor, you need to modify the VM parameters.
2. After changing the physical size of your hardware, you need to adjust the file system length. You need to to this with software on your OS.

So, if I mean shutdown your VM, I mean you do changes on hardware level. Like a real world computer, you would shut it down when installing RAM and HDD's ect. If you working with qemu tools, this is like changing the hardware. In your case, the HDD.

After you did the qemu-img resize and the virtual disk has the correct size, you would start your computer and change the filesystem specs there. This is the resize2fs. You do not need to extend the partition! This is already done by qemu-img.

If resize2fs tells you it cannot extend any more, then there are two possible causes:
(1) - you reached the maximum size
(2) - you have another partition blocking the resizing - you there may be no partitions 'in between'.

Please verify all this with parted in comparison with df (in your VM of course):

parted -l /dev/vda1
df -B 512

Select allOpen in new window

Up till now we are on the same page.  I have understood clearly your statements.  
I am guessing we have an 'in between' problem I have here the results of your suggested exercise.  I would guess the 'in between' is the problem but impassible for me !

Here is the screen shot for the first parted -l /dev/vda1 command

Here are the results of the suggested df -B 512 command

I look forward to hearing your further thoughts.

Jay Lepore
CompuMatter

As I said: You have a swap partition after your root partition you wish to extend.

This is why you cannot extend it.
But, and this is the good part, your disk is 86GB in size. You could easily extend swap!
Note: If extending a disk, space is added in the end of the disk. Space to extend a partition needs to be adjacent the the partition you want to extend.

To fix this:
1. switch off swap,
2. delete swap logical / extended partition and verify you have only one left
3, recreate it with parted, using a primary partition in the end of the disk
4. create swap space on the new partition
5. switch swap back on
6. resize your /dev/vda1 with resize2fs - which will now be possible
7. Edit /etc/fstab, modify your swap mount entry to match the new vda2

The relevant commands for swap are:
swapoff
mkswap /dev/vda2
swapon

Hint: Do not run the commands above just this way! You will need to use parted to delete the swap partition and creating it again. For the "start", end parameters use something like about 97% and 100%. This will effectively create it at the end of the HD:

parted /dev/vda mkpart primary 83GB 100%

Select allOpen in new window

If you want exactly 2GB, then you need to calculate the start poinnt. Possible units are MiB,GiB,MB,GB,%,s (sectors).  For more, see man parted.

Hello,

You gave me good information however you assumed a level of command knowledge which I did not have.  

After your comments, I also reviewed the following good resources on this subject:
* http://hexeract.wordpress.com/2012/04/30/how-to-expand-the-root-filesystem-of-a-11-10-ubuntu-running-inside-vmware-player/
* http://luke.bowbak.org/2013/01/24/partitions-thing-of-the-past-1.html
* and many more sites

Together, your simple review, and all of the other sites researched allowed me to create a step by step solution for others to follow which can be seen at

http://wiki.linuxmatter.com/index.php/Resize_a_partition#Expanding_the_partition_to_fill_the_new_drive_size

I will select you as the solution but truly it was a partial solution as your detail was not clear as it could have been and much research had to follow.

Sincerely,

Jay Lepore
CompuMatter

My apologies.  Of course.  I am grateful for your efforts and my problem is certainly solved. You've earned your points and I am happy.

Jay