@coolsport00 Sorry about the VMW need for the Cisco product. SOunds like you have a number of constraints, finances being I'm sure one of them! At least you have time on your hands and the means to experiment. You may, als, end up with a number of different platforms to meet your needs. We ran both Sun Microsystems and Red Hat Linux and Microsoft WIndows servers, each taking on specific duties. It's far from ideal and probably not very cost-effective, but you do what you have to to get stuff to work.

Pretty cool, @samuelolavo, thanks for clarifying!

@olivierlambert I'm seeing a recurrence of the snapshot_of / hidden-disks issue after patching to xapi-26.1.16-1.2 (both hosts, rebooted). Unusual element this time: snapshot-fixer.py dry-run flags ~260 VDIs across the SR that all cite a single OpaqueRef which resolves to no VDI (xe vdi-list | grep <ref> returns nothing). Holding off on rewrite until I understand whether that single-dangling-ref pattern is safe, given the set appears to include base VDIs of legitimate snapshots. Full technical detail and questions posted on GitHub: https://github.com/xcp-ng/xcp/issues/844.

@poddingue I'm seeing a recurrence of the snapshot_of / hidden-disks issue after patching to xapi-26.1.16-1.2 (both hosts, rebooted). Unusual element this time: snapshot-fixer.py dry-run flags ~260 VDIs across the SR that all cite a single OpaqueRef which resolves to no VDI (xe vdi-list | grep <ref> returns nothing). Holding off on rewrite until I understand whether that single-dangling-ref pattern is safe, given the set appears to include base VDIs of legitimate snapshots. Full technical detail and questions posted on GitHub: https://github.com/xcp-ng/xcp/issues/844.

