@johnnezero Thanks, man! I hope you and others find it and the related other two articles useful.

@johnnezero Cool -- you guys probably have a way better idea of a proper layout and organization of the materials. Thank you!

@john.c They are under two branches ... do you not see them?
XenServer-Articles and XenServer-Forum-Threads -- they landed under the "Branches" section ...

@john.c @johnnezero Well, the Github reporsitory is in place already! Access it at:
https://github.com/tobiaskreidl/Citrix-Tobias-Kreidl-Collection
Feel free to find more material to add, as will I, and thank you kindly for the suggestions and support.

@john.c Wow, that was amazing -- not sure why my searches were unsuccessful, but many thanks! I think Github might be a good option for putting these on-line as a more reliable spot. And, yes, preserving images is always a challenge.
I do hope some of that information may be useful to you and thanks much again for all your efforts, John!

P.S. Seems the easiest way to get the full content is to save the Web page as a PDF file, which I have since done. You can, of course, also download the whole package to an HTML folder but that output looks a bit messy, though it does split things out nicely. I'll consider one or the other or both for putting up somewhere, like on Github, but at least I have them now!

@john.c Not found with the Wayback Machine, alas. Still not finding it anywhere else, but will keep looking!
It's a crying shame Citrix didn't preserve the treasure trove of old community blogs.

@johnnezero It would be also interesting to take UMA/NUMA into account as VMs -- in particular, VMs with vGPUS -- can run much more efficiently if they do not cross memory bank boundaries that span more than one CPU instance. On some Linux systems -- not sure about the one hosting XCP-ng -- you can even disable NUMA. Just an additional thought here. I published a number of years ago a three-part series "A Tale of Two Servers" discussing a number of related optimizations but alas, the Citrix blogs were eliminated and I'm snot sure where copies of these articles exist anymore. But there are plenty of articles on this, in particular by Frank Denneman, and also ones like the following;
https://indico.cern.ch/event/304944/contributions/1672535/attachments/578723/796898/numa.pdf
https://docs.xenserver.com/en-us/xenserver/9/numa.html

@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