I finally got my lab updated and the two vms started, so far so good. Stats data is present, the first time I've seen any of my hosts pull 100% CPU. Hosts are little HP T740 thin clients with AMD V1756B processors and 64GB of ram, in a 3 host pool.
Sorry I can't bring more detail, not really doing work on my XCP lab right now, and lots of shake up around tech. space at work.
I decided to burn my lab down because of some trouble and wanted to start fresh to isolate any problems I may have created in the past. Wiped the disks, built a new NFS share ready for work, installed the XCP-ng OS and configured networking for the management interface on the local machines, all normal stuff. Went back to my desk and logged into XO Lite on each machine, using console --> xsconsole I was able to get all the hosts into a pool, and add an ISO and NFS SR, all seemed to work.
Went to the New VM to create a simple Debian vm on which I intended to host XO-CE from sources. Typed the info in, chose the Debian image from my ISO SR, the rest of the config as normal. Uncheck the boot after creation box, and create.
Click on the VM to bring the console up, then click power on... UEFI loader comes up, and ... Can't find the boot disk. Tried another iso that I knew was capable of EFI boot, same.
Realized I was trying to start in EFI, made a new one in BIOS mode, this one worked but now my screen shots are messed up so I'll probably have to go through and delete stuff with a different XO and go back to grabbing images of the process to write up "for the next guy".
Other than this small issue, it's working and doing it all from XO Lite. Yes still a bunch of missing features, but I know you are working on this. I just wanted to try things this way on this fresh build and see what I could get done from local console and XO Lite.
HP T740 with 64g of ram, 256g sata for OS, optional nvme for faster storage, optional 10gbe networking through low profile card. Works great for my lab.
Ran vSphere8 on three of them, running Harvester on 3 of them now. XCP-ng and vSphere8 work great, Harvester is a bit more resource hungry. Only the bottom three have nvme and currently have Harvester 1.7.0 running while I try to find time to learn more about this system.
My production pool upgraded fine as far as I can tell, but not so good with the windows drivers, I'll make a thread on the drivers.
Nothing really to add, my 3 host Intel production pool updated just fine. The load balancer is always a little weird, but I'm sure it is calculated based on CPU and RAM assigned to each VM, where I split things up based on workload.
It's a small system, and the real workload is handled by 3 Windows VMs so I tend to split them up onto one of the three hosts.
I may get to my lab in the next couple of days, but it isn't doing work so testing is kind of pointless right now. The only thing "doing work" is a VM with XO from sources.
BTW, the ram increase made zero difference in the VDI migration times.
I may still change the ram for each host in production, but I only have like 12 VMs right now and probably not many more to create in my little system. Might be useful if I ever get down to a single host because of a catastrophe. Currently running what it chose for default at 7.41 MiB, roughly doubled that in my lab to see what might happen.
Just got my VMware lab started so all this other stuff is going to back burner for a while. I will say I like the basic ESXi interface that they give you, I can see why smaller systems may not bother buying VCenter. I hope XO-lite gives us the same amount of function when it gets done (or more).
I was looking for a way to mark this solved, can't find it.
I haven't moved things, but after migrating my big lab to my mini-lab, I'm confident that the warm migration is the way to go. It was fast and seamless as long as you have the right network adapters set up. I had to fool with one of my networks to make a VM function, but that was certainly something I overlooked while setting up the mini-lab. A little testing before moving the VMs should make this go easily if using the old servers is the option for this project.
Thanks. I'm still going to wait until next week, my schedule just doesn't give me the time right now. But nice to know that when I do update, it will be fixed and my laziness prevented a problem for me 
I think I'll get my pool updated today, only been waiting a week at this point.
@coolsport00 You actually referenced my post, so I referenced yours as backup to the condition still being present. I think we just need to wait for them to finish making XO-lite what they seem to intend it to be, I think it's going to be good and I think they are doing a great job so far.
Also, I have a post somewhere about the UEFI not working from XO-lite, maybe they can be merged?
The wait period will be nice, after an RPU I'm watched VMs bounce back and forth trying to put themselves on another host. It's been a few updates since I noticed that, but a cooldown seems like a good idea, especially one that can be adjusted as you've made this one.
This reminds me that I have some work to do on my policy, mostly for anti-affinity.
I just set my lab back up from scratch, I can't remember for certain, but I think it pushed me over to v5 to set up the SR.
Indeed I will, but are the prices really that close? I was looking a few weeks ago with some replacements and spinning was still enough cheaper that it made a difference. I was looking for around 4tb enterprise class drives.
Just wondering about a possible XOstor configuration as far as performance:
3 hosts, each can have 3 spinning disks for HCI. Need about 6tb of usable free space and understanding each host is essentially a mirror of the other hosts. Total 12 drives in the pool.
What size drives would be best to achieve this? Would 2tb x3 drives give me this because they are not put into a raid like array on each host? Would I need to go 4tb x3 drives because it would make a RAID3 like array on each host? Or would I need larger x3 drives in each host? I only have SATA on these hosts.
Also how close are we to a "from sources" guide this would certainly get prototyped in my lab with a different drive configuration (single nvme), but I'd need to plan ahead for production. Time always being against me, it would take months to get this prototyped and the demo period will run out multiple times while I'm trying to work on this.
An example of time against me, I've had Harvester up for a month and still haven't build the first VM and haven't tried to get Rancher installed on a docker and integrated. It's certainly a much heavier lift to get to where XCP-ng and XO get you. I just feel like eggs in one basket is not something I should be doing (looking at you Broadcom and IBM 
).
The only GPU I've ever tried was nvidia quadro series, and that was probably under 8.2.
Truenas on bare metal just as storage, XCP-NG is also bare metal on 3 hosts to make a pool. That's the minimum if you want to enable High Availability, it also works really well as a "normal" pool which is what I have.
Rolling Pool functions are great, click the button and the system moves the VMS off of the host that need updates, reboots, moves VMs off of the next host, repeat. Only works with Shared storage.
I will make one suggestion that might be a problem for some users with really strict password requirements. Make the default password something more complex that doesn't contain the username or the word password.
One capital, one lower case, one number or special, and minimum 8 characters.
Alternate would be a note calling our where in the script the default can be edited, this way you don't have to do much, and those that need the default more complex can change it themselves before they run the script.
I'll try this in the future when I move me lab up to XCP-ng version 9, no timeline on this since I wanted it done two weeks ago.
[edit] full of typos today, please excuse my mistakes
My Truenas runs on bare metal, I have smb SR for iso, NFS SR for VMs, another smb for VMs.
In production I have a second old Truenas that that has smb and nfs that I use for storage updates, migrate from faster to slower storage which is still generally enough for my needs, update Truenas, migrate back to faster. I also have a third Truenas that has user data, but it's big so I set up a backup remote smb to spread out my disaster footprint.
In my lab is just a single bare metal Truenas with whatever kind of share I need. Generally just smh and nfs or iso and vm.
Both systems run three XCP-ng hosts so I can do things like rolling pool updates with no VM downtime. RPU is genius, all automated, just click a button and watch VMs move and hosts reboot.
I would restart the xcp-ng tool stack or do a rolling pool reboot.
Since your SR is hosted on Windows, I might uninstall the last updates and see if things start working. Then make a plan to move storage to Truenas.