How to resize a qcow2 disk image on Linux

resize_disk_image.md

How to resize a qcow2 disk image on Linux

This example takes olddisk.qcow2 and resizes it into newdisk.qcow2, extending one of the guest's partitions to fill the extra space.

1. qcow2 format

1.1. Verify the filesystems of olddisk.qcow2

virt-filesystems --long -h --all -a olddisk.qcow2
# Name       Type        VFS   Label            MBR  Size  Parent
# /dev/sda1  filesystem  ntfs  System Reserved  -    50M   -
# /dev/sda2  filesystem  ntfs  -                -    39G   -
# /dev/sda3  filesystem  ntfs  -                -    513M  -
# /dev/sda1  partition   -     -                07   50M   /dev/sda
# /dev/sda2  partition   -     -                07   39G   /dev/sda
# /dev/sda3  partition   -     -                27   513M  /dev/sda
# /dev/sda   device      -     -                -    60G   -

Tip: On ArchLinux the virt-filesystems tool is under the guestfs-tools package. So just try a sudo pacman -Sy guestfs-tools

1.2. Create a newdisk.qcow2 disk image with the new size (E.g 50GB)

qemu-img create -f qcow2 -o preallocation=metadata newdisk.qcow2 50G

1.3. Perform the resizing from old disk image to newdisk.qcow2

Note: "/dev/sda2" is a partition inside the olddisk.qcow2 file which we want to resize.

virt-resize --expand /dev/sda2 olddisk.qcow2 newdisk.qcow2

Done! Enjoy your new space!

2. Raw format (optional alternative)

If you want to create a raw disk instead of a qcow2 try following steps.

2.1. Extend the size of olddisk.qcow2 to the specified size (E.g +10GB)

Note: This will create a new image newdisk.qcow2 with the given size.

truncate -r olddisk.qcow2 newdisk.qcow2
truncate -s +10G newdisk.qcow2

2.2. Apply resizing

Note: "/dev/sda2" is a partition inside the olddisk.qcow2 file which we want to resize.

virt-resize --expand /dev/sda2 olddisk.qcow2 newdisk.qcow2

2.3. Quick inspection of new disk image

qemu-img info newdisk.qcow2
# image: newdisk.qcow2
# file format: raw
# virtual size: 50 GiB (53693907968 bytes)
# disk size: 36 GiB

2.4. Verify that the filesystems have grown as expected

virt-filesystems --long -h --all -a newdisk.qcow2
# Name       Type        VFS   Label            MBR  Size  Parent
# /dev/sda1  filesystem  ntfs  System Reserved  -    50M   -
# /dev/sda2  filesystem  ntfs  -                -    49G   -
# /dev/sda3  filesystem  ntfs  -                -    513M  -
# /dev/sda1  partition   -     -                07   50M   /dev/sda
# /dev/sda2  partition   -     -                07   49G   /dev/sda
# /dev/sda3  partition   -     -                27   513M  /dev/sda
# /dev/sda   device      -     -                -    50G   -

For more details and examples please take a look at the official documentation: https://libguestfs.org/virt-resize.1.html

In case anyone is updating cloud-img, and run into grub rescue Try following

Identify the partition using virt-filesystems and install grub on that new partition. /dev/sda is just and example

virt-customize -a newdisk.qcow2 --run-command 'grub-install /dev/sda'

bruh, thanks a lot

i used the second option , everything succeeded but i got this error when starting with new image
i have made a snapshot of this vm.

➜  images sudo virsh start arch-vm
[sudo] password for anish:
error: Failed to start domain 'arch-vm'
error: internal error: process exited while connecting to monitor: 2025-02-26T15:25:29.843171Z qemu-system-x86_64: -blockdev {"node-name":"libvirt-2-format",
"read-only":false,"discard":"unmap","driver":"qcow2","file":"libvirt-2-storage","backing":null}: Image is not in qcow2 format

@anisharaz If you created a raw-format image (instead of a qcow2 image), you'd need to update your virtual machine config accordingly. Your arch-vm is clearly attempting to load the filesystem as a qcow2 image, but "the second option" creates a raw image instead, despite the filename.

(I don't know why anyone would name their raw image foo.qcow2, that seems horribly confusing. I usually name mine foo.img. foo.qcow2 is reserved for images in the qcow2 format.)

@futpib

Why not just do this?

cp macOS.qcow2 macOS-backup.qcow2
qemu-img resize macOS.qcow2 +100G

qemu-img doesn't actually resize the partitions, it just resizes the "container". So really, when resizing partitions, running qemu-img is just preparation for running virt-resize. That does resize the partitions, but cannot resize in-place.

So there's no point in resizing your original image, because you're going to have to give virt-resize a separate "from" image (container size doesn't matter) and "to" image (container needs to be the new, larger size) to work with.

So you might as well create a new, empty "to" image at the correct new size, then virt-resize from your (unchanged) old image to the (larger) new one, rather than resizing your source image (with or without a backup). Even if you qemu-resize the source image, you still need a new destination image of the same size before running virt-resize.

Thanks @brunurd and @isumix for pointing that out. Fixed in revision #8.