@sluflyer06 Double check all your virtualization settings in the BIOS of your system.
There are some firmware updates that need to happen on the Intel cards that are frankly just easier to do in Windows, and even further in a physical machine (not passed-through). I had no issues updating my card via a passed-through Windows VM, but others haven't been as successful.
I agree that pass-through should just work.
I couldn't seem to get the GPU acceleration to work on a linux guest when I tried it on a Debian guest and I know if had the supported kernel running on the guest. I suspect this is due to the two different graphics devices on the guest VM (XCP-ng emulated and the physical passed-through GPU) and needing some sort of adjustments in X (Xlibre in my case) in order to tell it to use the GPU even though there's no display attached to it. I dropped that effort awhile back as I had bigger tasks at hand...But that's my suspicion. I need to tell X to offload processing to the GPU somehow, yet render the output to the emulated graphics adapter on the guest.
I've never really used GPU's for graphics acceleration on Linux. I don't game, and almost all of my Linux experience is headless server stuff. So I'm in uncharted territory for me.
@TeddyAstie That's more like it. I'm not finding the com2tcp though. I at least have something to search for.
Once configured, is this persistent or do I need to create some sort of start up script that runs/loads a config on machine boot?
Thanks!!
@dinhngtu If I'm following that correctly, this opens up a TCP port on the XCP-ng host and connects it to the guest VM. I need to go the other way. I need a COM port in Windows that I can send to a TCP address:port on the network.
This isn't exactly an XCP-ng question, but I'm wondering if anybody has a solution here.
I'm looking to virtualize a Windows-based workload that's primary application uses a unidirectional (sending) communication over serial.
I would like to get a "COM" port on Windows that redirects to an IP address/port. I have a vague memory of doing this in Windows 95, and I know I can do it with printers in Win10/11, but I cannot for the life of me see a way to create an IP-based COM port in Windows 11.
I have a few of these systems and I need the application to use the "COM" port that would send to a piece of middle-ware (IP Address:Port) that will accept the incoming command, translate it to another format and send on to the final destination.
This seems like it should be doable.
From what it looks like...If XCP-ng could move to kernel 6.8+ the Intel SR-IOV option should be on the table. That's a pretty massive jump from 4.19 and I have no idea how much effort that would be for you guys.
Nothing fruitful to add....
But...
Oooof....
This will be somewhat messy to clean up. I'm rooting for you guys though!!
I'm attempting to virtualize some media functions and doing video work on raw CPU is just crazy. (I've got an app running 80% on second gen 3Ghz Epyc with 12 vCPU's). I'm pretty sure if I had a vGPU to throw at it I could cut that down significantly.
From what I've seen, it looks like AMD is broken, NVidia works but requires expensive hardware and equally expensive licensing, and Intel isn't even remotely going to work.
Is that pretty much the state of things?
Thanks!
James
@olivierlambert While VDI is maybe not as vital as it once was...I'm experimenting with multimedia work in XCP-ng. Having a VM with GPU off-loading of CODEC encoding would be nice. It's a pretty big CPU hit to make that go.
@olivierlambert Ideally you need to be somewhere into Kernel 6. 6.12 is sticking out in my head, but I'm not positive when support got fully integrated.
@olivierlambert If I remember right, you should be able to see 62 VF's on that card. There might be a tool needed to define how many VF's are present like on a NIC.
@Forza said in Epyc VM to VM networking slow:
Would sr-iov with xoa help backup speeds?
If you specify the SR-IOV NIC, it will be wire-speed.
@olivierlambert From Intel's page:
"With up to 62 virtual functions based on hardware-enabled single-root input/output virtualization (SR-IOV) and no licensing fees, the Intel
Data Center GPU Flex 140 delivers impeccable quality, flexibility, and productivity at scale."
Generally speaking...Just because you haven't had direct requests doesn't mean the feature isn't desired.
It's easy enough to look over the current features and because it's not listed, you assume it's not there and move on to find the next viable solution.
Proxmox and OpenShift seem to be killing it in this space with Intel Flex GPU's.
I can't believe that there's not much interest.
Anyway...As far as I know these are pretty well supported in newer kernels. I think you need to be fairly deep in kernel 6. Given that XCPng/XenServer is currently running on kernel 4 with a bunch of backports, this might be a little problematic.
Last I knew, Intel is not charging licensing fees for using vGPUs like NVidia does.
With a working driver in XCP-ng and no licensing fees, this is could be a real cost-effective VDI platform.
I just added a P4 to one of my hosts for exactly this. My servers can only handle low-profile cards, so the P4 fits. Not the most powerful of GPU's but I can get my feet wet.
These latest 8.3 update speeds are still slower than a 13 year-old Xeon E3 1230.
While not critical...It would be nice to have the same dialog for system disks as we do for system names in the multiple VM's section under "advanced." Seems like a really easy thing to add that would prevent someone from having to go back and rename disks later. The system is already creating a name, it's already giving us the ability to name the disks for singles, why not be able to name the disks like the systems for multiples?
Okay...Updated to latest commit. Still behaves the same
@DustinB I'm on ee6fa which is apparently 11 commits behind. I'm updating now. and will retry a multiple VM deployment and see what happens.
My understanding is that the "name" of the disk doesn't really matter so much as that's more for us humans. The system mainly works off of UUID's which are unique.
I'll post back later.