Troubleshooting GPU passthrough ESXi 6.5

das1996

Member
Sep 4, 2018
41
3
8
No bueno.

I tried this variation before. Tried again.

The 1660 ti is a newer card, possible nvidia changed something. Or a combination of changes in esxi and the driver/card. I've been at this for the last few days and have tried all sorts of combinations in the passthru.map and vmx file. It all works great with this card in 6.5 (any update), but fails miserably in 6.7 and above.

I have a 1050 ti in my main box. Tempted to try it just to have a clear conscious that it's the card/driver/esxi than me doing something wrong.
 

das1996

Member
Sep 4, 2018
41
3
8
"Set nvidia gpu as primary"

Elaborate please.

Svga.present= false is in the vmx file to get rid of it entirely.
 

hmw

Active Member
Apr 29, 2019
319
97
28
"Set nvidia gpu as primary"

Elaborate please.

Svga.present= false is in the vmx file to get rid of it entirely.
Display 1 is the VMware SVGA display. I simply say 'Show on Display 2' which is the NVidia display

1602999423156.png 1602999438028.png 1602999536172.png
 

das1996

Member
Sep 4, 2018
41
3
8
I kind of figured as much after thinking about your comment. The svga.present = false gets rid of the vmware adapter/display entirely. The vm only sees a single gpu.

I think much of this is coming back to some kind of reset issue. The gpu is seen after a host reboot each and every time. It's only when the guest is rebooted that the error 43 crops up.

It's too late to pull the 1050 out but I'm tempted to give it a try tomorrow. Fortunately the test box is not even in a box... just a board on a stand of sorts. Very accessible. That would really be something if it works with it!
 

das1996

Member
Sep 4, 2018
41
3
8
See the second post here - HomeLab with Vmware ESXI and GPU passtrough |VMware Communities

He points out the unfavorable gpu state on guest shutdown.

I found a program by nirsoft - How to disable, enable, and uninstall a device from command-line on Windows, that allows device enable/disable via command line.

Using simple batch files for startup/shutdown (respectfully);

devmanview.exe /enable "NVIDIA GeForce GTX 1080 Ti"
devmanview.exe /disable "NVIDIA GeForce GTX 1080 Ti"

Allows the gpu to automatically be placed in a state which allows it to work after a guest reboot.

I added the appropriate command above to a startup.bat and shutdown.bat which is referenced in the group policy startup/shutdown policy.

1603004820657.png

So far this seems to work. It's not the most eloquent way. Also of concern is what effect this may have on OS/gpu stability in the long term. I usually go months between rebooting the hosts. On the production box, the win10 (htpc) is usually put to sleep after watching tv and restarted by WOL. I find after about 20-30 days I need to do an actual windows restart as it starts to get laggy.
 
  • Like
Reactions: klimvoroshilov13

das1996

Member
Sep 4, 2018
41
3
8
Wanted to provide an update after testing with a 1050 ti.

Swapped in the 1050 ti and disabled the startup/shutdown scripts (no disabling of gpu in device mgr at shutdown). Updated passthru.map with pid/vid of new card's gpu (d3d0 false).

Restarted as well as shutdown/restart a number of times. Gpu came back each time without any error 43's. IOW everything worked the way it should have.


So.. Take away... 16xx cards (and newer?) require the gpu disable/enable at shutdown/restart, otherwise error 43.

Same driver, same windows, same vmx settings, only change was the video card. Clearly something changed in the cards and/or the way the drivers interact with the newer cards.


I hope this helps the next person save some time and lots of hair pulling in getting this to work.
 

hmw

Active Member
Apr 29, 2019
319
97
28
So.. Take away... 16xx cards (and newer?) require the gpu disable/enable at shutdown/restart, otherwise error 43.
Which would mean the default reset method that works for the GPU (FLR) isn't working anymore

Reset Method
Possible values for the reset method include flr, d3d0, link, bridge, or default. The default setting is described as follows. If a device supports function level reset (FLR), ESX always uses FLR. If the device does not support FLR, ESX next defaults to link reset and bus reset in that order. Link reset and bus reset might prevent some devices from being assigned to different virtual machines, or from being assigned between the VMkernel and virtual machines. In the absence of FLR, it is possible to use PCI Power Management capabili
Perhaps you can try putting the GPU itself in the passthru map and experiment with D3D0 and other methods
 

