[SOLVED] Shrink VM unallocated disk size

[Adnan]

I have 2 disks from an old VM I'd like to backup just in case. The first disk is a 1TB disk and has 2 partitions of 500GB. The second disk is a 30GB disk with a partition taking all the space.

First thing I did was to sdelete the 3 partitions, then boot on gparted iso and shrunk every partition to real used size +1GB. Now the first disk is a 1TB disk file, with 2 contiguous 100GB partitions and 300GB of unallocated space. The second disk is 30GB with 1 partition of 3GB and 27GB of unallocated space.

I would like to shrink these disks. I'm testing with the 30GB disk, converting it from vmdk to qcow2 kept it as a 30G disk but it occupies 5G now (ls -lsh). Then I still wanted to shrink the virtual disk, so I tried "qemu-img resize file.qcow2 10G" and even converting it to raw and resizing it, but when booting to gparted the filesystem appeared corrupted. I thought cropping unallocated space shouldn't be an issue...

Is it possible to shrink these disks without ultimately having to create a smaller disk and dd from the first to the other?

 

[AKA]

"qemu-img resize file.qcow2 10G" <= This can't work like that.

You need to shrink the partitions in the OS first before you're resizing it in any case.

I don't know if it will be possible then, because i usually didn't care, because of thin provisioning, that you apparently have too.
So to save work, i'd just leave it like that.

 

[Adnan]

You need to shrink the partitions in the OS first before you're resizing it in any case.

This I'm aware, thank you for pointing it to me. When I talked about "unallocated space" I really meant it, the partition table shows "unallocated space".

I left it like this anyway, but for the sake of knowledge, would it be possible without playing with dd and a second disk?

 

[AKA]

Theoretically i don't see why not. If you boot a live system and DD one disk to another disk (Or just use clonezilla) it should be totally fine.

 

[Adnan]

dd/clonezilla seems to be a "can't fail" method, but would require double the space. Do you think there is an in place method which would work on the file itself no matter its format?

I'm simply trying to understand why cropping the disk in the unallocated space fails... I know the MBR is written in an unallocated space in the front, but I didn't hear about something after the useful data.

Thank you for your answers

-EDIT-: GPT writes at the end of the disk.