@jasonnix Update to nodejs 22.x. It should be good for a while. Nodejs 24 will be out soon but not required yet.

@tjkreidl Interesting that ASRock is also using the NUC name. ASUS also has the new NUC15.

This new ASRock box uses the Ultra 7 255H which has 6P/8E/2LPE cores (no HT).

@TeddyAstie I ran iperf3 tests between two VMs on Xeon E5-2680v2 and average results were within 2% of each other with the patch being slower. Peak speed was 14.5 vs. 13.7 Gbits/sec.

@2planks Make sure your BIOS settings are correct. Make sure all the virtualization (VTx) and IOMMU (VT-d) features are enabled.

@escape222 Yes, using XO.

You can do a quick deploy of XOA as a bootstrap to build your own XO VM.

@escape222 I have no problem UEFI booting the same debian-12.10.0-amd64-netinst.iso image on XCP 8.3. I just created a new VM using the Debian 12 template and it worked correctly.

Can you try setting the DVD-drive first in the boot order for the VM (on the Advanced tab). You can disable the network boot too (and also maybe the hard drive as a test).

@archw Yes.

@cairoti I have had this happen to me.... With HA enabled, when the master fails, a new pool member becomes the new master. With HA enabled and shared storage, designated HA VMs should be restarted on the pool.

If you have stand-alone (per server) storage then VMs on the dead server can't be restarted because their storage is gone.

If you don't have HA enabled then you need to manually force a new master and restart failed VMs.

To force a new master on a pool member use the command xe pool-emergency-transition-to-master from a XCP console. You can't do much to the pool without a master. If your old master just needs to reboot quickly then just do that without changing the pool. If you master is going to be down for a while (more than a few minutes) then pick a new master beforehand, or after as a forced change.

It may take a while to force another pool member to become the new master as the members have to timeout contacting the old dead master.

With a failed master or pool member you have two choices:

1. Kick out the dead host from the pool forever (from the new master). After you fix/replace the dead host you need to REFORMAT and START OVER with a NEW install of XCP (there may be a reset command, not sure). You can then add the NEW host to the existing pool. You CAN NOT re-add a host that has been kicked out from the pool. IF you reformat the dead host and start over with a clean install, you need to kick the old host from the pool as the new server has a new UUID and you can't replace a pool member (just kick old and add new).
2. Don't kick out the dead host and fix the hardware (as long as the drives boot the same XCP data as before). Just turn on the host and it should join the pool and know that it was the master, but there is a new master now and it should just become a normal pool host.

If you fix the old master (and did NOT kick it from the pool) then boot it with the same disks, it should just connect to the pool and know there is a newer master. You can re-designate it as the new master if you wish or just let it be a pool member.

Yes, I have done this (again, just now as a test) with XCP 8.2.1

@ItsAlwaysDNS I still have some old Debian systems running just fine. XCP 8.2.1, HVM, Debian 7, upgraded kernel 3.16 (32 bit). They were cloned from hardware systems and just added the XCP agent. I have run even older systems (same age as CentOS 6) and they work correctly.

You can look at this old CentOS 6 post.

@bradmbreer You only need to connect to the pool master. XO will find the other hosts in the pool. If you connect to a non-master, XO will be redirected to the master. If you connect to other hosts in the pool (after the master) it will just give an error. Just ignore the error connecting to other hosts in the same pool.

@olivierlambert I have also run into a different problem. When I start a rolling pool update and I want to make things move faster I'll also manually migrate VMs off of a server that is pending a reboot. The problem is XO will then also migrate the already moved VMs to a new different server. The process should check if the next VM to be migrated is actually still on the server to be rebooted, if not then it should know the VM has already been migrated off (for some reason) and not migrate it again for no reason.

It would also be nice to have a dynamic number of VMs to concurrently migrate. If the VMs are not busy and will be easy to migrate (ie, low active CPU and memory) then it should migrate more concurrently. And/or have a manual selection when you click the pool update button (dynamic/all/some #).

@TS79 @ph7 @JamfoFL
For everyone's future reference: Here is a great XO install video thanks to @lawrencesystems . Also, read the XO from source install docs.

Remember, XO is open-source, so you are the beta tester. If you don't want to do that then Deploy XOA which has been tested and is supported.

If you have no idea what you are doing, just use XOA. Just click on Deploy XOA and follow the prompts. You'll be ready to go in minutes without any deep knowledge or google rabbit hole searches!

@JamfoFL I don't know exactly what you have been doing, but yes, you would normally rebuild after pulling in a new commit. I use the XenOrchestraInstallerUpdater update script by @ronivay . You don't have to update on every commit. You can just wait for the full release update that looks like feat: release 5.103.1

@JamfoFL I use an update script, and yes, it builds a new version after a git pull.

@JamfoFL I am running both XOA and XO source.

For the XOA I just use the Vates update. I don't do any changes to the OS. Don't mess with their packages, just use the update button.

For XO source, I update Node and the OS and rebuild XO for source updates.

@JamfoFL I have only current Node installed. After upgrading Node I rebuilt XO.

@JamfoFL I'm running Node 22 now. I was running 20 before without any problems. Node 18 was a long time ago...

@Mefosheez @anthonyper If it solves the problem, then great!

You can't set or change HAP, it's what the CPU chip supports. I was looking at the notes for the change and part of it is related to hosts that have small HAP sizes (ie, 4K, 2M, not 1G). As there are other updates in the same version the issues must have been fixed by a different part of the patch.

@Mefosheez Does your host not have large HAP size?

Please show the output from xl dmesg | grep HAP on your XCP host.

@olivierlambert @payback007 @flakpyro I tested my Win11 23H2 setup (on XCP 8.3) and had the same type of problem. Everything was updated and working on 23H2 with XenTools 9.4. Then Windows update ran and downloaded 24H2 and just got stuck after a reboot (windows logo and spinning circle). Force reboot made Win11 revert, so that good.

I un-installed the XenTools 9.4 (just from the control panel/uninstall) and then ran windows update again. This time it did update with a few automatic reboots. I then re-installed the XenTools 9.4 and everything is working on Win11 24H2 now.

I guess there is some problem between XenTools 9.4 and 24H2 update, not a XCP problem.

I did not test the ISO 24H2 update, just the automatic windows update.