das1996

Member
Sep 4, 2018
41
3
8
^^I've tried every possible variation with the 1660 ti. It didn't matter, d3d0, flr, link, bridge, etc on the GPU PID, or any other pid associated with the card.

I've spent MANY hours over a few days messing with this. I think we're on the right track about it being a reset issue. Something changed after 6.5.0.

Unrelated, but discovered my browsers (FF, opera, chrome) weren't doing hardware decoding of videos (inc 4k/8k). Turned out I was missing some filters.

Post #2, specifically vp9 and av1. Maybe the decrapifier script removed them when I set this box up a year ago... Never paid much attention as this cpu is quite powerful (3900x). But noticed no decode activity when playing any vids in task manager.

For now, the 1050 ti will go into the htpc. I'm taking the 1660 ti for myself. In a few years maybe some of the hw decoding abilities of the 1660 will be needed so i'll swap. In any event gt 710---> 1050 ti is a vast improvement.
 
Last edited:

Railgun

New Member
Jul 28, 2018
9
1
3
Hi @das1996. Firstly, thanks for your efforts on this (and everyone for that matter). I too have started to experience issues in this regard with my 1660Ti, though in my case, it seems a host reboot no longer gets the card in a working state. I'd not done any of the above previously and am working on that as I type, though that being the case, I'm trying to determine the cause as to why a host reboot does not work. I'm running 6.7 build 15160138. It's probable that this was the build that caused the issue as prior to the update (still on 6.7, don't recall specifically which version) a host reboot seemed to work.

I'll try to get everything in place.

Incidentally, adding the script to the policy causes a hang on reboot/shutdown of the guest. I suppose it's easy enough to simply do manually should I need to and it's not as though it reboots often.

As I'm not an ESXi guru by any stretch, I'll be digging deeper than I probably should be just to make sure I know where everything is and should be.
 

Serj_82

New Member
Aug 11, 2020
9
0
1
Hello everyone... I am very tired and very angry ...
I have already tried everything I can, but I still can't make a pass-through transmission of the GTX 690. Error 43 ...
I try all the parameters:
hypervisor.cpuid.v0 = FALSE
pciPassthru0.msiEnabled = FALSE
SMBIOS.reflectHost = TRUE
pciPassthru.use64bitMMIO - TRUE
Did not help...

I downgrade virtualHW.version in win10.vmx to 8 (displayed as ESXi 5) version from 13th - Edit Settings stopped working.
On version 10 (displayed as ESXi 5.5) - it worked.

I constantly put 461 drivers. Does not work.

Sometimes it is possible to run the updated drivers on the video card, but as a result, the DRIVER IRQL NOT LESS OR EQUAL error persists in nvlddmkm.sys

Two video card processors and an HDMI audio controller in the PCI Devices list correspond to the values: 0000: 05: 00.01 and 04: 00.01 - an audio controller, and GTX 690 - 0000: 05.00.0 and 04: 00.0

Compare values via lspci -n command
The values 04: 00.0 and 05: 00.0 are 10de: 1188 The values 04: 00.1 and 05: 00.1 are 10de: 0e0a

In the etc / vmware / passthru.map file, on line 10de ffff bridge false, the brige value was like d3d0, doesn't work.

I change to bridge, rebooted the hypervisor, it didn't help.
I change to link, it did not help.

An option with a detailed schedule of settings: commented out the line 10de ffff link false in passthru.map, then wrote 10de 0e0a d3d0 false - that is, only for the audio device.
0e0a is the audio unit value. Did not help.

Changed the Svga.present value to false - disables the ability to log into the virtual machine altogether!

What ELSE can be done? Please....

Do I need a dummy monitor plug on the graphics card?
 

das1996

Member
Sep 4, 2018
41
3
8
^^I had to revert to adding a group policy to enable the gpu at boot, and disable at shut down (gtx 1050ti). For a while it worked without this, but at some point (after a windows update?), it stopped and doing the above was the only thing that kept it working between reboots.

Note, you will need to restart esxi for the above to work. If windows is shutdown without disabling the gpu first, then restarted, you will get error 43 and will continue to get it on subsequent windows reboots.
 

Serj_82

New Member
Aug 11, 2020
9
0
1
^^I had to revert to adding a group policy to enable the gpu at boot, and disable at shut down (gtx 1050ti). For a while it worked without this, but at some point (after a windows update?), it stopped and doing the above was the only thing that kept it working between reboots.

Note, you will need to restart esxi for the above to work. If windows is shutdown without disabling the gpu first, then restarted, you will get error 43 and will continue to get it on subsequent windows reboots.
Please tell me what exactly should be turned off?
In my guest OS, in the task manager, three icons are visible:
NVidia GForce GTX 690 (2 pcs) and VMWare SVGA 3D. Need to turn off the SVGA?
What are the next steps with the guest OS and the hypervisor?
 

das1996

Member
Sep 4, 2018
41
3
8
My advice. READ THIS THREAD in its entirety.... Several times even, to help better understand how all this works. The settings below work for me and survives guest OS reboots. The only caveat is post #245. Without it, I get pass through on initial esxi reboot, but on subsequent guest reboots, error 43 returns. When I had the gtx710 video card, only the passthru parameter was needed. No monkeying around with disabling/enabling the gpu on shutdown/reboots, respectively.

Also, I don't shut windows down at then end of a session. Instead, it gets put to sleep (sleep button on wireless keyboard). I use WOL to wake. Either by shortcut/app on cell phone, program on my computer, or a web url - Domain.com:{port}/path/win10-htpc.php . This calls a php script which runs a shell script and fires ether-wake for the respective mac address. For now I wouldn't worry about this. Get your error 43 issues resolved.

Once you disable the vm display ( Svga.present =false), connection to guest is only possible by remote desktop or vnc. The latter is preferred. It keeps windows in the same operating mode as if the display was still there (sort of). Remote desktop changes the environment and certain things may not work right.

passthru.map - you'll need to adjust the first two sets to match your video card's vga id (not hd audio)

#1050 ti
10de 1c82 d3d0 false

For the vm's, you will need all the other settings as mentioned throughout this thread. I'll see if I can attach a cleansed vmx of my win10 file.

vmx
1611254851069.png

esxi
1611254895547.png

See attached zip for cleansed vmx file. Entries containing xxxxxxxxx's have been cleansed.
 

Attachments

Last edited:

Serj_82

New Member
Aug 11, 2020
9
0
1
My advice. READ THIS THREAD in its entirety.... Several times even, to help better understand how all this works. The settings below work for me and survives guest OS reboots. The only caveat is post #245. Without it, I get pass through on initial esxi reboot, but on subsequent guest reboots, error 43 returns. When I had the gtx710 video card, only the passthru parameter was needed. No monkeying around with disabling/enabling the gpu on shutdown/reboots, respectively.

Also, I don't shut windows down at then end of a session. Instead, it gets put to sleep (sleep button on wireless keyboard). I use WOL to wake. Either by shortcut/app on cell phone, program on my computer, or a web url - Domain.com:{port}/path/win10-htpc.php . This calls a php script which runs a shell script and fires ether-wake for the respective mac address. For now I wouldn't worry about this. Get your error 43 issues resolved.

Once you disable the vm display ( Svga.present =false), connection to guest is only possible by remote desktop or vnc. The latter is preferred. It keeps windows in the same operating mode as if the display was still there (sort of). Remote desktop changes the environment and certain things may not work right.

passthru.map - you'll need to adjust the first two sets to match your video card's vga id (not hd audio)

#1050 ti
10de 1c82 d3d0 false

For the vm's, you will need all the other settings as mentioned throughout this thread. I'll see if I can attach a cleansed vmx of my win10 file.

vmx
View attachment 17246

esxi
View attachment 17247

See attached zip for cleansed vmx file. Entries containing xxxxxxxxx's have been cleansed.
Well, in general, something began that I did not expect ...
This was before, but I managed to get the host off the power.
Now it has started quite suddenly!
The video card has disappeared from the list of PСI devices and does not want to appear! I've already turned it on and off ten times, rebooted the host (although I will say it again, recently the video card did NOT disappear even after a reboot)!
This is VERY tired, please tell me, вo you know the official position of VMWare?
 
Last edited:

Iamfreaky

New Member
Mar 25, 2021
3
0
1
Sorry, but after following the Complete Post and trying everything for myself, I still don't get it to work. Still got the Code 43.

I changed the Passbrough.map on ESXi (6.7.0 and 6.5.0) for the Gpu + Audio to d3d0 false

Added
hypervisor.cpuid.v0 = "FALSE"
svga.present = "FALSE"
pciPassthru.use64bitMMIO = "TRUE"
pciPassthru1.msiEnabled = "FALSE"
pciPassthru0.msiEnabled = "FALSE"

to vmx File.
i Also tried Hardware virtualization ( This only works in 6.5.0 but not in 6.7.0)


Still it does not work. Any Ideas ?
 

AveryFreeman

consummate homelabber
Mar 17, 2017
254
23
18
40
Near Seattle
averyfreeman.com
Sorry, but after following the Complete Post and trying everything for myself, I still don't get it to work. Still got the Code 43.

I changed the Passbrough.map on ESXi (6.7.0 and 6.5.0) for the Gpu + Audio to d3d0 false

Added
hypervisor.cpuid.v0 = "FALSE"
svga.present = "FALSE"
pciPassthru.use64bitMMIO = "TRUE"
pciPassthru1.msiEnabled = "FALSE"
pciPassthru0.msiEnabled = "FALSE"

to vmx File.
i Also tried Hardware virtualization ( This only works in 6.5.0 but not in 6.7.0)


Still it does not work. Any Ideas ?
I always had to have svga=true, otherwise I wouldn't get any video at all, so if you got svga=false to work, you're on a different path than I was able to get working

hypervisor.cpuid.v0 = false was the key to fixing this in my instance with an nvidia GPU (quadro p400). I've heard GeForces are much more difficult due to their being segmented as a consumer-only product.

If you already installed the drivers in Windows before setting hypervisor.cpuid.v0=false, try setting svga=true so you can use the virtual interface again, and clean uninstall nvidia drivers using iobit uninstaller, etc. so you clear all the traces of nvidia's programs/drivers, then set it back to svga=false once you get it working (or just disable the Vmware vGPU driver in windows driver settings like I had to, since I couldn't set svga=false).

