You dont have javascript enabled! Please enable it!

Background disk merge failed to complete: The requested operation could not be completed due to a file system limitation (0x80070299)

5 Min. Read

[Updated: March 4th, 2016] – Adding a second recovery option under the Resolution section.

In this article, we will show you how to resolve the background disk merge that failed to complete in Hyper-V.


Sometimes things go wrong with Hyper-V replica or backup jobs, especially when Hyper-V replica and backup are running at the same time. In fact, this is the reason for this blog post.

One of my colleagues was backing up his virtual machine, the VM was in a backup state, and then he initiated replication from Host A to Host B at the same time.

The Virtual Machine ended up having two (.avhdx) as shown in the following screenshot:



A little bit of context on how Hyper-V replica and backup work behind the scene in Windows Server 2012 R2 Hyper-V.

I mentioned Windows Server 2012 R2 here because there are some changes in Windows Server 2016.

Hyper-V replica creates checkpoint (.avhdx) to handle the initial replication of the virtual machine (for example when getting the first copy of the virtual machine across the replica host). Hyper-V Replica will merge this disk out once it has successfully made a full copy of the virtual machine, virtual hard disk (which can take a while).

Hyper-V backup also creates checkpoint (.avhdx). In fact, a checkpoint is created for every virtual machine that is to be backed up. The I/O writes are temporarily redirected to the checkpoint’s AVHDX/AHVD file(s). This gives the backup requestor a clean and crash-consistent copy of the virtual machine’s VHD(X) files that are safe to read. After the backup, the checkpoint is merged and the job is completed.


After the backup is completed, the snapshot is being merged automatically, But since Hyper-V Replica and backup were running at the same time. The background disk merges failed to complete.

The Microsoft-Windows-Hyper-V-VMMS/Admin event log will be filled with the Error ID: 19100, because Hyper-V will continuously try to run the disk merge in the background and it will fail.


If you look at the checkpoints of this Virtual Machine in Hyper-V Manager or using PowerShell, you don’t find any!



However, if you open the VM settings for this virtual machine, you can see that the Edit disk is not available because checkpoints exist for this virtual machine.



We have actually two options to resolve this issue, but before we start, you need to remove first the replication for the affected VM on the primary host, and you want to stop the backup job if any is still running.

Option 1

Option 1 is risky because we need to start merging those checkpoints manually to the parent VHD(X), hence if you missed any step, you may lose your data!

In between, there is no need to dive in and start merging the checkpoints manually unless you are in such a scenario where that’s the only option you have left, for example in this case and you don’t have another Hyper-V host.

You can use PowerShell or DiskPart for this but I see a value by using Hyper-V Manager UI here because you can inspect which the most recent (.avhdx) and its parent, and then proceed safely.

It’s very important to start with the most recent virtual hard disk and then work your way down.

My fellow MVP, Didier Van Hoye wrote a great blog post on how to do this operation manually.


First, we need to find the parents of all (.avhdx) files.

Open Hyper-V Manager and click on Inspect Disk…


After you inspect the checkpoints and their parents, you can start Editing the disk.

As a side note, I strongly recommend taking a note for every step here.

Open Hyper-V Manager and click on Edit Disk… Browse and select the most recent (.avhdx) and click Next>

In my case it is (SQL-Instance_CA3AD8B3-C205-48A7-930B-24D8F7375334.avhdx)


At the Edit Virtual Hard Disk Wizard, select Merge and then click Next>


In my case, I want to merge to it’s parent disk which is (SQL-Instance_4B2591D7-440C-4A12-836B-64D055D38E5D.avhdx)


Verify and confirm the merge options are correct and click Finish


Let the wizard complete the merge.

Now if you go back and look at the virtual machine settings, you can see that the most recent (.avhdx) file that you just merged is still there. However, this file does not exist anymore.


Because the virtual machine was unable to auto-merge its disk in the background, you need to manually attach the most recent (.avhdx).

