Differencing Hard Disk - Hyper-V

cereberus said:

Obviously, the merging algorithm is really space inefficient.

Did you compact the merged VHDX?

In elevated Command Prompt, run DISKPART.

Select your VHD / VHDX file:

select vdisk file=X:\YourVHDX_File.vhdx

Compact it:

compact vdisk

You should get best results when compacting both child and parent before merge, then again the merged VHDX.

Kari

Kari said:

Did you compact the merged VHDX?

In elevated Command Prompt, run DISKPART.

Select your VHD / VHDX file:

select vdisk file=X:\YourVHDX_File.vhdx

Compact it:

compact vdisk

You should get best results when compacting both child and parent before merge, then again the merged VHDX.

Kari

I will try but I have never found the compact function to ever do that much.

I basically manually compact vhds by shrinking partitions using minitool partition wizard, and then copy shrunken partitions to a new vhd to reclaim space, and then expanding partitions again etc.

Compacting had little benefit but never mind.

More importantly, I managed to mount my differencing drive using attach from disk management (for some reason FE mount will it work on my pc), created a boot entry and after a bit of faffing with drivers (specific to my laptop amd sata controller), and I sucessfully booted into the differencing drive on host - hip hip hooray!

The possibilities are endless now. It is just a shame you cannot upgrade VHDs on host and have to go by Hyper-V.

Kari said:

Decided to show how I use differencing disks, and how I benefit from them. Apparently, as your edits show, you already found answers to your questions, but maybe this helps other members to understand the concept.

Some facts first. Differencing disks means that a VM uses a so called child VHD for an existing parent VHD. The parent VHD remains intact, in fact it can even be write protected. All changes made to VM are saved to child VHD. In some sense you could call it "checkpoint on steroids"; create a new VM using a child VHD, test your stuff, when done delete the VM and its child VHD to undo changes. Parent VHD is still there, repeat the process to test something else.

A differencing disk is always dynamically expanding, it can't be created as fixed size VHD. It's maximum size cannot be set by user, it can expand endlessly until the drive where it is stored has no more free space for it to expand.

One reason I use differencing disks is to save storage space on my dedicated Hyper-V partition. I use it mainly for two slightly different scenarios. Another good reason is how fast it is to create new virtual machines.

 Scenario 1: Different W10 versions

I installed Windows 10 version 1803 on a Hyper-V VM, When done, I simply deleted the VM, leaving only its VHDX file on my Hyper-V VM partition. I renamed that VHDX file as W10 1803 Base.

Next, I created three differencing virtual hard disks, naming them W10 Insider Preview Fast, W10 Insider Preview Skippy, and W10 version 1803. All three are using the same base, parent VHD W10 1803 Base.

In Hyper-V Manager I then created three new virtual machines, each of them using one of those three child disks. Booted up VM W10 Insider Preview Fast and upgraded it to latest Fast Ring build, booted up VM W10 Insider Preview Skippy and upgraded it to latest Skip Ahead build, and booted up VM W10 version 1803 and have been updating it with all cumulative and other updates for last official release. In a month to six weeks, when version 1809 will be released, that last mentioned VM will be upgraded and renamed to W10 version 1809.

Attachment 200184
(Click to enlarge.)

 Scenario 2: Different domain controllers

I clean installed Windows Server 2016 on a VM and use its VHDX file as parent disk. I have created three differencing disks and use them for virtual machines for two different Server 2016 local domains / domain controllers, and use third one to test Server 2019 Preview (upgraded from Server 2016), using it for third local domain.

Much faster to setup than to install server OS three times, a lot of HDD space saved.

How do I save space? Let's say that I had those three virtual machines mentioned in Scenario 1 above done traditionally using normal dynamically expanding virtual hard disks. The size of their VHDX files would be at the moment, depending on how many upgrades the public release, Fast Ring and Skippy virtual machines would have gone through around 25 to 30 GB each.

Using one parent VHD, it's size always remains at around 10 GB. It will not be changed, updated or upgraded, nothing will be saved on it. All three child VHDs, when VMs using them have been created only use 4 MB to start with. Of course these files will grow, my version 1803 VM child disk is now over 12 GB (it started its life as version 1709, was later upgraded to 1803), both Fast and Skippy already have over 15 GB child disks as they have been through a few upgrades.

