Today, one of my VMs needs to have its disk increased. I’m using qcow2 as the VM’s storage. Here is one way to expand the storage that it’s been proven to work very well for me.
I already increased this VM’s disk to 30GiB once already, but it wasn’t enough. So here, let’s explode it to 50GiB. The name of the qcow2 file is hosta.qcow2
. A friendly reminder that you should alway shave a backup before you perform any critical change such as this one. (I use ZFS, so all I had to do was snapshoting this whole dataset.)
Let’s check what is the current size.
# qemu-img info hosta.qcow2
image: hosta.qcow2
file format: qcow2
virtual size: 30 GiB (32212254720 bytes)
disk size: 1.18 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: true
refcount bits: 16
corrupt: false
Let’s add 20GiB to this disk to make it to 50GiB.
# qemu-img resize hosta.qcow2 +20G
Image resized.
Next we need to resize the filesystem on this disk. There are a few ways to do this such as attaching this hostq.qcow2
to another VM and expand it there, or just manually grow the LVM volume group in my case. However, I found a really cool way by using the virt-resize command.
# cp hosta.qcow2 hosta-orig.qcow2
Then carefully instruct the virt-resize to expand the correct partition. On my server, /dev/sda1 is used for /boot and /dev/sda2 is used as a LVM physical volume.
There is a nice trick to display the disk filesystem on a (KVM) VM.
# virt-filesystems --long -h --all -a hosta.qcow2
Name Type VFS Label MBR Size Parent
/dev/sda1 filesystem xfs - - 1014M -
/dev/cl/root filesystem xfs - - 27G -
/dev/cl/swap filesystem swap - - 2.0G -
/dev/cl/root lv - - - 27G /dev/cl
/dev/cl/swap lv - - - 2.0G /dev/cl
/dev/cl vg - - - 29G /dev/sda2
/dev/sda2 pv - - - 29G -
/dev/sda1 partition - - 83 1.0G /dev/sda
/dev/sda2 partition - - 8e 29G /dev/sda
/dev/sda device - - - 50G -
From the above output, we can see that the /dev/sda has already been expanded to 50GiB. But the /dev/sda2 is still only 29GiB (1GiB has been allocated to /dev/sda1 for the Boot partition.) So let’s expand the /dev/sda2.
# virt-resize --expand /dev/sda2 hosta-orig.qcow2 hosta.qcow2
[ 0.0] Examining hosta-orig.qcow2
**********
Summary of changes:
/dev/sda1: This partition will be left alone.
/dev/sda2: This partition will be resized from 29.0G to 49.0G. The LVM PV
on /dev/sda2 will be expanded using the ‘pvresize’ method.
**********
[ 3.7] Setting up initial partition table on hosta.qcow2
[ 4.8] Copying /dev/sda1
[ 6.9] Copying /dev/sda2
100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
[ 30.3] Expanding /dev/sda2 using the ‘pvresize’ method
Resize operation completed with no errors. Before deleting the old disk,
carefully check that the resized disk boots and works correctly.
Let’s verify our result.
# virt-filesystems --long -h --all -a hosta.qcow2
Name Type VFS Label MBR Size Parent
/dev/sda1 filesystem xfs - - 1014M -
/dev/cl/root filesystem xfs - - 27G -
/dev/cl/swap filesystem swap - - 2.0G -
/dev/cl/root lv - - - 27G /dev/cl
/dev/cl/swap lv - - - 2.0G /dev/cl
/dev/cl vg - - - 49G /dev/sda2
/dev/sda2 pv - - - 49G -
/dev/sda1 partition - - 83 1.0G /dev/sda
/dev/sda2 partition - - 8e 49G /dev/sda
/dev/sda device - - - 50G -
On the background, virt-manager actually created a temporary VM, perform the disk expansion, virt-filesystem check and remove that VM upon completion.
Read more here: