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

@cHenry Am wondering if defragmenting the drives might help, at least some, if nothing else perhaps slightly better I/O performance?

@jkreidl Seems there may actually be a new NUC now after all:
https://www.youtube.com/watch?v=wQZ8oIU8leQ

@enson After enabling HA, the host has to be manually rebooted, which I think you're already aware of.
OK, well, that leaves pretty much a network issue. Hmm. The statefile created OK on the shared SR within the pool?
The "not found" error message doesn't give you much to go on, unfortunately.

@enson When you enable HA, note that the host has to be rebooted for HA to take effect. Was that the case?

@ikade Am wondering still if one of the hosts isn't connected to that SR properly. Re-creating teh SR from scratch would do the trick, but a lot of work shuffling all the VMs to different SR storage. Might be worth it, of course, if it fixes the issue.

@yte_Smarter It my be that the SR is not mounted on one of the hosts in your pool?

@yte_Smarter There's an ophan VDI locator in XenOrchestra, I believe. If the VDI is no longer associated with a VM, it's likely an orphan.
YOu can also use the command "vhd-util scan -a -p /var/run/sr-mount/<UUID-of-the-SR>" to look for orphans.

@ikade Oh, sorry, right...
What happens if you run a manual "xe sr-scan uuid=UUID-of-SR" ?
Do you have orphan VDIs? You said earlier there were no remnant snapshots.

@yte_Smarter Hmmm, can you migrate any VMs' storage to other SRs to free up more space?

@yte_Smarter Sure, that's of course possible. Does "xe task-list" show any currently running tasks? Anything else of possible value in the logs?