All together, my parent (base) disk plus all three child disks, the VHDX files, use currently a total of 53 GB of storage space. Having done the same three virtual machines using normal dynamically expanding virtual hard disks, they would at the moment consume at least 80 GB of HDD space.

That's one way to use differencing disks.

Kari

I have setup my differencing vhds, the same way as you have.

The only minor problem with your idea of upgrading the 1803 child to 1809 is that you cannot run 1803 unless you run the parent which then breaks the differencing links to its children.

Of course, if you never intend to run 1803 anymore that is fine and rest of this post is not relevant.

Assuming one wants to run 1803 and 1809, one could simply create a new 1809 child keeping the 1803 child of course but the problem with that is if new apps etc have been added to the 1803 child is they are not included in the 1809 child.

I intend to create an 1803 grandchild (small) and 1809 grandchild. This way the 1809 grandchild inherits all changes from the 1803 child (as does the small 1803) grandchild. This way both versions can be run and the 1809 version contains all the 1803 child changes.

It will be an interesting test to see how stable a grandchild structure is and if any significant performance penalty.

cereberus said:

The only minor problem with your idea of upgrading the 1803 child to 1809 is that you cannot run 1803 unless you run the parent which then breaks the differencing links to its children.

Of course, if you never intend to run 1803 anymore that is fine and rest of this post is not relevant.

I must have explained my scenario badly.

I have a version 1803 parent, then three 1803 child disks. One child remains 1803, being updated regularly, until it will be upgraded to 1809. Two other child disks have been upgraded to normal fast ring and Skippy respectively.

My parent 1803 is always write protected, to assure I will not use it accidentally.

Kari

muchomurka said:

Is there any difference/advantage from linked clones in esxi?

Sorry for a delayed reply.

Basically, it's the same thing. I cannot see any major differences, nor any specific advantages.

Kari

Kari said:

I must have explained my scenario badly.

I have a version 1803 parent, then three 1803 child disks. One child remains 1803, being updated regularly, until it will be upgraded to 1809. Two other child disks have been upgraded to normal fast ring and Skippy respectively.

My parent 1803 is always write protected, to assure I will not use it accidentally.

Kari

I fully understood your description. I probably did not explain myself that well.

My point was when you upgrade your 1803 child to 1809, you lose the ability to run 1803 any more (unless you run parent which breaks chilldren).

I want to retain ability to run 1803 as well as 1809.

Sure it is easy to have both an 1803 and 1809 child but the 1809 child is relative to the base install.

Suppose the parent did not have Macrium Reflect Free installed, and I installed Macrium Reflect in the1803 child, it would be missing in an 1809 child.

By using Grandchildren, the 1809 upgrades relative to 1803 child and would have Macrium Reflect. The grandchild 1803 gives me the ability to run 1803.

I would then write potect the 1803 child as well as the 1803 parent.

I hope that is clearer now,?

Also, to write protect, is it adequate just to tick the read only box in file properties, or do we have to mess with permissions (and how)?

cereberus said:

My point was when you upgrade your 1803 child to 1809, you lose the ability to run 1803 any more (unless you run parent which breaks chilldren).

I want to retain ability to run 1803 as well as 1809.

OK, I got you now.

In my case, when 1809 will be released, I don't see any reason to run 1803 anymore. If I for some reason would like to keep 1803, I could just create a new child from 1803 parent. Takes seconds.

cereberus said:

Also, to write protect, is it adequate just to tick the read only box in file properties, or do we have to mess with permissions (and how)?

I just mark it read only in file properties.

Kari

Kari said:

OK, I got you now.

In my case, when 1809 will be released, I don't see any reason to run 1803 anymore. If I for some reason would like to keep 1803, I could just create a new child from 1803 parent. Takes seconds.



I just mark it read only in file properties.

Kari

Sure you can create a new 1803 child, but it will not have all the changes made to original 1803 child of course. The 1809 will have all the relevant (non OS related) 1803 changes though.



Thanks re. protection.