Reclaim disk space breaks VM disk

[LostInCompilation]

Describe the issue When clicking on Reclaim Space for a Windows11-ARM64 VM, the disk gets corrupted and Windows cannot boot anymore. The behavior is a bit off, after clicking Reclaim Space, the progress wheel finishes about 1/4 and suddenly the process finished. A 30GB big disk gets shrunken down to around 7GB, while the real occupied space by Windows11 + software should be around 20GB. So 7GB is definitely not possible. No compression has been used on this VM.

The error occurred a few weeks ago the first time, with an old Windows11-ARM VM. I tried reinstalling Windows 11 on the same disk (formatted beforehand) and the error appeared again. I use sdelete C: -z command inside the VM to zero out disk space since a long time. I also created a completely fresh VM with a new disk and installed Windows 11 ARM, there Reclaim Space works normally. So something with the uploaded VM disk seems to break the Reclaim Space feature. I uploaded the whole VM with a size of about 34GB.

Configuration

• UTM Version: 4.5.3 (99)
• macOS Version: 14.6
• Mac Chip: M1 Pro

Upload VM Since I need the storage space, please let me know when you come back to this issue. I will then upload the VM.

[lgrachov]

When clicking the Reclaim Space button, it shows an alert saying that the action is dangerous. The Reclaim Space feature is still experimental

[LostInCompilation]

I know that. But since it worked flawlessly with the VM in question for almost 2 years, something with the VM disk or a change in Reclaim space causes an issue.

[lgrachov]

But since it worked flawlessly with the VM in question for almost 2 years

I guess they changed how the feature works? If they changed how it works, you can just read the change log.

something with the VM disk or a change in Reclaim space causes an issue.

Since there is no way to actually reclaim space, UTM does it by converting the drive to the same format, but with a different size. I guess that it failed to properly detect the disk size or calculate the disk size so it failed.

[LostInCompilation]

Since there is no way to actually reclaim space, UTM does it by converting the drive to the same format, but with a different size. I guess that it failed to properly detect the disk size or calculate the disk size so it failed.

I don't know what you mean with that, since creating the new QCOW2 image omits zero space previously allocated in the disk image.

[lgrachov]

I don't know what you mean with that, since creating the new QCOW2 image omits zero space previously allocated in the disk image.

Well, the code for the Reclaim Space button says that it converts it.

[osy]

I am not able to reproduce the issue so I'm guessing it's something broken in qemu-img...

[LostInCompilation]

Do you need the whole VM disk image? I can upload it.

[osy]

That won't help, I need a way to consistently break it

[sudocurse]

Experienced the same thing for a 47GB disk on a linux arm64 VM. Shrank to 6GB but wouldn't boot. Grub rescue:

> ls
(hd0) (hd1) (hd1,gpt3) (hd1,gpt2) (hd1,gpt1) (hd2)
> ls (hd1,gpt2)
(hd1,gpt2): Filesystem is ext2. 

(I tried to ls the rest; all say filesystem is unknown except ls (hd2) says error: sector sizes of 262144 bytes aren't supported yet.)

> ls (hd1,gpt2)/boot

> ls (hd1,gpt2)/home

>

so nothing seems to be left in this image lol

[sudocurse]

Ran this on the image in the utm bundle:

> qemu-img check -r all /path/to/my/image.qcow2                                                                                                       
No errors were found on the image.
225331/1048576 = 21.49% allocated, 95.98% fragmented, 95.52% compressed clusters
Image end offset: 4881252352