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

@abudef @olivierlambert @thomas-dkmt I agree. I read block the same way... how about disable or prevent. (French? empêcher)

@julien-f @olivierlambert

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

@gduperrey Installed and running on Intel systems, and Zen3 system that sees the microcode update.

@stormi I did a standalone host ISO install, all works as expected. I also did a pool ISO upgrade (8.2.1 to 8.3), master first, others second, migrated live VMs from old to new, all works as expected.

@TrapoSAMA AlmaLinux 10 does have a x64 version that still supports Xeon v2 systems. ISOs here.

When you UEFI boot normal Alma 10 on a v2, it just stops, there's no additional error.

@dnikola almost 300 reports of Temperature above threshold. Lots of segfault and general protection errors in Dom0.

It's looking bad for the physical environment and hardware in use. Overheating, CPU issues, Memory issues, USB issues, etc... They can all be related to form an unstable system, very bad for a VM server.

@dnikola That machine is a hot mess.

@olivierlambert No IP record... Using Debian 11 with Management agent 1.0.0-proto-0.4.0. It's a non-standard interface setup with the IPv4/IPv6 assigned to the bridge interface. The agent does not report any addresses up to XO.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 32:a9:24:28:18:56 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:31:46:59:66:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.33/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2000::5031:46ff:fe59:66a1/64 scope global dynamic mngtmpaddr
       valid_lft 2591833sec preferred_lft 604633sec
    inet6 fe80::5031:46ff:fe59:66a1/64 scope link
       valid_lft forever preferred_lft forever

@gduperrey I updated my little AMD Ryzen 5 5600U (Zen3) and it's running great!

As for the important VM to VM network performance, using Debian 13 and iperf3 single thread, before (update not enabled) is about 7.2-8Gb/sec. After the update (xen-platform-pci-bar-uc=false) I get about 10.1-13Gb/sec. So that's about a 40-60% improvement. This brings it in line with similar small Intel systems.

I did not see any change (or problem) setting it on my small test Intel system (getting about 10.1-10.8Gb/sec).

FYI: Remember, after the config change and xe-toolstack-restart, restart the VMs!

@gduperrey Updated and running. Single hosts were fine. No AMD testing.

Upgrading a busy pool seems to have had some odd issues with VM migration, but all seems to be running fine now. I had upgraded the pool from 8.2.1 to 8.3 last month and everything has been fine. This time (after rebooting pool master) while trying to migrate guests so I could reboot hosts got a few XO errors like:

xo:api WARN admin | vm.migrate(...) [1s] =!> XapiError: INTERNAL_ERROR(Object with type VM and id bd38ee46-2701-3022-ec61-03bf3ffbdcc9/config does not exist in xenopsd)
xo:api WARN admin | vm.migrate(...) [2s] =!> XapiError: INTERNAL_ERROR(Object with type VM and id 235de1d7-832e-f1a7-fa1c-a45877aab8f6/config does not exist in xenopsd)

It was only a few on one host. I can NOT confirm this is related to the updates as I'm not having problems now. After manually rebooting the host and stuck guests, things were ok again.

@stormi Unless new Dom0 is Kernel 6.15 or newer (with updates), this will be an ongoing problem to support the newest hardware as they seem to keep updating the chips (you can't stop progress).

The current r8125 driver in 8.2/8.3 supports the 8125 and some 8126 chips, but not 8127. Other than supporting the new hardware versions of the chips, I have not seen any real complaints posted about the current r8125 driver (may be there are some Vates tickets?)

While the risk on the new driver is low, it is different (not just an update). I agree that it would be best to have r8125-module-alt for the new code and then r8126-module and r8127-module.

Note, that the new r8126-module driver should not be installed without the r8125-module-alt as the existing r8125-module would conflict with the new r8126-module driver.

The work is already done (compiled and running)... I'm just waiting for Realtek to fix some issues with the new code before it's worth fully testing the drivers (issues already acknowledged by Realtek).

@cairoti The data that is sent and stored on the remote is locally encrypted. The volume as a whole is not encrypted.

@bryonadams Please try HTTPS (tcp port 443).

@acebmxer Did you activate your License?
Click on XOA then Licenses (at the top). Make sure you see This license is active on this XOA