This is because once the virtualization detection "trips" the nvidia drivers into "knowing" the system is virtualized, it's impossible (or at least extremely difficult) to get it to go back to making it think it's not being virtualized (it's hit a "trip wire")

I don't see any info from you about what kind of hardware you're working with, but if you have a cheaper server or consumer board, you probably want to disable ACS check in ESXi system -> advanced configuration

You can keep trying different combinations in the passthrough map after trying that stuff and see if it helps, or look for some windows patches that address error 43. I know there's some other solutions out there.

And always, keep in mind, it's hard to get it to work, don't be hard on yourself. I had a perfectly good working "desktop" system before moving to 7.0 and nothing I could do after upgrading would make it work. It's not a very stable setup to depend on, if you really need it, plan to never upgrade and always keep the same hardware + hypervisor config. I finally just gave up and started using my laptop for all my "real" computer stuff.
 
Last edited:

Iamfreaky

New Member
Mar 25, 2021
3
0
1
@AveryFreeman I did hypervisor.cpuid.v0=false before even installing the GPU in the VM. I Started the System with it, and shut it down right after it. After that I installed the PCI Device and added pciPassthru.use64bitMMIO = "TRUE", pciPassthru1.msiEnabled = "FALSE" and pciPassthru0.msiEnabled = "FALSE"

Then I started the VM again and Installed the Device Drivers. If I Keep the SVGA then I will only get Bluescreens at the windows Start. I deinstalled the Nvidia Drivers now, reinstalled them, then they work for this short period (No code 43) but after one reboot Code 43 appears again.

I even tried the ACS Check , but that also didn't help. I am on the Newest Windows Version.