@Pilow Agree.... have to be sure that garbage collection is completed or it'll never catch up if backups continue to be run without the coalesce completing.

@Pilow The other thing to to consider is being cognizant of how long your backups typically take (or even, planning a worst-case condition) and defining the backup intervals accordingly.
In other words, if you know you cannot consistently do your incremental backups in less than an hour, perform them 90 minutes or two hours between backups. It's better IMO to have a solid backup less frequently than have them fail on a regular basis.

@Pilow Right, just skip the currently planned backup if a coalesce is still in progress and check again the next scheduled backup. This could potentially be implemented in the existing backup code.

@Pilow Ah, right. You'd have to check the time stamp if you worked on automating this.
So maybe @McHenry could write a script to do the backups and that way, ensure there was no on-going task in progress before kicking off the next backup instance.
It could be run periodically from a cron job and if there's still on-going activity, just exit and try again the next time.

@Pilow I agree, the error message is misleading and indeed, garbage collection can take some time to complete and likely in some cases to be greater than one hour.
Is there the option to monitor garbage collection with task-list or some other utility? Because if so, one could write a script to kick off backups instead of using the cron pattern in the backup setting. Just a suggestion ...

@McHenry Are you sure with that frequent running backups that each backup completes successfully before the next one starts? How long does the full backup typically take (less than 7 hours?) as well as the incrementals (under 1 hour?)? Again, I'd suggest looking in /var/log/SMlog for any error conditions that might help identify an issue. Also, how fragmented is your storage, as that can slow things down quite a bit, as can the lack of adequate CPU power as well as memory (run the top or xentop utility to view the load during backups).

@Pilow Yes, you are correct that the chain length is also limited. You might try to manually delete some of the snapshots and though the limit is supposed to be 30, perhaps there are other factors involved? Does that VM have a particularly large amount of storage and a lot of changes between snapshots? Are any other of your VMs experiencing similar issues? Your SR appears to be mostly empty, correct? Are there any related errors showing up in /var/log/SMlog ?

@Pilow Yes; it's been my understanding that this has been the default for many years now.

@JSylvia007 Sorry, I'm really late to this thread, but note that backups can become problematic if the SR is something like 90% or more full. There needs to be some buffer for storage as part of the process. The fact you could copy/clone VMs means your SR is working OK, but backups are a different situation. If need be, you can always migrate VMs to other storage which is evidently what you ended up doing, which frees up extra disk space. Also backups are pretty intensive so make sure you have both enough CPU capacity and memory to handle the load. Finally. a defective SR will definitely cause issues if there are I/O errors, so watch your /var/log/SMlog for any such entries.

@Aleksander WIth standard install 8.2 and associated drivers, it's reported that support exists for the following:
Tesla M6/M10/M60, P4/P6/P40/P100, V100, T4, A2/A10/A16/A40, and RTX A5000/A6000/6000/8000 series.
The appripriate NVIDIA licensing must of course also be obtained and installed, including a license server.

@Andrew I thought dom0 had to have some sort of graphics card; is this a recent development? My understanding is that dom0 needed one, albeit not necessarily any with GPU capabilities. Thanks in advance for any clarifications.

@Johny It would help knowing how the two GPUs were configured on the host. Is this host part of a pool or standalone?

@vaewyn There is an emergency transition to new master xe command. Also, make sure all your hosts are properly time syncronized to each other or there can be pool issues.
Try first:
xe pool-designate-new-master host-uuid=<new-master-uuid>
If that fails, you will need to run on the slave server:
xe pool-emergency-transition-to-master

@olivierlambert Good idea. Also, they should make sure all hosts are at the same update/patch levels, the network is set up properly among the three or more hosts, there is a compatible HA shared storage properly set up, etc.
You folks have a good guide at: https://docs.xcp-ng.org/management/ha/

@nikade Interesting, as that at some point used to be the case, at least with XenServer!
I stand corrected and learned something new.

Note also that if HA is turned on or off, the host must be restarted for that change to take effect, if I recall correctly.

@olivierlambert I've always preferred Intel NICs.

@kagbasi-ngc See if this thread can help you out:
https://xcp-ng.org/forum/topic/6618/how-to-remove-this-sr-nfs-storage/

@umbradark Maybe too obvious, but is your boot configuration set up to be BIOS or EUFI mode?

@nikade Did the same. VLANs are great! We did use separate NICs for iSCSI storage. But the PMI and VMs, traffic was handled easily by the dual 10 GiB NICs, even with several hundred XenDesktop VMs hosted among three servers (typically around 8- VMs per server).