Windows 10: Compacting virtual hard disks

Compressing a vhdx file in Hyper-V

Well I have had fun today trying to compress some vhdx files used in Hyper-V.

My VHDXs only had around 15GB of files (10 pro Insider 15061) including hidden files after disk cleanup when in Hyper-V but the vhdx files were around 40 GB/

Tried following

1) to compact it using Hyper-V compact - no change

2) mounted vhdx as drive in host and used vdisk compact - no change

3) backed up vhdx using Macrium Reflect, deleted partition and restored - no change.

4) shrunk c drive to minimum size with partition wizard - no change

5) shrunk c drive to minimum size and expanded to full size with partition wizard - no change

6) backed up c partition from 5 above (deleting c partition in vhd in Macrium) and restored with Macrium - no change


So I did this then

7) deleted c drive partition in vhdx from disk management, and then restored c drive using Macrium (said full copying)- no change!

8) So I then created a new vhdx and restored the image backup to new vhd (Hoooray - file now only 15 GB)

9) renamed old vhdx with .bak and renamed new one to old name and ran hyper-v - would not boot.

Back to trusty Macrium - booted from Rescue Drive and used "fix windows boot problems" - SUCCESS!

So sequence is

a) mount vhdx in hyper-v, use disk cleanup etc.

b) mount vhdx in host disk management

c) shrink c drive to minimum, the re-expand to full size using minitool partition wizard or similar

d) image backup vhdx using Macrium Reflect

e) create new vhdx

f) restore image backup from Macrium Reflect to new one (renaming old to .bak and new name to old name).

g) repair boot files using Macrium in hyper-v if needed.

In hindsight, not sure if step c is needed. More testing needed.

:)

 

Windows Phone Emulator

Windows Phone Emulator is unable to set the VHD on the virtual machine:

Couldn't change Virtual hard drive of the virtual machine: 'Emulator 8.1 WVGA 4 inch 512MB.mahtab' failed to add device 'Virtual Hard Disk'. (Virtual machine ID D8FA0783-159E-4189-B8FC-7B0F9E0301C7)

The storage where the virtual hard disk is located does not support virtual hard disk sharing.

'Emulator 8.1 WVGA 4 inch 512MB.mahtab': Cannot get information for attachment '...\Local\Microsoft\XDE\8.1\dd.480x800.512.vhd'. (Virtual machine ID D8FA0783-159E-4189-B8FC-7B0F9E0301C7)

The storage where the virtual hard disk is located does not support virtual hard disk sharing.

how can I solve it?

 

Windows 10 Pro Error codes returned after failing making a second System Image Backup

After creating a successful image backup on my second hard drive, I placed that backup into an
identifiable folder. Then I perform some system changes and start an image bakup again however it will now fail with the following error messages/codes:

- There was a failure compacting the virtual hard disk on the backup location. (0x80780151).

-Additional Information:

The process cannot access the file because its being used by another process. (0x80070020).

After a reboot its possible to create a system image backup again.

This was not happening with Windows 8.1 Pro

How to execute a second System Image backup that will avoid this failure?

 

Sounds like a fun trip indeed! I'll give that a shot with VMware Fusion VM too. Keep you posted.

Cheers

 

Never had a problem compressing vhds when I used VMWARE. Issue seems to be with vhdx files.

 

I do this inside the VM before compacting - Defrag to consolidate free space then use sdelete to zero.

It works much better than just compacting the vhdx. Code: { $Command = "C:\Windows\System32\defrag.exe" $Parms = "C: /h /x" $Prms = $Parms.Split(" ") & "$Command" $Prms $Command = "C:\Windows\System32\defrag.exe" $Parms = "C: /h /o" $Prms = $Parms.Split(" ") & "$Command" $Prms $Command = "C:\Users\Hali\OneDrive\Programs\SysinternalsSuite\sdelete.exe" $Parms = "C: /z" $Prms = $Parms.Split(" ") & "$Command" $Prms }[/quote] Probably the save restore route with Macrium would be just as good (or better) but it is sometimes easier to run a script I think...

 

Probably the save restore route with Macrium would be just as good (or better) but it is sometimes easier to run a script I think...[/quote] I always avoid defrag as it usually takes so long. Minitool does the same in effect in a fraction of the time.

What does sdelete do?

Edit: I have just seen this

Compacting Client Hyper-V VHDX Files • Helge Klein

 

Please do not take this wrong, I just have to say that your process involves awfully lot unnecessary work!

To start with, a dynamically expanding VHD can only grow. It never shrinks, that's not what Compact Disk means. Each checkpoint, even when later removed makes VHD bigger, and so on.

My workflow when I want to free unnecessary space used by my dynamical VHDs:

• Disk clean-up
• Create Macrium image of my VM
• Shut down VM
• Replace existing VHD with new dynamically expanding one in VM settings
• Restore Macrium image to new VHD