To do that, you need to click Browse and select the new parent disk, in my case it is (SQL-Instance_4B2591D7-440C-4A12-836B-64D055D38E5D.avhdx).


When you hit apply, you will receive the following Warning Data loss may occur!


Click Continue. You will receive a final warning message!


This is not safe, easy, and obvious so you are responsible for everything you do.

You continue to do this over and over again until you merge the last (.avhdx) into the parent VHDX.


One thing worth pointing out is that you may encounter the same error during the manual merging process, one of the disks might fail to merge to its parent directly.


In this case, you need to merge the disk to a new VHD(X).


Option 2

Option 2 is less risky if this option is available to you versus error-prone using option 1.

This option requires having a second Hyper-V host in your environment, and I believe we do all have more than one host in production.

We need to leverage the Shared-Nothing live migration feature and move the affected virtual machine including its storage to the second Hyper-V host.

You can use PowerShell or Hyper-V Manager, it’s much easier with PowerShell.

Move-VM "VMName" -IncludeStorage -DestinationHost HV02 -DestinationStoragePath "D:\VMs" –Verbose

You might ask why we don’t use storage migration and move the storage within the first host. If you recall, the primary host kept on trying to run disk merge in the background and was failing, thus this option is not viable for us. However, by moving the VM to a different host, and when the migration is completed, the second host will trigger a new disk merge and merge all the disks for you.

Note: As a measure of precaution, I strongly recommend doing this process while the VM is in the off state, thus will avoid the BSOD screen or reboot even if the VM is Generation 2.


Please do not run backup and Hyper-V Replica for your virtual machines at the same time.

The changes introduced in Windows Server 2012 R2 would benefit using any backup product to take backup of Replica VMs, in other words, if you are using Hyper-V replica today, you could take the benefit of that and start backing up your replica VMs. There are a few key scenarios where backup of a Replica VM becomes useful:

1- Reduce the impact of backup on the running workload (primary Host and VMs).
2- If you have Limited bandwidth between sites.
3- If you are hosting your virtual machines in a Hoster datacenter as the replica site.

Please remember to have backup all the time before you start this process.

Thanks for reading and hope this helps someone!


Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect, Swiss Certified ICT Security Expert, Certified Cloud Security Professional (CCSP), Certified Information Security Manager (CISM), Microsoft Most Valuable Professional (MVP), and Microsoft Certified Trainer (MCT). He has over 20 years of broad IT experience serving on and guiding technical teams to optimize the performance of mission-critical enterprise systems with extensive practical knowledge of complex systems build, network design, business continuity, and cloud security.

Related Posts


Virtual Machine Migration Operation Failed to Authenticate The Connection at the source Host: The Target Principal Name is Incorrect. (0x80090322) #HyperV

Free New eBook: Supercharge Your HyperV Deployment by @AltaroSoftware


2 thoughts on “Background disk merge failed to complete: The requested operation could not be completed due to a file system limitation (0x80070299)”

Leave a comment...

  1. Hi,

    if you start with the most recent one, the changes will be written to the snapshot before, using up more disk space. In the case where your hard drive is already full (what usually is the reason for this), the merging will not work this way.
    You should start with the oldest snapshot and work the way up to the newest. This way the changes will be only written to the original drive.


  2. Hello Ivan, thanks for sharing your feedback!
    You mentioned a particular scenario (when your hard drive is full).
    Have you tested to merge from the oldest snapshot and work the way up to the newest one?
    I did not test that scenario and I don’t think it works because you want to start with the most recent AVHDX file and then work your way down so you can end up with a usable parent VHDX, otherwise, you might lose data and the merge will fail. You must identify the AVHDX order of merging by inspecting the disk.
    If you have a second Hyper-V host, then check option 2 and move the affected virtual machine including its storage to the second host. It’s safer!
    Hope this helps!

Let me know what you think, or ask a question...

error: Alert: The content of this website is copyrighted from being plagiarized! You can copy from the \'Code Blocks\' in \'Black\' by selecting the Code. Thank You!