Hi, everyone. Nice to see this project turning into reality. I will try to spend time here as possible, which is hard with already being spread thinly. I've been a XenServer user for around a decade and am as interesting in learning as well as contributing whatever knowledge might be helpful to the community.

Best regards,
-=Tobias

And from the CLI:

1. xe host-list (to get the UUID of the host)
2. xe pool-eject host-uuid=<host_UUID>

@obyt It depends on (1) licensing, if any, as some licenses go by cores vs. sockets, and (2) NUMA/VNUMA depending on how critical the performance is depending on how the VCPUs get allocated between sockets or on a single socket. Best way IMO is to try all and test with benchmarks. See, for example, this article and the previous two articles, as well as articles by Frank Denneman and others: https://blogs.mycugc.org/2019/04/30/a-tale-of-two-servers-part-3-the-influence-of-numa-cpus-and-sockets-cores-persocket-plus-other-vm-settings-on-apps-and-gpu-performance/

@livierlambert said in NUMA-impact - Xeon/Epyc - 1P vs 2P:

There is no universal answer (because it's mostly depending on your VM load and what do you expect). As usual, my advice is to keep it simple if you don't have a problem with it (ie: you are satisfied by the perf.). Even a default EPYC configuration will be likely always better than a Xeon one.

After that, if you want to go deeper and learn the details, it's OK, let me just ping @jkreidl who did a remarkable job (if I remember correctly) on this very topic.

Thanks for the mention, @livierlambert ! Here's a link to part 3, which contains links back to parts 1 and 2. Note that NUMA will affect EPYC processors differently as they changed the die configuration at one point with the number of cores. I'm open for any questions on this topic. https://blogs.mycugc.org/2019/04/30/a-tale-of-two-servers-part-3-the-influence-of-numa-cpus-and-sockets-cores-persocket-plus-other-vm-settings-on-apps-and-gpu-performance/

@pretorious I would add that you have to be careful about overprovisioning when NUMA/vNUMA kicks in, that is when you allocate more VCPUs to exceed the number of physical CPUs of a bank of them as well as the associated physical memory (assume, for the sake of argument, you have two banks of physical CPUs and each has directly accessible to it one of two banks of memory) then things get inefficient because a CPU may need to go across to a different bank of memory to access data and there is additional overhead involved. See for example this article and the two preceding it:
https://blogs.mycugc.org/2019/04/30/a-tale-of-two-servers-part-3-the-influence-of-numa-cpus-and-sockets-cores-persocket-plus-other-vm-settings-on-apps-and-gpu-performance/

-=Tobias

How many hosts in your pool? For HA to work out of the box, you need at least three hosts in a pool. Also, are all your hosts properly time synchronized to the same time source?
They need to be very close in time to each other for HA to work properly. Note that when HA is first enabled on a given host, it has to be rebooted for HA to function.

@ucasljorge That may be the issue. That's pretty full for a coalesce to work!

@tmoab Strange, but I've seen some tasks "stuck" that could not be cancelled for some reason or aanother. A reboot is a drastic measure, but unfortunate;y sometimes the only recourse.

@evdog You can force a host to be ejected even if the host is not reachable any longer from the pool master using:
xe host-forget uuid=UUID
If there is any issue because VMs are thought to be running still on that host,
you may need to do a power state reset on such before you can get rid of that host.
See if that works for you.

@lanedrop CPU compatibility is automatic now, albeit the CPUs have to be somewhat similar. That said, Intel and AMD CPUs cannot be mixed. There used to be scripts out there that you could use to check compatibility but I have not seen them for quite some time. Note that the CPU mask will be reduced to the lowest common denominator -- that is to say, the oldest, least-featured CPU in the pool -- so I would be careful what servers you include in your pool(s).
See also: https://xcp-ng.org/forum/topic/6896/non-server-cpu-compatibility-ryzen-and-intel/21

@livierlambert @oehays Easiest backup to a remote location IMO is to NFS-mount a drive from some other system and back up to it. That way, it can always be exported to anywhere needed, even if your server(s) are destroyed and you have to start over from scratch.

@hansen I'd suggest booting off some Linux rescue disk and just redoing all the partitions manually. I ran into an upgrade issue once on a Dell box because of some stupid little extra utility partition they had in there. See: http://xenserver.pl/author/tobias-kreidl
Look for "The (In)famous Dell Utility Partition."

Tapdisk is just palin not good as a storage control mechanism, IMO. There's only so much you can pull out of it.

@ndrew Thank you for that, much appreciated. Although I was aware of this process for SSD drives, I did not know that spinning disks had become that much smarter in the interim (~40 years!). But in any case, raw drives are very powerful if you have decent code to access them and the overhead can be appreciably less than with formatted drives.

@ustavoninetyone -- it's not on the supported hardware list, hence highly unlikely. See Olivier's response near the top of this category to see what GPUs are supported.
-=Tobias

@livierlambert Indeed. NVIDIA in particular is bent on your having to license any sort of vGPU technology and it would not surprise me to see even passthrough leveraged at some point in the future. There are already restrictions on being able to make use of Quadro features, for example, of you don't have licenses.

Also, note that you need one video board reserved to run the native OS (XCP-ng) dom0 instance itself, so the server has to effectovely have at least two graphics boards such that one can be used as a GPU.

@enson Are all hosts properly time synchronized to NTP? Make sure they are all within reasonable limits of each other.
Might be a network thing -- are all interfaces configured alike on all hosts? Can the hosts all ping each other?

@asonnix Yes, a vCPU means a virtual CPU, which is the assignment of a VM to a physical CPU core.
Servers have sockets that contain physical CPUs, so it sounds like your system has four sockets, holding four physical CPUs.
Each physical CPU can have multiple cores and in some cases, one thread per core or in others, two threads per core, but let's stick
to the simpler case here.
A configuration of 4 cores with 1 core per socket means each of the 4 vCPUs will reside on a core on four separate physical CPU sockets,
so all four physical CPUs are accessed. This is in most cases not ldeal as in many servers with 4 physical CPUs, the memory banks are split between pairs of CPUs,
two on one bank, two on the other. Having VMs cross over physical CPU memory bank boundaries is generally inefficient and should
be avoided if possible. This is why NUMA (Non-Uniform Memory Access) and vNUMA become important in the configuration.
And @skger is correct that licensing can sometimes depend on the configuration.
I should add that under some circumstances, configuring the CPUs for turbo mode can be an advantage.
Suggested reading: my article on the effects of vCPU and GPU allocations in a three-part set of articles. In particular, Part 3 addresses
NUMA and configuration issues and Part 2 discusses turbo mode.
I hope this helps as it is initially quite confusing.
https://community.citrix.com/citrix-community-articles/a-tale-of-two-servers-how-bios-settings-can-affect-your-apps-and-gpu-performance/
https://community.citrix.com/citrix-community-articles/a-tale-of-two-servers-part-2-how-not-only-bios-settings-but-also-gpu-settings-can-affect-your-apps-and-gpu-performance/
https://community.citrix.com/citrix-community-articles/a-tale-of-two-servers-part-3-the-influence-of-numa-cpus-and-sockets-cores-persocket-plus-other-vm-settings-on-apps-and-gpu-performance/

@lanedrop At least with the higher-end NVIDIA GPU boards, you need special licensing to even tap into the Quadro features. Note that this is not to be confused with Quadro boards like the P5000 and P6000! They sure don't make it easy to figure out what is supported with what boards.
As to RDP, we ran with RDP on a Dell server with Windows 2012 servers some time back successfully. I think it was a PXXXX board of some sort, but don't recall which specifically.

@orza Just make sure whatever GPU you get either doesn't require a software license or take the licensing into account under consideration of your choice. In some case, you will require software licensing even for passthrough deployment. Also, make sure your server has an adequate power supply as well as ventilation to handle the GPU card.