[SOLVED] Trying to shrink qcow2 image to make space for another one on the proxmox host (image gets corrupted after resize)

[successtheman]

I have an issue here (the purple screenshot is from when I am booted in an ubuntu live iso) and I am unable to fix it but as you can see the device /dev/sda is 414G (the dark black is in proxmox terminal before converting the qcow2 image to raw for resize), but I want to get rid of the unallocated ~142G (shown in the gparted screenshot) and take it down to around 260-270G. It's a qcow2 image and whenever I convert it to raw and resize, the data becomes unreadable.

-proxmox terminal screenshot (host)-


-ubuntu live iso terminal (guest)-


-gparted ubuntu live iso (guest)-


So far my steps are the following:

Before doing any of these I resized the lvm with lvresize etc... you can see from the screenshots

1.

qemu-img convert -p vm-101-disk-0.qcow2 vm-101-disk-0.raw

2.

qemu-img resize --shrink vm-101-disk-0.raw -- -1G

If this step of resizing actually worked I would reduce it to around 272G or so with "qemu-img resize vm-101-disk-0.raw --shrink 272G" and proceed to the next step below, but it doesn't and when I try to check the raw image with parted,

like so

parted -m vm-101-disk-0.raw print | tail -n +3 | awk -F ":" '{print $(NF-2)}'

it says "Error: end of file while reading /var/lib/vz/images/101/vm-101-disk-0.raw" -this works fine before the resize occurs

(If the 2nd step worked I would do this next)

qemu-img convert -p -O qcow2 vm-101-disk-0.raw vm-101-disk-0.qcow2

I did try the 3rd step and when I boot into a live iso and try to check the partitions while having the qcow2 image mounted, it shows no partitions, further reinforcing my theory that something gets corrupted after resizing.

If someone could please help me I would appreciate it, I need to make space to add a new VM and I can't unless I can manage to reclaim the unallocated space within this qcow2 image successfully.

 

[fabian]

I think you are resizing your disk too much? 262G is less than 270.60GB+1.5GB+1M

 

[successtheman]

I think you are resizing your disk too much? 262G is less than 270.60GB+1.5GB+1M

See I would agree with this, however even when I shave just 1G off the disk like so

qemu-img resize --shrink vm-101-disk-0.raw -- -1G

the same result occurs with the raw disk becoming corrupted or so, and I am puzzled as to why this is the case

EDIT: I will update the OP accordingly because you are correct that does pose an issue but I did test further as specified above.

 

[successtheman]

Perhaps I can use virt-sparsify after marking the unallocated space as a cleared partition in gparted so that the OS does not use it? This would avoid the need to resize the disk maybe? I don't know if this would cause an issue with proxmox thinking the disk is still larger than it is though (because there would be a ~141G cleared partition then) so I think resizing it is still the road I need to go by but I could be wrong

 

[leesteken]

What kind of corruption? A virtual drive with a GPT has a backup/secondary GPT at the end of the drive. MBR drives have a similar thing. When you change the drive size (even if you account for all partitions and their sizes), that backup GPT gets broken. This is not a problem if the first/primary GPT is correct but it does show up by various tools as an error. I always boot VMs with a GParted Live CD to fix those kinds of issues (and check and resize partitions to fill the drive after resizing).

 

[successtheman]

What kind of corruption? A virtual drive with a GPT has a backup/secondary GPT at the end of the drive. MBR drives have a similar thing. When you change the drive size (even if you account for all partitions and their sizes), that backup GPT gets broken. This is not a problem if the first/primary GPT is correct but it does show up by various tools as an error. I always boot VMs with a GParted Live CD to fix those kinds of issues (and check and resize partitions to fill the drive after resizing).

It looks like you are right about the partition table, but I don't know how to fix it after I run the resize. Somehow I was finally able to resize the qcow2 image without converting the file to raw first using the following command

qemu-img resize vm-101-disk-0.qcow2 --shrink 272G

After this, gparted says invalid seek or so. Kpartx says that the alternate GPT/partition table is invalid and uses the primary instead and shows partitions on the disk however. If I click ignore in gparted it just shows unallocated space for /dev/sda. I am confused how to proceed

 

[successtheman]

I tried running testdisk, but that didn't do any good and the partition table looks like this now, which is completely wrong sizes

 

[leesteken]

First boot the VM with GParted and reduce the size of the partition inside the VM. Make sure to reduce it enough for you to shrink the qcow2 file. Some software uses GB and some use GiB and they don't always show the right unit: this can be an 8% difference. Then shutdown the VM (from the GUI inside the VM) and shrink the qcow2 file. Then start the VM with GParted again, ignore (or fix?) the secondary GPT (it will be fixed by changing partition sizes anyway) and resize the partition to fill the virtual disk again. Then shutdown (again) and start the VM normally without GParted.
EDIT: I don't have experience with qcow2 shrinking but these steps are quite generic and don't really depend on the storage type (I think).

 

