Possible to resize a Guest VM's disk?

Latest response

Is it possible to resize a Guest VM's disk? 

I have searched the documentation, and cant find any instructions on how to resize a VMs disk once it has been created and the OS has been installed.

This is something we use frequently in VMWare, and it would be nice to have this feature in RHEV.  Resizing the disk while the machine is online would alo be perfect.


More information on the use case would be appreciated.
It is used to set features priority.



A perfect example would be when we need to expand a data partition on a Virtual Machine due to the application demands growing outside the normal scope of the initial deployemt.

We have EMC Vmax SAN, so to keep storage costs down, we only allocate out as much disk space as the application owner specs.  Frequently, we need to resize the disks of a Virtual Machine (in VMware) to meed the demands of the growing data.

May be, thin-provisioned (TP) disks may be the answer as long as storage supports TP disks...The host can actually see more storage space than actually allocated.


Of course, there is no free lunch..performance impacts should be evaluated agains the workload for TP disks.


It does not eliminate the issue of re-sizing the disks online, but works as an interim solution...


Just a thought !




Dynamic disk resize is not yet implemented and is on the roadmap.


In the meantime, you can add additional disks to the guest and resize the VG and LV inside the guest using that disk to get more storage for the partitions/filesystems already holding data.

I am well aware of how to use LVM, but LVM is not the answer if you have Windows VM's.  :)


Most of our environment is running Windows Server 2008 R2.

(Added on behalf of Aaif Ali after accidentally deleting the wrong duplicate comment)


I think you can resize vmdisk if your vmdisk on shared storage, and you have  
any rhel-6 box on your environments with libguestfs-tools, you can use  
virt-resize which is part of libguestfs , look at man page for more info  
after you install libguestfs-tools

So please do not to it under RHEV environment.


If you'll do this it has to be done outside of RHEV control IE extension of the VM LV in case of block device or just changing the file size for NFS. The records within RHEV database are different and I don't know the full implication of that.


The best solution ATM for already exiting VM will be to add another disk to the VM and use in-guest tools to do the extension. In Linux guest it is easy.


If the VM was not created yet and you are just looking for a methodology to allow extra space in the future then you can utilize a combination of sparse files and the fact that Windows disk manager allows for partition resizing.


1. Create you VM with the desired extra space, example 200G, use Thin provisioning

2. When installing windows create your partitions according to the desired (current) size leaving the rest non-partitioned - Use quick format.


Now the size of the VM image in RHEV will be limited to the size of the partitioned size (+ minor overhead for meta data).


Now you can easily use the partition resizing wizard in Windows Disk Management to extend the partition/s whenever extra size is needed.

I opened a case about this (00525040) this past summer. I ended up coming up with my own workaround. Now, if a Windows admin can hack this together, surely Red Hat can clean it up and publish a KB article for the benefit of all. In the meantime, here is what I've got. It's very rough but it does work.




Primarily used this site as a guide: http://libguestfs.org/virt-resize.1.html


Windows guest used for testing: Windows 2008 R2, 60GB IDE disk, 100MB boot partition and remainder as C: NTFS system partition. For purposes of test, aim was to expand C: drive from ~ 60GB to ~ 70GB.


Steps to workaround:


Exported Windows guest to export domain

Setup RHEL 6.1 guest with access to (NFS) export domain

Registered RHEL guest to RHN and applied all errata (yum update)

Installed libguestfs tools including virt-resize:

yum install '*guestf*'

Ensured that export domain was in "detached" status in RHEV

Mounted NFS share of export domain from RHEL guest to local drive under /mnt/export After navigating the labyrinth of directories, I determined that my exported Windows VM was here:

/mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/master/vms/ b57f6831-b912-4c9d-848f-5c063e52bb9b/b57f6831-b912-4c9d-848f-5c063e52bb9b.ovf

And its associated disk was here:


Determined the device names:

virt-filesystems --long --parts --blkdevs -h -a /mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842


Name Type Size Parent /dev/sda1 partition 100M /dev/sda /dev/sda2 partition 60G /dev/sda /dev/sda device 60G -

