Reclaiming dynamically expanding VHDX space

As anybody who knows about dynamically vhdx files will be aware is if you delete stuff or do disk cleanup e.g. to remove Windows.old, although the spaced is logically freed, it is not physically removed as far as host OS is concerned.

The upshot is the vhdx files just keep growing until they meet the maximum size and then behave more like a fixed size vhdx file.

There is a clean option you can use to attempt to reclaim this space but it does not work that well, hardly saving anything.

I experimented with a variety of methods and decided cloning vhdx file to another new vhdx file would be easier using Macrium Reflect.

I tried this and found it could be temperamental in reclaiming space i.e. it only fully reclaims space if new vhdx is rather smaller then original. I attribute that to the fact when you clone a system using Reflect to the same size drive, it does not "defrag" the clone i.e. some of that unclaimed space also gets copied.

So I tried an experiment by creating same size vhdx file, but deliberately reducing size of drive partition as shown below (drag and drop efi, msr, C drive, right click on C drive and reduce it in size, then drag and drop recover partition)

I then cloned it and the original vhdx file which had grown to around 69 GB was reduced to just over 45 GB.

It was then a simple matter using minitool to move recovery partition to end, and then expand C drive to fill all unallocated space.

I tried this method on several vhdx's and it worked 100% reliably in all cases.

<---(newb) are you cloning from inside the VM? is that the trick to reclaim space?

vannn said:

<---(newb) are you cloning from inside the VM? is that the trick to reclaim space?

Click to expand...

No much simpler. I just mount vhdx file on host OS as a drive and clone to a blano vhdx created on host OS.

The reclaim space happens because when you clone a drive with Macrium Redlect to a smaller C drive, Macrium Reflect effectively defrags drive at same time as reclaiming used apace.

It's a bit like when you delete a file, the space is not actually freed which is why you can recover deleted files.

Interesting.
So shrinking c drive is really needed here?
I assume leaving it as is then Reflect will use intelligent copy and not copying empty space where deleted files are.
Keep in mind that I look from (image) 'restore' mode not from 'clone' mode but hoping cloning also supports intelligent copy. Otherwise you do need to shrink.

cereberus said:

It was then a simple matter using minitool to move recovery partition to end, and then expand C drive to fill all unallocated space.

Click to expand...

I usually place this as the first one during restore drag n drop (and enlarge it a bit) since it's the default location on clean installs. It usually gets moved / recreated at the end by OS upgrades when the size is deemed too small.

This has always been good enough for me: Open Hyper-V Manager, select Edit Disk...., Select the VHDX, click Next, make sure Compact is selected, and click Finish. Before:



After:



OR from Kyhi:
mount and defrag (optimize) vhd
then type
diskpart
select vdisk file="X:\NAME.vhd"
Compact vdisk
exit

There have been some reports that using sdelete first will help reclaim more free space:

NavyLCDR said:

This has always been good enough for me: Open Hyper-V Manager, select Edit Disk...., Select the VHDX, click Next, make sure Compact is selected, and click Finish. Before:

View attachment 55415

After:

View attachment 55416

OR from Kyhi:
mount and defrag (optimize) vhd
then type
diskpart
select vdisk file="X:\NAME.vhd"
Compact vdisk
exit

There have been some reports that using sdelete first will help reclaim more free space:

SDelete - Sysinternals

Securely overwrite your sensitive files and cleanse your free space of previously deleted files using this DoD-compliant secure delete program.

learn.microsoft.com

Click to expand...

Compact really does not work that well regrettably. Sdelete is more hassle than it is worth.

Hopachi said:

Interesting.
So shrinking c drive is really needed here?
I assume leaving it as is then Reflect will use intelligent copy and not copying empty space where deleted files are.
Keep in mind that I look from (image) 'restore' mode not from 'clone' mode but hoping cloning also supports intelligent copy. Otherwise you do need to shrink.

I usually place this as the first one during restore drag n drop (and enlarge it a bit) since it's the default location on clean installs. It usually gets moved / recreated at the end by OS upgrades when the size is deemed too small.

Click to expand...

I do not know why but it just works better when shrinking C drive. It only takes a few seconds to re-size after.

cereberus said:

Compact really does not work that well regrettably. Sdelete is more hassle than it is worth.

Click to expand...

More hassle than resizing partitions and cloning drives? Have you been taking lessons from Jimbo45 on the "easy" way to do things?

NavyLCDR said:

