Save to My DOJO
Usually when we talk about Hyper-V’s virtual disk types, we focus on fixed and dynamically expanding. There’s another type that enjoys significantly less press: differencing disks. Administrators don’t deal directly with differencing disks as often as they work with the other two types, but they are hardly rare. Your Hyper-V knowledge cannot be complete without an understanding of the form and function of differencing disks, so let’s take a look.
What are Hyper-V Differencing Disks?
A differencing disk contains block data that represents changes to a parent virtual hard disk. The salient properties of differencing disks are:
- A differencing disk must have exactly one parent. No more, no less.
- The parent of a differencing disk must be another virtual hard disk. You cannot attach them to pass-through disks, a file system, a LUN, a remote share, or anything else.
- The parent of a differencing disk can be any of the three types (fixed, dynamically expanding, or differencing)
- Any modification to the data of the parent of a differencing disk effectively orphans the differencing disk, rendering it useless
- Hyper-V can merge the change data back into the parent, destroying the differencing disk in the process. For Hyper-V versions past 2008 R2, this operation can take place while the disk is in use
Typically, differencing disks are small. They can grow, however. They can grow to be quite large. The maximum size of a differencing disk is equal to the maximum size of the root parent. I say “root” because, even though a differencing disk can be the parent of another differencing disk, there must be a non-differencing disk at the very top for any of them to be useful. Be aware that a differencing disk attached to a dynamically expanding disk does have the potential to outgrow its parent, if that disk isn’t fully expanded.
How Do Differencing Disks Work?
The concept behind the functioning of a differencing disk is very simple. When Hyper-V needs to write to a virtual disk that has a differencing child, the virtual disk driver redirects the write into a differencing disk. It tracks which block(s) in the original file were targeted and what their new contents would have been.
The most important thing to understand is that the virtual disk driver makes a choice to write to the differencing disk. The file itself is not marked read-only. You cannot scan the file and discover that it has a child. The child knows who its parent is, but that knowledge is not reciprocated.
Writes are the hard part to understand. If you’ve got that down, then reads are easy to understand. When the virtual machine requests data from its disk, the virtual disk driver first checks to see if the child has a record of the requested block(s). If it does, then the child provides the data for the read. If the child does not have a record of any changes to the block(s), the virtual disk driver retrieves them from the parent.
This is a Hyper-V blog, so I mostly only talk about Hyper-V. However, the virtual disk driver is part of the Windows operating system. The normal tools that you have access to in Windows without Hyper-V cannot create a differencing disk, but you can mount one as long as its parent is present.
How are Differencing Disks Created?
Unlike fixed and dynamically expanding virtual hard disks, you don’t simply kick off a wizard and create a differencing disk from scratch. In fact, most Hyper-V administrators will never directly create a differencing disk at all. There are four generic methods by which differencing disks are created.
For most of us, backup software is the most likely source of differencing disks. When a Hyper-V aware backup application targets a virtual machine, Hyper-V will take a special checkpoint. While the disk and the state of the virtual machine are frozen in the checkpoint, the backup application can copy the contents without fear that they’ll change. When the backup is complete, Hyper-V deletes the checkpoint and merges the differencing disk that it created back into its parent. If it doesn’t, you have a problem and will need to talk to your backup vendor.
Note: backup software operations will always create differencing disks in the same location as the parent. You cannot override this behavior!
Standard and Production Checkpoints
Standard and Production Checkpoints are created by administrators, either manually or via scripts and other automated processes. As far as the disks are concerned, there isn’t much difference between any of the checkpoint types. Unlike backup checkpoints, Hyper-V will not automatically attempt to clean up standard or production checkpoints. That’s something that an administrator must do, also manually or via scripts and other automated processes.
Note: checkpoint operations will always create differencing disks in the same location as the parent. You cannot override this behavior!
Pooled Remote Desktop Services
For the rest of this article, I’m going to pretend that this method doesn’t exist. If you’re operating a full-blown Remote Desktop Services (RDS) operation for your virtual desktop infrastructure (VDI), then it’s using differencing disks. Your gold master is the source, and all of the virtual machines that users connect to are built on differencing disks. When a user’s session ends, the differencing disk is destroyed.
Of the four techniques to create a differencing virtual hard disk, manual creation is the rarest. There aren’t a great many uses for this ability, but you might need to perform an operation similar to the gold master with many variants technique employed by VDI. It is possible to create many differencing disks from a single source and connect separate virtual machines to them. It can be tough to manage, though, and there aren’t any tools to aid you.
You can create a differencing disk based on any parent virtual hard disk using PowerShell or Hyper-V Manager.
Creating a Hyper-V Differencing Virtual Hard Disk with PowerShell
The New-VHD cmdlet is the tool for this job:
New-VHD -Path .diff.vhdx -ParentPath .root.vhdx -Differencing
Don’t forget to use tab completion, especially with ParentPath.
Creating a Hyper-V Differencing Virtual Hard Disk with Hyper-V Manager
Use the new virtual hard disk wizard in Hyper-V Manager to create a differencing disk:
- In Hyper-V Manager, right-click on the host to create the disk on, or use the Action pane in the far right. Click New, then Hard Disk.
- Click Next on the informational screen.
- Choose VHD or VHDX. The differencing disk’s type must match its parent’s type. You cannot make a differencing disk of a VHDS file.
- Choose Differencing.
- Enter the file name and path of the differencing disk that you want to create.
- Select the source virtual hard disk.
- Check your work and click Finish if you’re satisfied, or go Back and fix things.
How Manual Differencing Disk Creation is Different
A differencing disk is a differencing disk; no matter how you create them, they are technologically identical. There are environmental differences, however. Keep these things in mind:
- Hyper-V will automatically use the differencing disks created by backup, standard, and production checkpoints. It will retarget the connected virtual machine as necessary. No such automatic redirection occurs when you manually create a differencing disk. Remember that modifying a virtual hard disk that has differencing disks will render the children useless.
- During manual creation of a differencing, you can specify a different target path for the differencing disk. While convenient, it’s tougher to identify that a virtual hard disk has children when they’re not all together.
- Hyper-V Manager maintains a convenient tree view of standard and production checkpoints. Manually created differencing disks have no visual tools.
- The checkpointing system will conveniently prepend an “A” (for “automatic”) to the extensions of the differencing disks it creates (and give them bizarre base file names). Both Hyper-V Manager and PowerShell will get upset if you attempt to use AVHD or AVHDX as an extension for a manually-created differencing disk. That makes sense, since “A” is for automatic, and automatic is antonym of “manual”. Unfortunately, these tools are not supportive of “MVHD” or “MHVDX” extensions, either. If you do not give it an obvious base name, you could cause yourself some trouble.
You can use PowerShell to detect the differencing disk type and its parent:
The Inspect function in Hyper-V Manager does the same thing. You can find this function in the same Action menu that you used to start the disk creation wizard.
I also wrote a PowerShell script that can plumb a VHD/X file for parent information. It’s useful when you don’t have the Hyper-V role enabled, because none of the above utilities can function without it. Head over to my orphaned Hyper-V file locator script and jump down to the Bonus Script heading. It’s a PowerShell veneer over .Net code, so it will also be of use if you’re looking to do something like that programmatically.
Merging Manually-Created Differencing Disks
Now that you know how to create differencing disks, it’s important to teach you how to merge them. Ordinarily, you’ll merge them back into their parents. You also have the option to create an entirely new disk that is a combination of the parent and child, but does not modify either. The merge process can also be done in PowerShell or Hyper-V Manager, but these tools have a different feature set.
Warning: Never use these techniques to merge a differencing disk that is part of a checkpointed VM back into its parent! Delete the checkpoint to merge the differencing disk instead. It is safe to merge a checkpointed VM’s disk into a different disk.
Merging a Hyper-V Differencing Virtual Hard Disk with PowerShell
Use the aptly-named Merge-VHD cmdlet to transfer the contents of the differencing disk into its parent:
Merge-VHD -Path '\svstore01vmsVirtual Hard Disksdiff.vhdx'
The differencing disk is destroyed at the end of this operation.
PowerShell cannot be used to create a completely new target disk, for some reason. It does include a DestinationPath parameter, but that can only be used to skip levels in the differencing chain. For instance, let’s say that you have a root.vhdx with child diff1.vhdx that has its own child diff2.vhdx that also has its own child diff3.vhdx. You can use Merge-VHD -Path .diff3.vhdx -DestinationPath .diff1.vhdx to combine diff3.vhdx and diff2.vhdx into diff1.vhdx in a single pass. Without the DestinationPath parameter, diff3.vhdx would only merge into diff2.vhdx. You’d need to run Merge-VHD several times to merge the entire chain. Hyper-V Manager has no such capability.
Merging a Hyper-V Differencing Virtual Hard Disk with Hyper-V Manager
Hyper-V Manager has a disk editing wizard for this task.
- In Hyper-V Manager, right-click on the host to create the disk on, or use the Action pane in the far right. Click
- Click Next on the informational screen.
- Browse to the differencing disk that you wish to merge.
- Choose Merge.
- Choose to merge into the parent or into a new disk.
- Check your work and click Finish if you’re satisfied, or go Back and fix things.
If you chose to merge the disk into its parent, the differencing disk is destroyed at the end of the operation. If you chose to merge into a new disk, both the source and differencing disk are left intact.
Hyper-V Manager cannot merge multiple layers of a differencing chain the way that PowerShell can.
The Dangers of Differencing Disks
There are two risks with using differencing disks: performance and space.
Differencing Disk Performance Hits
When a differencing disk is in use, Hyper-V will need to jump back and forth from the child to the parent to find the data that it wants for reads. Writes are smoother as they all go to the differencing disk. On paper, this looks like a very scary operation. In practice, you are unlikely to detect any performance problems with a single differencing child. However, if you continue chaining differencing disk upon differencing disk, there will eventually be enough extraneous read operations that you’ll start having problems.
Also, merge operations require every single bit in the differencing disk to be transferred to the parent. That operation can cause an I/O storm. The larger the differencing disk is, the greater the impact of a merge operation.
Differencing Disk Space Issues
As mentioned earlier, a differencing disk can expand to the maximum size of its parent. If you have a root disk with a maximum size of 50 gigabytes, then any and all of its differencing disks can also grow to 50 gigabytes. If the root is dynamically expanding, then it is possible for its differencing disk(s) to exceed its size. For example, in this article I have used a completely empty root VHDX. It’s 4 megabytes in size. If I were to install an operating system into the differencing disk that I created for it, root.vhdx would remain at 4 megabytes in size while its differencing disk ballooned to whatever was necessary to hold that operating system.
A merge operation might require extra space, as well. If I were to merge that differencing disk with the OS back into the empty 4 megabyte root disk, then it would need to expand the root disk to accommodate all of those changed bits. It can’t destroy the differencing disk until the merge is complete, so I’m going to need enough space to hold that differencing disk twice. Once the merge is completed, the space used by the differencing disk will be reclaimed.
If the root disk is fixed instead of dynamically expanding, then the merges will be written into space that’s already allocated. There will always be a space growth concern when merging trees, however, because differencing disks are also dynamically expanding and they merge from the bottom up.
Transplanting a Differencing Disk
Did a forgotten differencing disk run you out of space? Did a differencing disk get much larger than anticipated and now you can’t merge it back into its parent? No problem. Well… potentially no problem. All that you need is some alternate location to hold one or more of the disks. Follow these steps:
- Shut down any connected virtual machine. You cannot perform this operation live.
- Move the disk(s) in question. Which you move, and where you move them, is up to you. However, both locations must be simultaneously visible from a system that has the Merge-VHD cmdlet and the Hyper-V role installed. Remember that it is the disk that you are merging into that will grow (unless it’s fixed).
- If you moved the differencing disk and you’re still on the system that it came from, then you can probably just try the merge. It’s still pointed to the same source disk. Use Get-VHD or Inspect to verify.
- If you moved the root disk, run the following cmdlet:
Set-VHD '\svstore01vmsVirtual Hard Disksdiff.vhdx' -ParentPath 'C:LocalVMsVirtual Hard Disksroot.vhdx'
Your usage will obviously be different from mine, but what you’re attempting to do is set the ParentPath to reflect the true location of the parent’s VHDX. You can now attempt to merge the disk.
If a differencing disk somehow becomes disjoined from its parent, you can use Set-VHD to correct it. What you cannot do is use it to rejoin a differencing disk to a parent that has been changed. Even though the Set-VHD cmdlet may work, any merge operation will likely wreck the data in the root disk and render both unusable.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
18 thoughts on "Hyper-V Differencing Disks Explained"
Great Article. Very Informative about differencing disks. Thanks.
“Any modification to the data of the parent of a differencing disk effectively orphans the differencing disk, rendering it useless”
So this means once a parent vhdx has been connected back to a vm after a failed merge with an avhdx makes the avhdx useless and trying to merge with parent will cause data loss?
Just the act of connecting the VHDX does not modify its contents. But, if the VM was turned on, then it will modify something and that will permanently break the parent-child relationship.
Trying to merge will fail outright. But the differencing data contained in the AVHDX would be lost, yes.
So the avhdx from an interrupted merge after a backup shouldn’t be attempted to merge back in as it will result in data corruption in the vhdx?
I copied the files in questions and attempted a merge that completed successfully but from what you’re saying I shouldn’t even try to do that on the production disk. Correct?
In the generic sense, that would depend on how the merge was interrupted. The merge process has safeguards built in.
Usually, it can detect when a merge will fail and prevent it from happening.
If your test merge completed successfully, that is a really good sign. If you tested it and liked what you saw, that’s even better.
Usually, as long as you do not directly manipulate the parent disk, you will not orphan its children.
In your case, I would keep those copies and be ready to go to backup, but at least give it a shot in production.
The child has been orphaned because I had to reconnect to even have the option to merge. Does that fact that it’s a file server influence the way or if I should try to merge in production? Note: There are actually 4 orphaned children that all point to the vhdx as a parent that date back 2 months. Does that change your advice?
Would you mind taking this over to the Dojo forums? That format would be easier. Please provide a diagram of the parent-child relationships of these different files.
But yes, I would try to recover all of them.