I have received a very long update back from Veeam on my backup issues.... There appears to be another user with similar setup / issue not sure if that user is the OP this post specifically... Hello, Thank you for your patience. The QA team has finished the analysis, and I am going to outline the details as below: 1. CBT Inconsistency Issue Whenever you see the Warning about CBT showing: 2026-08-16 17:37:27.459 00079 ERROR | [XenRpcClient]: Failed ListChangedBlocks. Error: [Task 291af3d7-28c1-15a9-7f13-c6a1a12283e9 (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated]. We can go to the previous run and see that we get reports that the CBT of the previous snapshot is inconsistent and thus removed by XCP: 2026-08-16 09:54:34.120 00004 ERROR | [XenBackupManager]: Failed to retain the data for the snapshot 5a17fb31-2616-4e72-a85c-e235883c8c91 Veeam.Vbf.Common.Exceptions.ExceptionWithDetail: [Task 39c0f25f-e811-ee45-1b0b-e4a9ca9839ae (Async.VDI.data_destroy) failed: . VDI_NO_CBT_METADATA. OpaqueRef:a005d328-6da0-b8b7-34ef-0607ed44c2ed The team has been reviewing and testing, and this is what they see. We send the request for the snapshot to be created, and it is sent to the coordinator: xcp-ng-vyadytkn Aug 16 09:50:08 xcp-ng-vyadytkn SM: [1555017][MainThread] vdi_clone: introduced VDI: OpaqueRef:a005d328-6da0-b8b7-34ef-0607ed44c2ed (5a17fb31-2616-4e72-a85c-e235883c8c91) CBT shows as open and reading fine: Aug 16 09:50:08 xcp-ng-vyadytkn SM: [1555017][MainThread] ['/usr/sbin/cbt-util', 'set', '-n', '/var/run/sr-mount/7911c9c5-5f20-01e1-8b8d-39c6a98a2704/5a17fb31-2616-4e72-a85c-e235883c8c91.cbtlog', '-f', '1'] Aug 16 09:50:08 xcp-ng-vyadytkn SM: [1555017][MainThread] pread SUCCESS But look at how on xcp-ng-host2 the CBT gets marked as inconsistent by XCP, even though it's open and reading: Aug 16 09:51:05 xcp-ng-host2 SM: [1683689][MainThread] Changed Block Tracking metadata is inconsistent for disk 5a17fb31-2616-4e72-a85c-e235883c8c91. The Breakdown: xcp-ng-vyadytkn was the coordinator—the one we talk to, who then passes everything around to the hosts. xcp-ng-host2 was the host that the VM resided on at that time. xcp-ng-host2 is marking the CBT as inconsistent and deleting the snapshot CBT log, which means we cannot reference it on the next run. We do not see anything else interacting with the CBT besides that host. This matches exactly what we see with another client running the same setup. The team successfully replicated the environment, which is configured as follows: VM storage is NFS. The VM is running on a host that is not the coordinator. They have been able to reproduce this behavior occasionally, and the working theory is that the VM host keeps its own tracking separate from the coordinator. Part of the backup process requires the VM host to issue a pause/resume via a process called tapdisk. When it resumes, it pushes a data cache (likely inside the NFS cache), overwriting the CBT reference held by the coordinator server. It acts as a race condition—whoever pushes the CBT data last wins. If the VM host pushes last, it breaks what the coordinator is sending. Next Steps for CBT: The team is working to raise this issue directly with Vates so they can address the race condition. We ask that you also open a Vates ticket if possible to help draw more attention to the bug. We are trying to find ways to code around this race condition in the future, but there are currently no ETAs or guarantees. 2. Synthetic Full Failures (Delilah_ArcFS01) In addition to the CBT bug, the team discovered a separate issue. Recently, the synthetic fulls for Delilah_ArcFS01 have been failing. This appears to be related to the NFS repository: [30.08.2026 00:43:22.856] <24> [0007] Error (1) Failed to execute full transform task [30.08.2026 00:43:22.856] <24> [0007] Error (1) Agent: Failed to process method {Transform.CompileFIB}: NfsFileEx was already stopped. File: [Host:, Mount: [/volume1/veeam], Disk: [Delilah ArcFS01 Backup/Delilah ArcFS01 Backup_2026-08-29T232336.vib], Type: [nfs3 (1)]] (Veeam.Backup.Common.CCppComponentException) [30.08.2026 00:43:22.856] <24> [0007] Error (1) in c++: Failed to execute command Command: READ, Offset: 2523136, Data size: 659456, Chunk size: 131072 [30.08.2026 00:43:22.856] <24> [0007] Error (1) in c++: Failed to read file: Offset: 2523136, Block size: 659456, File: Path: [Host:, Mount: [/volume1/veeam], Disk: [Delilah ArcFS01 Backup/Delilah ArcFS01 Backup_2026-08-29T232336.vib], Type: [nfs3 (1)]], Handle: [01000702080061030000000007fffd5f65840fb20000000000000000150061038a2f7c0b0400610379207c0b], Read chunk size: 131072, Write chunk size: 131072, Read only: true Because it continuously fails during the synthetic full, it eventually causes the snapshot to be lost when retries fail. The team will change this logic in a future update. Action Items for the NFS Issue: To help prevent these snapshot loss failures, could you please provide the logs from the repository NFS (192.168.20.91)? Export the logs from the Veeam server and select the repository host. Provide the results of running this command directly on the Repository host: journalctl --since "30 days ago" > journal_repo.log Temporary Workaround: If you can, please temporarily switch to active fulls instead of synthetic fulls to help stabilize the job. Please let me know if you have any questions, and if you are able to raise that ticket with Vates. They also just responded back with this statment... Regarding the second part of the last email with the noticed Synthetic full issue, I actually would like you to also make this registry entry on the Veeam server and keep synthetic fulls enabled to see if it helps with that issue: Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication Name: Nfs3CommandWaitTimeoutSec Type: DWORD Value (In Decimal): 86400

@dthenot Thanks - I'll be interested to hear about your findings. I'll hold off on submitting a report until I hear back.