So I know it's /dev/sda2 I want to expand. This would be typical for any Windows box Vista and beyond - a 100MB boot partition. Create a new disk to work from, with desired size (using original name with "new" appended at end):

truncate -s 70G /mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842new

run virt-resize (old disk to new disk):

virt-resize --expand /dev/sda2 /mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842 /mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842new


Summary of changes: /dev/sda1: partition will be left alone /dev/sda2: partition will be resized from 59.9G to 69.9G /dev/sda2: content will be expanded using the 'ntfsresize' method Copying /dev/sda1 ... [################################] Copying /dev/sda2 ...

After waiting a very long time for this to finish, I realized this creates a disk in RAW format -- my original disk was COW. So I then converted it:

qemu-img convert -O qcow2 /mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842new /mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842new/mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842new/mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842newqcow2

# conversion step might be avoided by using qemu-img *instead* of truncate to create the new disk, such as: qemu-img create -f qcow2 /mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842newqcow2 70G #

Using vi, edited just one section of the OVF file:

ovf:size="60" to "70"

Changed permissions of new disk to be same as original: -rwxr-----

chmod o-r,u+x 2dbd8375-ffee-474c-8bd9-c97b5f79a842newqcow2

chown 36:36 2dbd8375-ffee-474c-8bd9-c97b5f79a842newqcow2

Moved original file to a backup copy:

mv 2dbd8375-ffee-474c-8bd9-c97b5f79a842 2dbd8375-ffee-474c-8bd9-c97b5f79a842bak Moved new file to original file name:

mv 2dbd8375-ffee-474c-8bd9-c97b5f79a842newqcow2 2dbd8375-ffee-474c-8bd9-c97b5f7 Unmounted NFS

Back in RHEV, attached to export domain Browsed to VM and started import

(VM was moving to a different RHEV manager so there was no concern about a duplicate ID)


Import ran fine and completed. Powered up Windows guest, which ran chkdsk on C: as expected. This was completed with no major errors and the machine rebooted. I logged into machine and verified in Explorer as well as Disk Management that the disk was now 70GB, with the C: drive filled out to use the extra 10GB of space. There was no need to do anything here since virt-resize had already expanded the NTFS file system. Everything appears to work normally.





I did a resize this afternoon of a RHEL 4 KVM guest in RHEV 3.1.   I used a iSCSI storage domain with a preallocated disk.   I tried to use virt-resize ala Daniel's notes above, but virt-resize would not do the sda4 extended partition.   So, I tried to do everything manually based on different notes I had gathered.

Here are my steps:

1) export the guest to the expDomain

2) detach the expDomain

3) find the disk image on the nfs server, for me it was in this directory:

  •  $ ls -al expDomain/4cf5e5b7-8f91-446e-a7e3-1a6485f96495/images/9a9f71e3-af1c-481e-bb48-238a3b333a53/
  • total 67174480
  • -rw-rw-r--  1 vdsm kvm 75161927680 Apr  5 19:31 58977df1-198b-4e8c-ad7b-3bf8b92967b5
  • -rw-r--r--  1 vdsm kvm         328 Apr  5 14:14 58977df1-198b-4e8c-ad7b-3bf8b92967b5.meta
The size was originally 64GB.   Above is the size after resize to 70GB


4) resize using qemu-img, then info to see results:
  • $ qemu-img resize  58977df1-198b-4e8c-ad7b-3bf8b92967b5  +6GB
  • $ qemu-img info     58977df1-198b-4e8c-ad7b-3bf8b92967b5

5) mount and redo the partitions,

  • $ losetup /dev/loop1   58977df1-198b-4e8c-ad7b-3bf8b92967b5
  • $ fdisk -lu  58977df1-198b-4e8c-ad7b-3bf8b92967b5 
  • (get a picture of the start and stop blocks)
  • $ fdisk -u  58977df1-198b-4e8c-ad7b-3bf8b92967b5 
  • > delete partitions 4-9
  • > create partition 4 (extended), and partition  5-8 with the same sizes, partition 9 should extend to the max size.
  • $ losetup -d /dev/loop1

6) attach the expDomain

7) import the guest

8) startup the guest, and run ext2online /dev/vda9

Of course, this was working because I wanted to extend the last partition only.