Updated both of my test hosts.
Machine 1:
Intel Xeon E-2336
SuperMicro board.
Machine 2:
Minisforum MS-01
i9-13900H (e-cores disabled)
32 GB Ram
Using Intel X710 onboard NIC
Everything rebooted and came up fine. None of my test systems are AMD based at the moment!
Not to bring up an old thread but was the issue of the Management agent version not properly being displayed with 9.4.1 after a migration ever figured out?
Updated around 43 hosts without issue.
@gduperrey im getting the following trying to update:
yum clean metadata && yum check-update
Loaded plugins: fastestmirror
Cleaning repos: xcp-ng-base xcp-ng-updates
4 metadata files removed
3 sqlite files removed
0 metadata files removed
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Excluding mirror: updates.xcp-ng.org
* xcp-ng-base: mirrors.xcp-ng.org
Excluding mirror: updates.xcp-ng.org
* xcp-ng-updates: mirrors.xcp-ng.org
xcp-ng-base/signature | 473 B 00:00:00
xcp-ng-base/signature | 3.0 kB 00:00:00 !!!
xcp-ng-updates/signature | 473 B 00:00:00
xcp-ng-updates/signature | 3.0 kB 00:00:00 !!!
xcp-ng-updates/primary_db FAILED
http://mirrors.xcp-ng.org/8/8.3/updates/x86_64/repodata/0a94f9d57be162987a7e5162b4471809af2ee0897e97cc24187077fb58804380-primary.sqlite.bz2: [Errno 14] HTTPS Error 404 - Not Found-:--:-- ETA
Trying other mirror.
To address this issue please refer to the below wiki article
https://wiki.centos.org/yum-errors
If above article doesn't help to resolve this issue please use https://bugs.centos.org/.
(1/2): xcp-ng-base/primary_db | 3.9 MB 00:00:02
xcp-ng-updates/primary_db FAILED
http://mirrors.xcp-ng.org/8/8.3/updates/x86_64/repodata/0a94f9d57be162987a7e5162b4471809af2ee0897e97cc24187077fb58804380-primary.sqlite.bz2: [Errno 14] HTTPS Error 404 - Not Found-:--:-- ETA
Trying other mirror.
http://mirrors.xcp-ng.org/8/8.3/updates/x86_64/repodata/0a94f9d57be162987a7e5162b4471809af2ee0897e97cc24187077fb58804380-primary.sqlite.bz2: [Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
One of the configured repositories failed (XCP-ng Updates Repository),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:
1. Contact the upstream for the repository and get them to fix the problem.
2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
3. Run the command with the repository temporarily disabled
yum --disablerepo=xcp-ng-updates ...
4. Disable the repository permanently, so yum won't use it by default. Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:
yum-config-manager --disable xcp-ng-updates
or
subscription-manager repos --disable=xcp-ng-updates
5. Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
yum-config-manager --save --setopt=xcp-ng-updates.skip_if_unavailable=true
failure: repodata/0a94f9d57be162987a7e5162b4471809af2ee0897e97cc24187077fb58804380-primary.sqlite.bz2 from xcp-ng-updates: [Errno 256] No more mirrors to try.
http://mirrors.xcp-ng.org/8/8.3/updates/x86_64/repodata/0a94f9d57be162987a7e5162b4471809af2ee0897e97cc24187077fb58804380-primary.sqlite.bz2: [Errno 14] HTTPS Error 404 - Not Found
Perhaps mirrors are still syncing?
Tested on my usual Intel test servers you've seen me post in this thread in the past as well as a 2 host AMD Epyc pool,(HP DL325 Gen10) rolling pool reboot worked as expected, hosts rebooted without issue, backups and replication appear to function as usual.
@TrapoSAMA Have you tried 3.6.0? The package is named "amsd-3.6.0-1867.26.xenserver8.x86_64.rpm" you should be able to find it on the HPE support site
Edit: i found a link to the RPM: https://downloads.linux.hpe.com/repo/mcp/XenServer/8/x86_64/current/amsd-3.6.0-1867.26.xenserver8.x86_64.rpm
I am currently running "amsd-3.6.0-1867.26.xenserver8.x86_64.rpm" on my DL360 Gen 11 servers. It's been working well!
Its also worth mentioning i had no luck with the newer amsd rpms as they have dependency errors. I am assuming just because the dom0 OS is CentOS 7 based and somewhat dated. I reached out to my HP rep about if the xenserver packages will continue to see updates but never heard back. Having to deal with a daemon like this to keep fan speeds under control will definitely be taking into account with this years server refreshes considering Dell and Lenovo do not have this requirement.
Echoing what @olivierlambert mentioned. I migrated a number of Almalinux VMs and they too would not boot until adding the Xen PV drivers.
@gduperrey Updated both of my test hosts.
Machine 1:
Intel Xeon E-2336
SuperMicro board.
Machine 2:
Minisforum MS-01
i9-13900H (e-cores disabled)
32 GB Ram
Using Intel X710 onboard NIC
Everything rebooted and came up fine. Ran a backup job which also completed without issue. Using a mix of ext, XFS and NFS SRs
This seems to be fixed in the latest commit and also does not happen in the just released XOA 5.108.0
@florent i have NBD enabled. Whats strange is i updated builds twice last week and backups continued to run. (Though progress in the tasks view disappeared as pointed out in this thread).
Last night we had a storm that knocked power out and my UPS's ran out of juice taking my home lab down, when everything came back up after backups would no longer run and would show ""invalid HTTP header in response body". I rolled back to a earlier commit (c7167 June 5th) and now not only are backups working again but progress in the tasks view is also displaying properly again.
Edit: Moved to commit 7994f from June 23rd and i still see progress there as well.
Mine was working on the latest commit however tonight due to a power failure my XO VM rebooted and now i too am experiencing the same errors. My hosts also rebooted as a result. Rolled back to a build from earlier this month and all is well again.
@manilx I am seeing this as well (on 2effd)
Vmware Education pricing back before Broadcom was insanely good. We are getting an Edu discount from Vates as well but its still more expensive than pre Broadcom VMware was. At the same time it's much cheaper than Broadcom owned VMware 
I just recently created a new "Golden Template" of AlamLinux, i noticed AlmaLinux 9 used BIOS in the XO provided Template however Rocky Linux 9 uses UEFI. Is there any particular reason for this? Is there a performance difference between either? I'm wondering if i need to start over and select the Rocky Template if UEFI does perform better. I also notice Ubuntu uses UEFI but Debian uses BIOS however i also understand there is much more of a difference there.
@rtjdamen I do know the dedicated migration network was an issue. CBT data would be reset if you preformed a migration using a dedicated migration network, removing the dedicated network was a work around there. The next issue was taking a manual snapshot and removing would sometimes also reset CBT data. Perhaps i need to spin up a test VM and try again and i know there have been a lot of updates.
Not to dig up an old thread but was the issue with CBT being reset to 00000000-0000-0000-0000-000000000000 after a manual snapshot is taken with NFS storage ever confirmed or reproduced by Vates? I would love to start being able to use CBT and purge snapshots after each backup run, or have there been enough changes / improvements that this is worth testing again?
@dinhngtu here is the output from one of the VMs recently migrated:
xe vm-param-get uuid=261634d9-b67c-1048-b028-2e33abea6329 param-name=PV-drivers-version
micro: -1; xennet: XenServer 9.1.7.65 ; xeniface: XenServer 9.1.12.94 ; xenvif: XenServer 9.1.13.107 ; xenvbd: XenServer 9.1.9.82 ; xenbus: XenServer 9.1.11.115
One thing i've noticed since upgrading to tools version 9.4.1 is that the version installed will display properly in XOA up until the VM is migrated. After a migration it changed to just "Management agent detected" with no version shown. Not sure if this is an XO issue or an issue with the tools itself?