@stormi Microcode updated on affected Gen11 i7. Running normally.

@gduperrey I jumped in all the way by mistake... I updated a wrong host, so I just did them all. Older AMD, Intel E3/E5, NUC11, etc. So far, so good. Add/migrate/backup/etc VMs are working as usual. Good for guest tools too, but mine are mostly Debian 7-11. Stuff is as usual so far.

I agree and I'll say it again, Thanks! It's not just Linux/Xen stuff. It is XCP-ng and XO that make everything work as a cohesive vertical open-source solution (some nice buzz words). Thanks to the Vates team and community that have built and support it. I look forward to ongoing continuous improvement and innovation!

@bleader Installed and running.

@bleader Updates running on several old and new intel machines (including microcode update). Working fine so far. Rolling Pool Reboot is a helpful feature.

@bleader I installed it on a bunch of busy hosts. All are fine, but none used PCI passthrough. The Rolling Pool Reboot in XO was very helpful.

@julien-f @olivierlambert

Thanks for the ability to delete XO task logs feature! (XO commit f6e6e)

@gduperrey I have several hosts updated and running. I'm happy to see 8.3 updates on parity with 8.2.

@stormi Installed on several test and pre-production machines.

@bleader I installed it on many 8.2 machines. On one I did get a warning:

  Cleanup    : xen-libs-4.13.5-9.40.3.xcpng8.2.x86_64                     14/14
warning: %posttrans(microcode_ctl-2:2.1-26.xs29.5.xcpng8.2.x86_64) scriptlet failed, exit status 1
Non-fatal POSTTRANS scriptlet failure in rpm package 2:microcode_ctl-2.1-26.xs29.5.xcpng8.2.x86_64
  Verifying  : xcp-ng-release-8.2.1-13.x86_64                              1/14

But it did not seem to have any effect. Nothing extra in the yum.log

@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.