@Andrew thanks for all your hard work. I guess time will tell if the Vates team has to add those defaults to their official package or maybe I just got "lucky"

@Andrew,

I realize this is an old topic, but found it to be VERY helpful and maybe it will be for someone else.

I decided to move to mini pcs (GMKTEC NucBox K6s) for my homelab/XCP-ng pool.

Although my RDP was pretty solid, and the VM behaved properly via my XOA interface, my network was CLEARLY not working with my Realtek 8125 NIC drivers while on 8.3. SMB transfers getting stuck (basically not working at all), and my pre-Xentools internet speed test was at ~200mbps download, while post Xentools I was only getting 2-7mbps (Xentools not XCP-ng pre-release guest tools). I'm sure an iperf test would've revealed the same problem with a local transfer as well. A problem no doubt! I found that the ethtool -K eth0 tx off tso off command corrected my issue but doesn't persist on the host. Bummer.

My interfaces basically matched the outputs already performed by the op.

My system is fully up to date and patched, yet the yum installer stated my r8125-module-9.012.04-1.xcpng8.3.x86_64 was "already installed and latest version" and I had "Nothing to do". Well this simply isn't correct for my use case!

I used Andrew's modified rpm package (notice the "-2" vs the "-1") in which he modified "with TXcsum/SG/TSO disabled by default. This fixes problems with Windows Server VMs an on-board RTL8125 chips".

Once I ran (as he suggested): wget https://users.ntplx.net/~andrew/xcp/r8125-module-9.012.04-2.xcpng8.3.x86_64.rpm & yum install r8125-module-9.012.04-2.xcpng8.3.x86_64.rpm my problems simply went away.

So I post this to help others (is it just me with this problem on the whole internet?), and pose the question to Vates: why is the updated installer not considered the most up to date package in your repo (in other words the ...-2 vs the ...-1)?

I can only assume that my issue (by using cheap mini pcs...which is MY fault of course!) is limited and the team doesn't want "TXcsum/SG/TSO disabled by default" for the masses using Realtek 8125 drivers. If that is the case, makes sense. I won't pretend to be smart enough to know the implications of doing that globally for all of 8.3.

Am I correct in assuming this? Is there something I'm missing?

Thank you @olivierlambert, Andrew, @gskger, and all others associated with the Vates team for helping the homelab community (smart because I also have a real enterprise I.T. sysadmin job and if left to me I'd use officially supported XCP-ng instead of cough hyper-v) and providing an open source product which is developed in a smart, planned way that works beautifully. Your contributions don't go unnoticed even though your community may have a problem or two every once in a while that we don't understand. ...Or bring upon ourselves

@HolgiB thank you. Since my instances are just for homelab, I'm waiting for a solution from Citrix/XS/Vates. I can afford to be stubborn and expect the parties that failed to supply a solution. But again thank you, if this was production I would do so. Or just use my backups and migrate data to a working instance. I'm just really curious how this happened and want to test if a solution is provided and when.

@stormi disabling that option won't let my VM boot. Just more BOD. I will continue trying things of course. My main concern is access to proper agents as the one referenced in XCP-ng docs seemed to have been developed and also abandoned in the year 2019! The other options have literally failed. This issue would frankly keep me from having confidence in the stack if I was to run in production. How could Citrix or XenServerProject let this happen? Including Vates, we're talking about a pretty mature system/dev stack at this point.

@clip I will add that I'm experiencing same results with Windows 11 (no TPM used) and a Ryzen hypervisor. Both working and blue screening VMs have uefi boot firmware and each have the same 9.3.3 XenServer Tools updated on 6/7/24. No MS update issues pre 6/17/24

@KPS I have the Citrix package installed and the XCP-ng "manage PV drivers via Windows update" toggled on. I remember being very careful on my initial setup and following the proper guidelines, but I wouldn't bet my life on it.

The more concerning thing for me is that I have 1 vm with the same configuration and it's fine, with another 2 blue screening. They are literally clones of each other. Maybe the others will fail soon too (I know it takes a couple reboots).

I have backups and remediation options to attempt as others have posted here. Ie: uninstall Citrix package, update, toggle off auto update etc. I feel confident I'll find the right combo.

Again, just strange that I've had none of these issues after all my years using this hypervisor. ... I love Vates and this community... So I'm not overly concerned yet.

Great work keeping an eye on this and thank you!!!!

@Toni yep. I had to do this too. 2 of my 5 Windows VMs got blue screened by the Citrix drivers. There is something going on beyond a doubt! My VMs have been flawless for years now until yesterday 6/17/24.

@StormMaster thank you. This workaround did exactly what i needed.