More hassle than resizing partitions and cloning drives? Have you been taking lessons from Jimbo45 on the "easy" way to do things?

Click to expand...

HaHa - its just that cloning Reflect takes about 4 minutes max, and I do not have to remember syntax.

I tried sdelete anyway and it never seemed to work properly.

Sdelete works every time here.
It does grow the disk to full size after the zero-fill. Afterwards you need to compact.

I will try again but never had much success in the past.

Hopachi said:

Sdelete works every time here.

Code:

sdelete64.exe c: -z

It does grow the disk to full size after the zero-fill. Afterwards you need to compact.

Click to expand...

I did not try sdelete, only posted what I found. Sounds like that process of first growing the vhdx file out to full size and then compacting may indeed be a longer process with more writes than cloning, if there is not much space in use in the vhdx file.

Hopachi said:

Sdelete works every time here.

Code:

sdelete64.exe c: -z

It does grow the disk to full size after the zero-fill. Afterwards you need to compact.

Click to expand...

Totally failed for me - this is after compact. You can see copy before I started.

KYHI said:

Optimize-VHD (Hyper-V)

Use this topic to help manage Windows and Windows Server technologies with Windows PowerShell.

learn.microsoft.com

Click to expand...

I have tried these and only limited success.

Why not just image the system, create a new vhdx of the size you what (dynamic or fixed) and restore. If it fails to boot then simply re-install the boot loader for that windows install (won't kill other windows systems if you have them on the same or even other disks). (bcdboot c:\windows etc etc).

Cloning assuming it means what cloning should do is to "replicate" byte for byte" source and target disks so presumably the disk "Geometry" of both source and target will be the same even if you can "resize" partitions on the target disk.

Or have I missed or not understood something here.

Slightly to another topic --if you keep the Windows OS small on the vhdx file is there any advantage in using a "dynamically expanding vhdx" file as opposed to a "maximum=xxxx" type=fixed when creating the vhdx file if you aren't changing your base Windows OS a lot.

Cheers
jimbo

jimbo45 said:

if you keep the Windows OS small on the vhdx file is there any advantage in using a "dynamically expanding vhdx" file as opposed to a "maximum=xxxx" type=fixed when creating the vhdx file if you aren't changing your base Windows OS a lot.

Click to expand...

Yes, if space is limited. When you boot a dynamically expanding vhdx there must be enough free space for it to temporarily expand to its maximum size. If there isn't you get a 'not enough space' BSOD at boot.



If you use a fixed size vhdx there may not be enough space to add another native boot vhdx. By using expanding vhdx I've managed to get a choice two that I can boot from, where there would only be space for one if they were a fixed size.

Bree said:

Yes, if space is limited. When you boot a dynamically expanding vhdx there must be enough free space for it to temporarily expand to its maximum size. If there isn't you get a 'not enough space' BSOD at boot.

If you use a fixed size vhdx there may not be enough space to add another native boot vhdx. By using expanding vhdx I've managed to get a choice two that I can boot from, where there would only be space for one if they were a fixed size.

Click to expand...

Same here - I have at least 5 vhds nominally 100 gb each. However each only uses ariund 50 GB. Of O used fixed size, I would permanently reserve 250 GB extra. As I only run one at a time, I only need to use extra 50 GB to run as you say.

cereberus said:

Totally failed for me - this is after compact. You can see copy before I started.

View attachment 55755

Click to expand...

Interesting. I'll try more tests. I'll give it a try with mounted VHDX to see if it makes a difference.
Looks to me from the screenshot as if it didn't even touch the disk. But the date confirms modification. Then it shrinks to exact same size... or what.

Is that with mounted VHDX? Did you see if it grows to full size after Sdelete is done?

Note:
So far I always ran the Sdelete process from inside the VM.

NavyLCDR said:

I did not try sdelete, only posted what I found. Sounds like that process of first growing the vhdx file out to full size and then compacting may indeed be a longer process with more writes than cloning, if there is not much space in use in the vhdx file.

Click to expand...

Good point. For disks with a lot of file operations to be taken into account.
But as for an average disk, there are considerable writes either way; to new VHDX file (clone) or you overwrite to same VHDX file (sdelete).

The zero-fill writes zeroes covering all free space, the disk will grow to full size. Then compact will have effect on the zeroed-out space.

The only advantage I see is that you don't create extra file like with cloning; might be useful in some cases; but you do need the extra space when it grows.