@gduperrey Installed and running on a few hosts. Good so far.

@gduperrey Installed and running on a few pools. Working correctly as expected.

It would be nice to have an "unregister" button, or better, a "use free license" button.

@stormi Got it... I missed that one for coretemp. Vates ticket opened for the XOA stats problem after 8.3 upgrade.

@stormi Upgrade problem... I upgraded a good working busy 8.2.1 server to 8.3 (using the new ISO). The upgrade went well without error. No guest VMs were changed.

Same issue in XO (Master 7be70) and XOA (5.107.2), so it must be an XCP issue. There are three new problems (all was working before);

1. XCP coretemp no longer loads/works. Error: coretemp coretemp.0: Adding Core 0 failed
2. XO Host CPU stats and Load are now reported as zero (It's a busy machine, they are not zero)
3. XO All guest VMs report zero CPU usage. Some just report No stats. for CPU. They do have current recognized guest tools (Linux and Windows). They do report other stats (memory, network, disk).

Other older XCP 8.3 hosts/guests are working.

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

@dinhngtu @olivierlambert @stormi I think the Windows VM's with old tools should show up in the Dashboard Heath report under "Guest Tools status"...

@flakpyro From my experience, VM with UEFI boots faster than BIOS. For some OS versions UEFI runs faster IF there are no Xen drivers. But for most installs it does not matter much, except for Debian... which has given me problems with pool/migration/reboot with the UEFI installs on XCP (there's a workaround).

So, I would vote for UEFI as the default for all OS/VMs that support it correctly since most are moving to that anyway (including XCP hosts).

@olivierlambert Any backups that run cause RPU to fail and not continue/restart. My example of this is hourly continuous replication breaks RPU.

@olivierlambert @flakpyro Commit 2fd5759 seems to solve the issue for me.

@xcplak With a LVM guest, you can restore the whole VM now. The backup data is actually saved correctly and it is possible to manually restore a single file. So they can fix XO and the old backup data is still good.

@flakpyro Nice catch! I see the same problem.

@olivierlambert @florent Running XO source (master 6ed35). I see the Windows VMs in the CR backup job report, but they no longer appear on the destination host as a VM. Some have updated tools, others do not. It worked before... Non-windows VMs seems to be fine. These are all old VMs, so it's a new problem on existing systems.

@olivierlambert @florent I still hit a single thread limit in the XO VM that makes backups CPU bound limiting performance as before.

@peo Still an existing problem:
https://github.com/vatesfr/xen-orchestra/issues/7029

andrew64k created this issue in vatesfr/xen-orchestra

open File level restoration not working on LVM partition #7029

@snowstruk The stock XCP 8.3 r8125 driver works for my 8125 and 8126 devices. I have not tried it a 5G, so it's possible the 8126 is not working at 5G (I don't see it advertised) with the current driver.

I have run the current dedicated realtek 8125 driver and it works but I have not tried the 8126 driver. I don't know how many people are using the 8126 chipset (I guess not many).

If your device is not working at >1G then it sees to be a hardware incompatibility issue. You could try loading the new 8126 firmware to see if that helps.

Here's the output about my test 8126 card (attached to a 2.5G switch):

# lspci -v -s 04:00.0
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8126 5GbE Controller (rev 01)
        Subsystem: Realtek Semiconductor Co., Ltd. Device 0123
        Flags: bus master, fast devsel, latency 0, IRQ 18
        I/O ports at 3000 [size=256]
        Memory at e0d00000 (64-bit, non-prefetchable) [size=64K]
        Memory at e0d10000 (64-bit, non-prefetchable) [size=16K]
        Expansion ROM at e0d20000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [b0] MSI-X: Enable+ Count=32 Masked-
        Capabilities: [d0] Vital Product Data
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [148] Virtual Channel
        Capabilities: [170] Device Serial Number 01-00-00-00-b4-b3-c9-88
        Capabilities: [180] #19
        Capabilities: [190] Transaction Processing Hints
        Capabilities: [21c] Latency Tolerance Reporting
        Capabilities: [224] L1 PM Substates
        Capabilities: [234] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?>
        Kernel driver in use: r8125
        Kernel modules: r8125

# ethtool -i eth1
driver: r8125
version: 9.012.04-NAPI-PTP-RSS
firmware-version: rtl8126a-2_0.0.2 02/01/24
expansion-rom-version:
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

# ethtool eth1
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseX/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseX/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
                                             2500baseX/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 2500Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

@ThierryEscande I ran the update and it's passing good data (on an older card that worked before).

@stormi From Debian 11:

# ethtool -i enp0s25
driver: e1000e
version: 5.10.0-34-amd64
firmware-version: 0.2-4
expansion-rom-version:
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

@MathieuRA For this issue, fix-server-connect works for me. Thanks.

@creoleMalady On your NFS server, do you have sync writes enabled or disabled?

@olivierlambert Realtek has released three related ethernet PCI chips: RTL8125 (2.5G), RTL8126 (5G), RTL8127 (10G).

Realtek started with a single driver that supported the 8125 and 8126 as they are closely related. The current XCP driver is based on that single set of code. Now they have split the code into three different drivers.

The problem is they have released new versions of the RTL8125 that require new driver code to work. This already caused problem in the mainline upstream Linux and required updates to the kernel driver (early 2025) and at least one XCP user has hit this problem on a desktop board. Since XCP is using the vendor driver, the question is what to do next:

1. Do nothing and let people use other ethernets
2. Make a new alt-driver for only the 8125 chip (no 8126 support), leave the old 8125 driver alone (maybe for 8.2?)
3. Use the new Realtek 8125 code and add new drivers for the 8126 and 8127 (maybe for 8.3?)
4. ???

The path forward could be different for XCP 8.3 vs. 8.2.1 ...