[successtheman]

First boot the VM with GParted and reduce the size of the partition inside the VM. Make sure to reduce it enough for you to shrink the qcow2 file. Some software uses GB and some use GiB and they don't always show the right unit: this can be an 8% difference. Then shutdown the VM (from the GUI inside the VM) and shrink the qcow2 file. Then start the VM with GParted again, ignore (or fix?) the secondary GPT (it will be fixed by changing partition sizes anyway) and resize the partition to fill the virtual disk again. Then shutdown (again) and start the VM normally without GParted.
EDIT: I don't have experience with qcow2 shrinking but these steps are quite generic and don't really depend on the storage type (I think).

As you could see from the first gparted image in the op, I already made free space (the unallocated space) so that part is done and not an issue. I'd already resized it before coming here. The issue is actually getting the partitions to be recognized after resizing.

When I click ignore in gparted while booting from the iso, it just shows unallocated space and no partitions, which is what I am stumped on right now

 

[leesteken]

How do the partitions look inside the VM after shrinking them with GParted but before shrinking the qcow2 virtual disk?

 

[successtheman]

How do the partitions look inside the VM after shrinking them with GParted but before shrinking the qcow2 virtual disk?

They are in the gparted screenshot from the OP

Everything boots as normal in this state as well

 

[leesteken]

They are in the gparted screenshot from the OP

That's more than 272GiB. Try to keep a margin for error of about 8-10% because of alignment and differences between 1024^3 and 1000^3 (7.4%).

qemu-img resize vm-101-disk-0.qcow2 --shrink 272G

,.

Maybe try shrinking to 293G? Or delete some files to shrink /dev/sda3 some more (but I guess you need to shrink the Logical Volumes inside of the ubuntu-vg first to do that)?

 

[successtheman]

That's more than 272GiB.

I resized to around 275G ultimately just didn't update the post, however the GiB vs GB thing might be confusing me

Maybe try shrinking to 293G? Or delete some files to shrink /dev/sda3 some more (but I guess you need to shrink the Logical Volumes inside of the ubuntu-vg first to do that)?

I will post some screenshots of the LVM volumes in a moment

 

[successtheman]

Need to transfer the backup with the working disk (it will be at least 3 hours maybe more), but in the meantime @leesteken here is a screenshot of the output from kpartx showing what I was referring to before

 

[leesteken]

View attachment 44828

I don't know kpartx, but that looks alright. 567486464 sectors of 512B is 270,60GiB. I guess that gdisk /dev/sda can fix the alternate GPT.

 

[successtheman]

@leesteken I restored a working backup from a few months back and I am just going to run a small VM within my Linux VM, it's easier for my purposes and allows me to keep the Linux partition the same size. So I guess this is still unresolved but it's not worth the trouble anymore

 

[successtheman]

@leesteken Happy New Year btw , and thanks for all your help thus far

I now consider this issue solved

These are the steps I followed to fix it

-Follow this guide first
https://www.rootusers.com/lvm-resize-how-to-decrease-an-lvm-partition/

then shrink disk with the following command (replace 1G with size you want disk to be shrunk to)

qemu-img resize --shrink img.qcow2 1G

-Then after shrinking the qcow2 disk follow this guide below to fix the partition table PMBR mismatch error in parted by using the gdisk commands
https://patrakov.blogspot.com/2019/01/resizing-linux-virtual-machine-disks.html

After this the system was complaining about the Logical Volume being smaller than the Physical Volume so I followed the steps from this site https://itecnotes.com/server/linux-sectors-which-is-smaller-than-corresponding-pv-size-error/ and fixed it. Extended the disk a bit with some trial and error and qemu-resize and it finally worked

 

[alex.d]

# virt-filesystems --long -h --all -a img.qcow2
# qemu-img info img.qcow2

qemu-img convert -O raw img.qcow2 img.raw
losetup -f -P img.raw
kpartx -a /dev/loop0
// if resize sda1 , else sda2 loop1p1, else sda3 loop2p1
resize2fs -M /dev/mapper/loop0p1 5G
echo Yes| /sbin/parted -a optimal /dev/loop0 ---pretend-input-tty resizepart 3 6G Yes

kpartx -d /dev/loop0
losetup -d /dev/loop0
qemu-img create -f qcow2 -o preallocation=metadata img-tmp.qcow2 6G
qemu-img convert -O qcow2 img.raw img_tmp.qcow2
rm -r img.raw

virt-resize --expand /dev/sda3 img_tmp.qcow2 img-tmp.qcow2
qemu-img convert -O raw img-tmp.qcow2 img.img
rm -r img-tmp.qcow2

virt-sparsify img.img --convert qcow2 img.qcow2
rm -r img.img


# virt-filesystems --long -h --all -a img.qcow2
# qemu-img info img.qcow2