Can't understand why you mount VHD in host, can't understand why to save old VHD as .bak when Macrium Image exists.

Of course I also export all new Hyper-V virtual machines as soon as I have finished installing Windows, when the VHD file size is smallest. If then later I want to start from scratch, from freshly installed Windows, I just delete the VM and import it back.

 

sdelete writes zeros to free space. If you do run it note it takes a long time (much longer than defrag) and sits on 100% complete for ages before it finishes. It is tempting to think it isn't working but it is - just need to let it finish.

I have it as part of a script that compacts the OS, removes apps I don't want, runs disk cleanup and so on. I just let it run after upgrade/clean install. The whole script takes an hour to run I guess but it saves thinking.

 

op

Re. .bak - just cautious - I delete after I verify new vhd works.

What I found was that exporting vhdx using mrf alone and reimporting to new vhdx did not shrink the vhdx to minimum size possible. The minitool step does that (basically a defrag).

Sure you can do this inside vm - just found it faster doing in host.

 

We must have totally different working methods *Smile

Let's see what I told to be my workflow, and check how that works in reality. Example W10 x64 VM is one I have used for ESDtoISO and UUPtoISO testing, a clean installed build 15048 with no additional software installed, upgraded several times to builds 15055, 15058, 15060 and 15061, always restored back to clean 15048. This has of course caused the VHD size to grow to multiple times what really is needed.

After the above, checking file sizes. Macrium image was made when the original 64 GB dynamically expanding VHD was 34.5 GB:




Macrium image size just under 5 GB:

After restoring Macrium image to a new dynamically expanding VHD, file size is 9.3 GB. Over two thirds smaller than original one:




The same as seen by File Explorer, yellow highlight is the original VHD, start situation, and green highlight the new VHD where Macrium image from old VHD was restored. Old VHD can now be deleted, net storage save savings over 25 GB in this example case:




(Notice that VHD has already grown over 0.5 GB since the previous screenshot a few minutes earlier. This is because in previous screenshot VM was not started yet after restoring the image.)
This of course is all logical, happens every time.

 

Just did a similar test. I have a clean install of 10561 with about 300MB of programs installed.

Before doing anything the VHDX was 10.54GB. I reduced the size of Windows to 6.50GB.
Ran defrag free space and slab consolidation (took less than 1 minute) and sdelete (took 40 minutes)

Compact option in Edit disk in Hyper-V reduced the VHDX to 7.38GB. Save and restore using Macrium reduced it to 6.65GB.

So it seems Macrium is more efficient but IMO more of a faff.

Code: Microsoft Drive Optimizer Copyright (c) 2013 Microsoft Corp. Invoking free space consolidation on (C... Pre-Optimization Report: Volume Information: Volume size = 21.99 GB Free space = 15.49 GB Total fragmented space = 35% Largest free space size = 10.97 GB Note: File fragments larger than 64MB are not included in the fragmentation statistics. The operation completed successfully. Post Defragmentation Report: Volume Information: Volume size = 21.99 GB Free space = 15.49 GB Total fragmented space = 34% Largest free space size = 10.98 GB Note: File fragments larger than 64MB are not included in the fragmentation statistics. Microsoft Drive Optimizer Copyright (c) 2013 Microsoft Corp. Invoking slab consolidation on (C... The operation completed successfully. Post Defragmentation Report: Volume Information: Volume size = 21.99 GB Free space = 15.49 GB Allocation Units: Slab count = 702 In-use slabs = 223 Slab Consolidation: Space efficiency = 100% Recovered space = 1.71 GB Retrim: Total space trimmed = 4.15 GB SDelete v2.0 - Secure file delete Copyright (C) 1999-2016 Mark Russinovich Sysinternals - www.sysinternals.com SDelete is set for 1 pass. Free space cleaned on C:\ 1 drive cleaned. Press Enter to return to menu:[/quote] Before





After running Compact in Edit Disk





After save/restore using Macrium

 

Thanks guys - I must have had some other issue. I will try again.

It is interesting how compact works in lx07 example on same vhd using batch file. I agree running a batch is possibly less of a faff, but plus of Macrium route is less risk as original vhdx is not touched.

 

Yesterday I did exactly that but when I restored Macrium image to a new vhdx, I ended up with a 38 GB vhdx even though actual install was less than 20GB. What seemed to be causing issue was that I had a partition at end of vhdx after the C drive.

So I created new vhd reordering partitions so C drive was last but it still did not shrink below 38 GB. No idea why though.

So, I tried again but this time I restored Macrium image to a new vhdx with same reordered partitions so C drive was last, and this time made sure vhdx was initially only slightly larger that all the partitions actual used space (so Macrium was forced to shrink the C drive to fit).

This worked creating a <20 GB vhdx file. Then it was a simple case of expanding vhdx file in hyper-v and extending C drive to fill unallocated space.