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.

From my perspective, there's literally money on the ground for any virtualization platform to pick up VDI with Intel. The GPU's are affordable and performant for VDI work. They currently work with Openshift and Proxmox is at work on it.

When IBM/RedHat "killed" CentOS, the rest of the world took a hint and left. Companies and projects left CentOS in droves as the future of their products were in jeopardy due to the loss of CentOS.

At this point, the damage is done.

These latest 8.3 update speeds are still slower than a 13 year-old Xeon E3 1230.

@Andrew Thanks for that added detail.

Your success to Wasabi is encouraging. Perhaps Planedrops performance issues with BackBlaze B2 is related to a specific combination of implementation of S3 between BackBlaze and XO.

Things to test:

XO to AWS
XO to Wasabi
XO to BackBlaze

Theoretically, the performance should be the same to all S3 endpoints.

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

@olivierlambert

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.

@olivierlambert

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.