Before opening a support case, has anyone seen Veeam Backup & Replication 12.3.2 create Hyper-V checkpoints, remove them from the VM configuration, and leave the AVHDX files behind without ever merging them?
This is a three-node Windows Server 2022 failover cluster with Pure FlashArray storage backing the CSVs. A VM running SQL Server 2019 accumulated 46 orphaned AVHDX files across two virtual disks over three days, totaling about 675 GB. Get-VMSnapshot returned nothing, and Hyper-V Manager showed no checkpoints. The VM was running from the end of a 23-level differencing chain.
The unusual part is that the VMMS event log contains no merge events for this VM—not failed merges or interrupted merges, but no merge attempts at all. Other VMs on the same host regularly logged normal 19070-to-19080 merge event pairs. This makes it appear that Veeam created the checkpoint and then removed it from the VM configuration without asking Hyper-V to merge it.
I shut down the VM and flattened both chains with Convert-VHD to another CSV, then repointed the VM to the new disks. Test-VHD passed before and after, and SQL Server started normally with all 14 databases online and data current to shutdown. However, the problem returned immediately: the next backup run against the new flat VHDX files created two more orphaned AVHDX files, again with no registered checkpoints or Hyper-V events. A cluster-wide check found this VM is the only one affected across all three nodes.
Has anyone encountered this behavior with Veeam and Hyper-V, or found a configuration issue or known fix that explains why the checkpoint merge is never requested?
2 Answers
At this point I’d involve Veeam support rather than repeatedly flattening the disks. The fact that only one VM is affected, across every cluster node, suggests something specific to that VM or its backup metadata—such as an unusual disk layout, job association, CBT or guest-processing setting, or stale checkpoint information. Support should be able to correlate the backup session with the Hyper-V API calls and determine whether Veeam is issuing a remove operation without the corresponding merge request.
I’ve seen similar behavior with third-party Hyper-V backup integrations when a job fails or loses track of a checkpoint. The snapshot can disappear from the VM configuration while the AVHDX chain remains, requiring manual consolidation. Given that this is happening repeatedly, I’d collect the Veeam session logs, VMMS logs, cluster role history, and the exact checkpoint-related operations, then open a support case. They may also require testing on the latest supported build before investigating further.
That kind of manual consolidation hasn’t been common in my environment for years, so I’d treat the repeat occurrence as a product or configuration issue rather than normal Hyper-V behavior.
That’s why I wanted to ask first: support can be slow and may ask for details already included in the initial case. Still, with another pair of AVHDX files appearing after the disks were rebuilt, I’m going to provide the full logs and have them investigate it directly.