I probably would have just bought a cheap mini PC and used Virtual Box for this, which is something I did do in the past for an old XP machine when the hardware started to fail. Grabbed a disk to vhd of it before the final failure and loaded it into Vbox.
Might be able to do this in nested virtualization in XCP-ng.
Yes, master is really the host that controls all of this stuff, so you would need to run the command on a host running as master.
Each host defaults to be its own master, but when you join one to a pool it will "demote" itself from that role.
I'm doing the latest production level updates announced yesterday... My pool has never migrated VMs as fast as it is now.
That was migrating several at a time, moving VMs back to "balanced" at the end is moving them at about half that speed one at a time. This is more than double what I was able to do with the same hardware on 8.2.1. It looks like it is actually capping at the maximum 10gbps speeds that the x710 cards and my switch can handle, that's never happened, not even on my lab which has been on v8.3 for over a year.
(note to self, might be time to upgrade those x520 cards in the lab to x710)
Next month's Windows updates might be interesting, hope this increase holds for that process too.
Uggg... Just after I upgraded 8.2.1 to 8.3.x and did updates. Guess I have more waiting for me for later today or tomorrow.
I went from Citrix 9.3.3 to 9.4.1, and generally they have remained manual when I've upgraded. All these VMs started out with 9.2.x so this is probably the fourth update to them.
And all that said, I know the MAC address did not change, because I had a reservation for one of them and it was found properly before putting it back to manual. I think the XCP-ng side of things worked properly (no MAC change), but the driver side was the issue, and nothing you can fix since you don't write this driver.
I probably should have used the cleaner first, but I went straight to the Citrix installer like I've done in the past. Took about an hour to get the 5 VMs updated, now I can move on to other things that have been lacking. I've mentioned it a few times, but this construction has me way behind for the summer, and only a few weeks of work time left before students come back.
Better late than never I guess 
4 out of 5 of my Server 2022 VMs needed to have the networking set back to manual after the driver update. 5 out of 5 need to have the system drive marked as non-removeable, but I need to move on for a couple other things before swinging back to the system drives.
I let it sit for an hour while I was at lunch, if it didn't pick up by then, it wasn't going to restart. I haven't had time to look through the logs but I'd guess there was a timer that expired since it was taking so long to reboot the Master host.
All three of the hosts took about 30 minutes before reboot.
And then the load balancing was all wrong, when I finished the updates I did a rolling pool reboot. It refused to put any VMs on host 2 during this process, and once the pool reboot finished it spent about 30 minutes migrating VMs for what appeared to be no reason, twice ending up with all VMs on host 1 or host 3. After it finally stopped migrating, I manually migrated a few VMs off to host 2 and left it alone for the night. Just got back in and will be checking things this morning.
I'm doing the latest updates on my production pool, and found something that is really just an annoyance more than a problem.
3 hot pool with Intel Silver v2 and 128GB of ram in each host.
Click on the pool, go to updates, hit the rolling pool update button. VMs migrate out as normal, update get's transferred to Master as normal. Took over 30 minutes after this step to reboot.
Upon reboot, VMs did not migrate back. Task for Rolling pool update did not pick up where it left off. Manually migrated a single VM back to Master to see if things were really still working, seemed OK.
Went to lunch to see if it would sort itself out. Nope.
Came back from lunch, went to the third host and entered maintenance mode to migrate all the VMs, when done told it to install updates, when done told it to reboot. Waiting about 20 minutes so far and guessing it will be a full 30 before it reboots.
Why I say this is an annoyance more than a problem, because we need to be on XCP-ng 8.3 in another two months so I'm not sure this is worth a fix as long as everything functions when I have all three hosts updated.
We have a group of colleges together, and they got the price down to $120 per core for VCF, there are no other levels to buy.
And for the small system that we have, Vates would not be a huge amount less, only a couple thousand a year less which doesn't really push to find a different solution. But again I have not looked into education discounts yet so if that cuts the price in half, then it would be substantial enough that they might think about changing. We also pay for Dell vxrail, not sure how much that costs, but allows us to not employ a person to handle the cluster.
There are scripts to run that will set up the XO-CE, even an image you can download directly and answer a few questions to set the IP, etc. while downloading it. It's not hard and easy to document. If that user goes away, then it might get more complex, but there are a couple people that have made scripts on github to get the XO-CE running on many Debian based and many RHEL based linux, I think there is even a docker image if you are using docker stuff.
But I agree looking out for "the next guy" is something that needs to be done whenever possible.
As far as pricing for non-profit education, I'll have to contact sales again and see what I can do. I checked several years ago when things were kind of separate, now that support is all encompassing I need to check back and see what it will cost. I've just been running the XO-CE version but I like to support projects where I can, and if I can wedge a little money into my budget for support, I certainly will do that. With only 3 hosts and a handful of VMs, it's hard to come up with the money for the lowest tier.
One thing I really want to work with is XOstor, I think in my system this might be a good way to go forward for me. Cheaper than building new NAS (about $5000 each for two of them).
All that said, if it is a simple enough system, you probably aren't going to need much support beyond these forums.
[edit] Are we allowed to attach PDF documents to a post? I have simple instructions from when I set up 8.2 in my lab. I don't have newer documents made for 8.3 using XO-lite yet, but screenshots to put to words. XO-lite is changing the knowledge burden to get up and running by a significant factor, and I like where it is going!
Has anyone tried turning off delta, and turning off compression?
Not ideal, but its how I'm dealing with some different issues (windows with big empty disks).
OK, 3 months is good because I'm in a nasty bind right now and this may need to wait until August. I would expect many other places to have the same issues.
Can you simply change the filter to "none" in the vm view to see those that are stopped (red icon)?
This only works if the master host is still running, if that host crashes, you have more work ahead of you.
I also suggest having an XO from sources running somewhere else, like a laptop (VM or hardware), or an old low power server, in a VM on another pool, etc. That way if the host running XOA or XO-CE fails, or the VM just crashes, you will have a backup.
Also keep you XO config backed up since it is pretty quick to deploy a new XO and blast the config onto it.
In version 8.3 you could also log into the XO-Lite and see the VMs that are running and those that are not.
So is that June 25, 2025 or 3 months from now as the drop dead date?
With 8.3 becoming LTS, what happens to 8.2.x? How long will it still receive security updates?
Trying to decide if this is a drop everything and upgrade moment, or if there is some time available before upgrading is required. While my 8.3 lab has been solid since switching (disregarding user created problems), I'm not sure I want to go through an 8.2 to 8.3 upgrade right now.
Also with 8.3 going LTS, does this mean that a 9.x Beta will be available soon? It looks like Alma just released v10 which I've read is going to be the basis for XCP-ng 9.x, or is this still a mountain of work to overcome to get to a Beta? The newer kernel functions like the NFS options is something I'm looking forward to testing.
Here is some info on setting the disks so that they are no longer removeable, I think the last time I did this I just needed the registry edit to fix it.
I'm kind of stuck waiting to migrate my firewall before I can get back to fixing my VMs. I only have 5 and one of them is not showing the warning. All of them should have been getting updates from the management agent or from Windows Update, not sure why only 4 give the warning.
Just an FYI,
So far the only 2022 VM I've updated has created new network adapters which defaulted to DHCP, and it has marked the system drive as removeable, which we saw with 2025 almost a year ago.
Make sure to write down your static IP addresses before beginning.
This is from installing Xenserver MA 9.4.1-160
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.
Off topic, how does XCP handle the E and P cores in that 13900 machine? That was one of the considerations that made me skip these Intel processors in favor of AMD.
I'll get mine updated as soon as possible, on going work to clean out my tech room so it can get cut in half for class space. Goodbye future expansion if we need it!
No issues so far with my production system (8.2.x) and this batch of important updates, these are on Intel Silver (v2?) processors.
But my system is so vanilla that I doubt there would be any issues anyway. The only "out of normal" thing I've done today is storage migrate a VM off of one Truenas to another so I can apply some updates to Truenas. Then I'll migrate everything to the updated server so I can update the "main" storage.