@stormi Installed on our 2 production pools, DR and remote sites, 46 hosts total ranging from Dell, Lenovo, HP, and Supermicro servers, no issues to report!

@gduperrey

installed on 2 test machines

Machine 1:
Intel Xeon E-2336
SuperMicro board.

Machine 2:
Minisforum MS-01
i9-13900H
32 GB Ram
Using Intel X710 onboard NIC

Both machines installed fine and all VMs came up without issue after. My one test backup job also seemed to run without any issues.

@gduperrey installed on 2 test machines

Machine 1:
Intel Xeon E-2336
SuperMicro board.

Machine 2:
Minisforum MS-01
i9-13900H
32 GB Ram
Using Intel X710 onboard NIC

Both machines installed fine and all VMs came up without issue after.

I ran a backup job after to test snapshot coalesce, no issues there.

@stormi Updated a test machine running only couple VMs. Everything installed fine and rebooted without issue.

Machine is:
Intel Xeon E-2336
SuperMicro board.
One VM happens to be windows based with an Nvidia GPU passed though to it running Blue Iris using the MSR fixed found elsewhere on these forums, fix continues to work with this version of Xen.

@dthenot @olivierlambert thanks guys ill hold off on submitting a ticket for now to keep the conversation centralized here but if you need any more info, would like me to try anything or would like a remote support tunnel opened just let me know!

@CodeMercenary I am using V4 on the XO-Server to our backup remotes and it seems to work just fine. However using V4 as a storage SR was nothing but problems, as @nikade mentioned we had tons of NFS Server not responding issues which would lock up hosts and VMs causing downtime. Since moving to v3 that hasn't happened.

Checking a host's NFS retransmissions stats after 9 days of uptime i see we have had some retransmissions but they have not caused any downtime or even any timeout messages to appear in dmesg on the host.

[xcpng-prd-02 ~]# nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
268513028   169        268537542

From what a gather from this blog post from redhat (https://www.redhat.com/sysadmin/using-nfsstat-nfsiostat) it seems like that amount of retransmissions is VERY low and not an issue.

Until the XO update is released by Vates you can filter your PV Driver version using the following:

pvDriversVersion:!9.4.1

This will show you all VMs not running that version. If you have Linux VMs they will be shown in this filter. If you have tagged your windows VMs you can combine this with a tag for example:

power_state:running pvDriversVersion:!9.4.1 tags:/^Windows$/ 

Remove the ! to filter for VMs that are running the latest 9.4.1 version.

@stormi Updated both of my test hosts.

Machine 1:
Intel Xeon E-2336
SuperMicro board.

Machine 2:
Minisforum MS-01
i9-13900H
32 GB Ram
Using Intel X710 onboard NIC

Everything rebooted and came up fine. The MS-01 i test with uses i40e and intel-igc not the e1000 driver. The other machine with the SuperMicro board uses igb so im afraid i'm not much help in testing that driver.

yum commands did seem to work from the small handful i ran.

And yes, stats do indeed work again

I never noticed the issue with Server 2025 and hanging on reboot since the updates from last week. Were you able to see anything in the dump files i sent?

@stormi installed on the same test machines i have the other batch of updates installed on. No issues after a reboot.

@gduperrey Installed on the same 2 hosts as the last batch of test updates released in December.

No issues to report so far, ran a backup job after after without issue.

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 

@dinhngtu

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?

Seems fixed in XOA 5.107.1

@olivierlambert I think so! All my regular Delta+CR combination jobs run as usual tonight without issue which is good news after such a massive change.Ii can see the newly replicated copies when looking in XO-Lite or XCP-NG center so likely just a UI issue that is hopefully a quick and easy fix!

@florent so testing a CR job with the latest XOA release. The job runs successfully and i can see the virtual disk on the remote SR however the replica does not appear in XOAs VM inventory view.

Edits:
They do appear in XCP-NG Center,and XO Lite
They do NOT appear to show up using xo-cli list-objects
This also appears to ONLY happen to Windows VMs. Maybe related to missing templates?

VMs that have not yet even ran their daily replication job also seem affected. Replicas that ran last night and appeared in inventory before the update now now longer appear in the VM inventory list. This might be related to something else that was changed in the new XOA update?

@Tristis-Oris have CR jobs started working for you with the latest master code?
@florent Understod! Our XOA appliance has been on the latest branch since we deployed it almost a year and a half ago. Though with all these changes i may consider dropping it down to stable for a bit as backups are pretty critical. We only use Delta jobs (Which seem to be working well) and Continuous replication jobs. (Which i have seen some issues with recently in this thread).

Until the XO update is released by Vates you can filter your PV Driver version using the following:

pvDriversVersion:!9.4.1

This will show you all VMs not running that version. If you have Linux VMs they will be shown in this filter. If you have tagged your windows VMs you can combine this with a tag for example:

power_state:running pvDriversVersion:!9.4.1 tags:/^Windows$/ 

Remove the ! to filter for VMs that are running the latest 9.4.1 version.