Possible to resize a Guest VM's disk?
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.
Responses
More information on the use case would be appreciated.
It is used to set features priority.
Thanks,
Simon
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 !
Regards,
Dharmesh.
(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:
/mnt/export/c2b0fea0-44ad-4969-88dd-0194b39f1442/images/72d4207c-5b6b-404c-825a-846d2ec5fc40/2dbd8375-ffee-474c-8bd9-c97b5f79a842
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
Output...
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
Output...
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
- $ 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.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
