The problem is, I can’t find anything in the official docs about how to do this. e.g. looking at the man pages, the RHEL virtualization docs and the libvirt site. It makes me think I’m trying to do something wrong. I can see some virsh commands with the word “resize”, but they don’t explain what they actually do, e.g. would the free space appear at the end of the disk on the guest, would it preserve the partition table offsets on the guest (and so on). There’s also a qemu command where you can manipulate the qcow2 image.
Yes, you need to use qemu-img to resize, and then inside the machine depending on your partition layout, if standard partitions, then growpart from cloud-utils-growpart package can be used or if LVM, then the normal way with LVM.
So with qemu-img:
qemu-img resize vm_disk.qcow2 20G
will increase it to 20GB in size (but be careful, if image size was 40GB then you end up reducing it and losing data). You can also use the plus symbol to increase by X amount so:
qemu-img resize vm_disk.qcow2 +10G
will add 10GB to the existing image size, whatever that may be. Of course with the VM powered off when you attempt to do this.
After this you can boot the VM and use growpart, or LVM tools to resize the partition within the VM, and filesystem.
I was hesitant to use the qemu commands due to this alarming text from the RHEL docs
While QEMU is an essential component of the architecture, it is not intended to be used directly on RHEL 8 systems, due to security concerns. Therefore, using qemu-* commands is not supported by Red Hat, and it is highly recommended to interact with QEMU using libvirt.
But for qcow2, it makes sense to use the qemu command.
I’ll make some notes about the partition sizes before and after.
Seems strange that they say that. I don’t know of any libvirt commands that can actually resize a disk, so the qemu-tools are pretty much the only real way to do it. Although I haven’t found anything via a quick google, I could be wrong.
Generally, if I’m going to resize to a specific size without the + sign, then I just check the size of the existing image first, for example:
so the 41GB ones, I could effectively then use the first command I gave you, but replace 20 with 60. Or, use the second command and just do +20G which would effectively be the same.
The shrink script I have is when I prepare OpenStack images, if I create the VM with 10GB, then the disk image is 10GB. But I don’t want to upload empty space to OpenStack, so I shrink it to the used disk space size, which can be about 1GB for a minimal install. Shrinking is done like this:
qemu-img info /vms/vmg/vmg01.qcow2
virtual size: 10 GiB
qemu-img resize /vms/vmg/vmg01.qcow2 +10G
qemu-img info /vms/vmg/vmg01.qcow2
virtual size: 20 GiB
After starting the guest and logging in, I see all partitions are exactly as before except that there’s new free space at the end of the disk, which is what I wanted.
I also found more detail in ‘man qemu-img’. The top of the man page is just a summary of the commands, but scrolling down, it shows each command in more detail. For the resize command, it also shows a --shrink option, which could be an alternative to using ‘convert’ (but slightly less safe).
Actually the shrink parameter is not the same as what the convert command does. All the convert parameter does is keep the disk/partition parameters the same, just shrinks the size of the qcow2 image. This is like going from a thick-provisioned disk to a thin-provisioned one. To all intent and purposes, the image still think it is set for 10GB, 20GB or whatever disk size was chosen when creating the VM.
The shrink parameter in conjunction with the resize means that if you haven’t resized the partitions and filesystems within the VM, you will lose data. So completely different type of command.