I’ve raised this at the vmWare NVIDIA community forums also
We’re deploying a vSphere 6/Horizon 6.2.0 solution using HP Gen9 Servers fitted with GRID K1 cards.
We’re experiencing an issue where the NVIDIA adapter is not always identified, i.e. the VDI falls back to the standard VMware VGA adapter instead.
The behaviour is strange but consistent:
Connect to View Server > Login > VDI uses VMware SVGA
Log Off > Login > VDI uses VMware SVGA
But…
Connect to View Server > Login > VDI uses VMware SVGA
Disconnect > Login > VDI uses NVIDIA k120q
Disconnect > Login > VDI uses NVIDIA k120q
Log Off > Login > VDI uses VMware SVGA
So… summarily, any login pursuant to either a reboot or log off, and the VDI uses the VMware SVGA adapter; whereas any login pursuant to a disconnect uses the NVIDIA.
Guest OS is Win 7 Professional x64
As things stand we would be asking end users to login, disconnect, then re-connect in order to make use of the NVIDIA adapter. Not a good look.
Thanks in advance for any input or ideas.
UPDATE
Having scanned through the Process Tree in ProcMon, and done another review of the Event log, I am at this point entirely bereft of ideas as to how to troubleshoot and resolve this.
Does anybody have any clues? I’ll settle for the smallest grain of hope at this point.
Also, does anyone know where we go for support on a case like this? Is it to NVIDIA or to VMware?
For reference, further details on the problem are here:
Support calls for the K1 are not provided by NVIDIA, you need to raise an issue via the OEM/whoever you purchased the cards via e.g. server vendor DEll/Cisco etc and they can raise a case. This is the disadvantage of selling GPUs as "hardware" and in our newer M60/M60/M10 we have moved to a license model to provide direct support.
We will continue to do best will with K1/K2 customers but really your support contract is with the OEM who provided the card and you have to raise an issue with them.
I actually think your best call is to VMware as this sounds like a configuration issue as we have lots of customers wusing the same server and cards without issue. The new licensing model has funded an increase in support material for all custoemrs and you might want to search our knowledge base Find Answers | NVIDIA and use resources like the configuration guide video: Error | NVIDIA
As the problem is associated with the disconnect/login workflow it’s really likely to be either Microsoft (it’s the OS that picks the driver) and/or VMware stack (as that can influence and trigger the OS picking the driver).
The GPU is a resource below that and as such it’s generally not us dictating whether our driver is picked up.
Thanks for this Rachel.
Is anyone at your end able to offer any clarification around the K1 vGPU driver package that appears in the "old drivers" section of the NVIDIA web site with a release date of 2nd June 2016?
The release date of this driver appears to be later than the release date of the "current" driver; but the version numbers are lower.
thanks
The latest “maintainance” driver is 354.97 June 2, 2016. That’s the GRID 2.3 driver, i.e. a maintenance release on the GRID 2.x R352 driver branch. Date is later because it was indeed released after 3.1.
So these are two different drivers off different build trees. Where the maintainance one takes fixes and the newer branch also takes new functionality.
I can’t rule out a faint possibility that there is something in the way the driver presents itself that could prevent it being picked up but it’s very unlikely as we would have heard a lot more about it I’d have thought and technically it’s just the driver sitting there.
As the login workflow triggers a chance my best guess it is in the VMware code that works around the underlying fault in win 7 which randomly picks up the wrong driver. I would ask VMware if disabling the vSGA driver is appropriate.
I typically do this on all my VMs with a GPU, regardless of Operating System. Custom install of VM Tools and do not install the display driver, then once the NVIDIA driver is installed, I have no use for the basic display adapter, so disable it. That way, I am only presenting 1 choice to the Operating System. We use XenApp / XenDesktop for our platforms, so unsure if VMware places any requirements on having the base adapter available.
I’ve not experienced any issues (performance or other) by doing this so far.
I’m not sure this is the answer you’re looking for, but I hope it helps in some way.
Thanks for this. I’m imagining that if we could start from scratch with a "clean" gold image, we might be experiencing a lot less pain all the way around. Unfortunately, we don’t readily have that option because we work exclusively with pools of persistent desktops. We are going to continue with the VMware support ticket effort for a few days longer, but if we don’t get a positive outcome and it becomes a choice between dumping NVIDIA and rebuilding all new desktops, we will dump NVIDIA. We really want the K1 to work, because it adds a real snappiness and sharpness to the user experience; but we can live without it. I’m not re-building all our desktops from scratch just to make it work.
Thanks anyway, for the additional advice. I do appreciate it.
I do suspect the underlying issue is the known Win7 issue, which thankfully Microsoft resolved in win 8.x and up. windows 7 is going away and migrations speeding up so hopefully this will long term be resolved :-/ Lifecycle FAQ - Windows | Microsoft Docs
I believe VMware workaround it by disabling the sVGA adapter so manually doing it should have no ill-effect (but you should check with VMware), the one effect it has under XenDesktop is to lower the console performance but I have a vague idea VMware doesn’t have that problem.
Really though I think the people with the code that controls this are VMware and that’s where the support issue is most likely to be resolved… if you have a ticket reference I can ping VMware support and ask them if they need assistance. What have you actually been told by VMware support?
Thanks for that. The VMware support case reference is #16195560707. If you think you may be able to somehow assist them, that would be great.
As yet we have not been told anything conclusive by VMware. They have analysed our PCoIP logs and determined that, "in the initial session the driver was not loaded to be detected by the PCOIP session. But when you re-launch the session the drivers were detected"
The actions we have taken under the support case under their guidance are listed here, point 23 onward:
We have also received an initial response from NVidia following our Bug submission but that is in the very early stages. The last email notification I received stated that it was going to "Level 2".
Although I’m keeping an open mind, I’d be more convinced that this was a Microsoft issue were we not getting the display adapter to work at all. The fact that it seems to work flawlessly on a reconnect but not on a login is what makes me lean more toward this being a VMware/NVidia problem rather than a ‘Windows’ problem. But yea… always keeping an open mind.
Any assistance anyone at your end can offer will be gratefully acknowledged by us. It may be that events will overtake this issue going in to next week, but I would ideally like to get it resolved.
Hi Rachel,
FYI, this no longer carries any urgency. The VMware ticket is now being escalated to engineering and given the potential timescales involved, I have decided to drop GRID for our current deployment. I will consider rolling GRID out for our users as and when there is demand for ‘new’ desktops only.
I will keep the VMware ticket running and if any solution is ultimately forthcoming I will update this thread accordingly.
Writing this off as a bad experience and lesson learnt.
Thanks for your assistance, I appreciate it.
Robert