I’d try killing both hidden=1 and kvm=off.
Later today, I’ll throw a secondary GPU into my proxmox machine so I can test passing through an nvidia device.
1 Like
I’ll try that.
Dude, thanks for being so helpful. 
Edit:
Nope. Tried with just CPU as host, and it still gives issues. Tried with just host,hidden=1, and it still gives issues. Same for host,kvm=off and as you know host,kvm=off,hidden=1.
1 Like
You also have to set the vendor and time flags.
host,hv_time,kvm=off,hv_vendor_id=null
2 Likes
This is a work thing, and I will be in the office on Monday. Thanks 
.
1 Like
So I set it to the following conf file:
bios: ovmf
bootdisk: virtio0
cpu: host,hv_time,kvm=off,hv_vendor_id=null cores: 4
efidisk0: local-lvm:vm-100-disk-2,size=128K
hostpci0: 02:00,x-vga=on,pcie=1
machine: q35
memory: 7168
name: Test-Windows
net0: virtio=96:24:CF:B4:AA:A2,bridge=vmbr0 numa: 0
ostype: win10
scsihw: virtio-scsi-pci
smbios1: uuid=f675c872-c390-4668-9c48-423f5b4ff239
sockets: 1
usb0: host=6-1.2
usb1: host=2-4
usb2: host=3-1.2.3.4
usb3: host=1-1.2.3.4
virtio0: local-lvm:vm-100-disk-1,cache=writeback,size=90G
Still getting the same issue:
The Nvidia drivers are installed:
OVMF shouldn’t need the x-vga=on, try disabling that.
Also, strange question, but does your GPU show up in an “eject / remove devices” tray icon? If that’s the case, it’s an indicator that not all the required virtual PCI devices are there.
1 Like
Removing that resulted in this:
Odd thing: Now the Basic Display Adapter is giving Code 43 as well. 
I imagine the audio is the HDMI audio portion of the GPU.
I’ve seen this happen to a friend after installing new Nvidia drivers.
Edit:
Reading here
I see the XML config file has the following settings:
<features>
<hyperv>
...
<vendor_id state='on' value='whatever'/>
...
</hyperv>
...
<kvm>
<hidden state='on'/>
</kvm>
</features>
So now to try it with hidden=1.
Adding hidden=1 did not work. People in that thread you posted sgtawesomesauce were using x-vga=1 so I added that back.
Now the GPU isn’t showing up in my tray icon, and cannot be ejected. However, it is still giving the Code 43 error code.
Speaking of headless host and switching between guests, does anyone know if it’s possible to use Intel HD Graphics inside a guest OS by now? I think the feature is called KVMGT/XENGT respectively.
It was a long shot. At this point, I’m just slinging mud at the wall to see what sticks. I wasn’t able to get my nvidia GPU passed through with proxmox over the weekend, try as I might. 
Well, I should’ve been checking the logs when I was testing this. Double clicking the VM <id> - Start entry shows me this:
vm 100 - unable to parse value of 'cpu' - format error
hv_vendor_id: property is not defined in schema and the schema does not allow additional properties
So clearly I’m not formatting the conf file right. It hasn’t been using all the settings I’ve put on the CPU: line. All that time wasted sigh.
x-vga=1 forces hv_vendor_id=proxmox and I feel like that’s not good?
cpu: host requires kvm being set to on. 
I’m not sure what set of options work correctly.
I need hv_vendor_id=null and kvm=off presumably to hide the fact I’m using a hypervisor. But I can’t since both of those have requirements that others say I also need.
Odd.
@Vitalius
I am not fully aware what hardware you are using but is the Nvidia GPU the only one in your setup (iGPU also included)?
This post which has been posted above is saying that using the GRUB boot parameter "video=efifb:off" as well as loading your own VBIOS on guest startup can do the trick, especially if you are passing through your main (only) GPU. You may need to trim your VBIOS dump as shown in this video.
I can’t tell if this eliminates “Error 43” as well as I have not tried a passthrough on Proxmox, yet. Hope I could provide anything useful to you. Good luck!
1 Like
So, this motherboard has one PCI-e x16 slot, once PCI-e x1 slot, and one PCI slot. Unless I got a 1x to 16x riser, I couldn’t really follow that method for loading the VBIOS.
I’ll try the "video=efifb:off" trick next.
Edit:
Adding that did not fix the issue. I may have to try a 1x to 16x riser to see if I can get a copy of the VBIOS directly.
This is becoming more of an annoyance than I had hoped. Being “plug n play” was ideal and this is definitely not that. sigh
Yeah. I think the best solution would be to get a 460 or 550 or something like that, from Team Red. It’s going to work much better.
I know this is a work situation, so you may not be able to do this.
1 Like
Dumb question, do you still have the basic graphics adapters connected to the system? EG the spice vnc thing that KVM uses for the console function in proxmox.
Depends. If I’m using x-vga=on, or kvm=off, it is not there. If I remove those options, it is there.
I don’t adjust this in the GUI because it lacks options for those two things.
Apparently, x-vga does ‘magical things’ in the background.
From my testing if you still have the spice/VNC/whatever console graphics in the VM then the Nvidia driver will not work.
1 Like
That must be a problem on Proxmox’ side then. At least i can’t remember having this issue on Arch + libvirt. In my early testing phase I did run both Nvidia and SPICE side-by-side without a problem. I just happened to have an extended 2nd screen in 800x600 resolution.
Getting rid of it was not a problem either but then again, it could be that Proxmox behaves differently. Would be a quite a bummer though.
Are you saying that you did never actually succeed in passing the hv_vendor_id attribute, because of config file parsing? So the problem is that you don’t get it through, not that it is passed but fails doing its job?
I don’t know proxmox, but can you use a tool like ps in a terminal to get the qemu command line from the running process? That would be a way to verify what is actually passed to qemu. You should also be able to copy this command line and run an edited version of it, as a way of checking that the desired command line work as expected.
Not a problem on Ubuntu either, I am running the same combo right now.