Thanks for the tips. All those items checked out. After a bit more troubleshooting involving a nearby switch and my VLAN routing, things are working a little more consistently, so I'm going to chalk this up to a routing issue elsewhere in my network. I'm just not used to a NIC turning off the link light if there's not a valid route.

@still_at_work Personally would say AMD, almost all XCP-ng servers I manage are AMD based and have been excellent so far. Usually a better value and better overall performance and their high core counts are great for virtualization unless you specifically need something that is faster single threaded. I have 3 hosts in my lab, all Threadripper (so baby EPYC) and they've been rock solid as well.

https://xcp-ng.org/docs/compute.html#vgpu This is what you need, Pass through. Not necessarily VGPU ($400 per seat). But! (Windows) Follow these steps: The link above. Do not connect the GPU to the VM you have. restart while holding shift so you can start with "safe mode + Networking" Before your VM gets to BIOS force Shut down. Attach RTX video Card Start "safe mode + Networking" Download and install NVIDIA drivers. Reboot You will have to do this to every VM that you need that RTX card on. Hasta la victoria siempre

I see, so you might need the UEFI info from the host or something similar I don't know if this exists, I have to admit I'm not using Windows in production myself.

You are welcome

I second @olivierlambert saying that you should consider EPYC, they are fantastic to work with, have moved my entire org to almost 100% EPYC systems and they have been nothing but rock solid reliable, fast, and efficient. You get more power for the money too and more expansion options. And both Intel and AMD run just fine, there aren't really any issues or differences that matter for most workloads. EPYC is mature at this point though, the "teething" issues from years ago are long gone, I have some first gen EPYC stuff running, some that have had uptime in the realm of a year without a single hiccup.

@olivierlambert I made a system update (yum update) and rebooted the server without interfering on grub menu... So it persisted on the same error... I nad to choose the second option again to do a good boot. I tried to find where those faulty grub log lines where saved, but journalctl just stored healthy boot.

Not sure to get it, so giving the question for @fohdeesha