olivierlambert
I am not pretending to be a specialist in this area. However, KVM did it years ago AND it is open source. Furthermore, there are countess DIY guides from back when it wasn't implemented in KVM yet. The way I understand it the main things that need changing are the hypervisor CPU feature flag and CPUID leaves which need to be hidden from the guest and the hardware vendor id which needs to be set to something random.

I've checked the other Nvidia threads on this forum. People are complaining about this problem for more than a year. Furthermore, they are giving references to guides and sources on how its done with KVM.

What does "it is really complicated" mean? If the XCP-NG team does not how to do it, even when it is known what causes the problem and there is an open source solution to serve as example, then how did you even get where you are now? Don't pretend. If you really wanted to you could have implemented it by now.

At one point I was even considering paying for XO, but this really is a deal breaker for me.

olivierlambert
Of course I am not alone and of course I am not implying to leave all other work and deal with this. I was just asking if it is a possible (albeit "hacky") and strictly DIY solution (no up-streams or anything like that).

I will gladly look into this some more over the incoming months when I have the time and preferably appropriate hardware.

olivierlambert
Okay I haven't checked the XEN sources extensively but I presume that those 'static values' you are talking about are hard-coded somewhere in there. From what I have read, Nvidia's detection method is to look for specific strings in specific places. I believe that (at least part of) the KVM patch is to randomize those values.

So, at least theoretically, wouldn't it be possible to hard-code different values and recompile the whole source? That should provide at least a temporary fix, and I understand that everyone would have to do it for themselves, but perhaps it would be possible for someone with a more detailed knowledge on the project to create a guide, perhaps on the wiki, which people interested in this and with enough technical expertise can follow.

olivierlambert
I see, 4.14 is supposed to be released sometime during the summer if I am not mistaken?
Can you elaborate a bit more on "could come with a code base that would be easier to modify for what we need". What makes you say that?

olivierlambert
Sorry, I did not intend to be rude. My point was that it is a known problem with a known solution (albeit for a different code base).
I would love to take have a go with implementing a patch. Unfortunately at this time I do not posses neither the hardware, nor the knowledge or time to do it (day job and family).

Otherwise I agree with Biggen. This is a really niche use case and not many people are interested in it, therefore it is not considered important. Thanks for putting it in a more understandable way mate.

It just sucks to be on the minority side I guess.

P.S. olivierlambert Are you saying that there are no plans for implementing a patch for this in the future?

EDIT:
Biggen as far as I know only vGPU enabled cards (Grid/Tesla) do not have this problem, and even so those cards require crazy subscription-based licenses to work. We are talking about sums that only enterprise data centers can afford. Furthermore, even if you have a Tesla card + license you still cannot do a PCI pass trough - you are limited to assigning "slices" (vGPUs) to the VMs + you need a proprietary driver on the host for that to work and such does not exist for XCP-NG.
Consumer, Titan... PCI passthrough = code 43 (unless you find a way to trick the drivers to think they are not running in a VM). I read mixed reports about Quadro, so I would say that those are a hit or miss, depending on the card and driver used. About the drivers themselves - basically older drivers are more likely to work and by older I mean downloaded in the past older drivers. I read complaints in other forums saying "driver XXX worked before but when I downloaded it now it does not work anymore" so my guess is that they have recompiled the older drivers to include the code 43 error.

olivierlambert
I am not pretending to be a specialist in this area. However, KVM did it years ago AND it is open source. Furthermore, there are countess DIY guides from back when it wasn't implemented in KVM yet. The way I understand it the main things that need changing are the hypervisor CPU feature flag and CPUID leaves which need to be hidden from the guest and the hardware vendor id which needs to be set to something random.

I've checked the other Nvidia threads on this forum. People are complaining about this problem for more than a year. Furthermore, they are giving references to guides and sources on how its done with KVM.

What does "it is really complicated" mean? If the XCP-NG team does not how to do it, even when it is known what causes the problem and there is an open source solution to serve as example, then how did you even get where you are now? Don't pretend. If you really wanted to you could have implemented it by now.

At one point I was even considering paying for XO, but this really is a deal breaker for me.

olivierlambert
I hope you are being sarcastic. Of course it is on purpose. Nvidia are known to f around with people like that. Why are you refusing to implement a simple option to hide the hypervisor like KVM does?

jtbw911
I am not a fan of unraid, not to mention that is paid as well. My other option is Proxmox, but I would like to avoid it as I find XCP-NG and XO much more flexible and easy to administrate.

About why Nvidia, I am planning on replacing my gaming machines with gaming VMs, and currently Nvidia Gamestream + Moonlight is the lowest latency solution that exists.

I am open to suggestions of course, but the way I see it this is the best way. The only problem is the that the hypervisor cannot be hidden from the guest OS in XCP

Re: XCP-ng and NVIDIA GPUs

I was just wondering if this problem has been solved or if there is any progress towards it.
I am about to build a new server and this is the only obstacle that forcing me to use Proxmox or KVM in general instead of XCP-ng.