PVE guest mit Nvidia 3070 will nicht

[pmdk]

Moin,
ich hab schon einige Threads hier und außerhalb gelesen, die Anleitungen usw..

Der Host (PC83) läuft soweit. Auch ein ubuntu22-guest läuft mit Standard-Treibern. Sobald ich das PCI-Device 0000:65:00.0 auswähle, bootet der guest nicht mehr.

Folgende Infos hab ich:
root@pc83:~# lspci |grep -i nvidia
0000:65:00.0 VGA compatible controller: NVIDIA Corporation Device 2488 (rev a1)
0000:65:00.1 Audio device: NVIDIA Corporation GA104 High Definition Audio Controller (rev a1)
root@pc83:~# nvidia-detect
Detected NVIDIA GPUs:
0000:65:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2488] (rev a1)

Checking card: 00.0 VGA compatible controller
Uh oh. Your card is not supported by any driver version up to 530.30.02.
A newer driver may add support for your card.
Newer driver releases may be available in backports, unstable or experimental.

## Was wollen die mir damit sagen? Ne 3070 ist doch jetzt nicht soo neu.

root@pc83:~# journalctl --since '2023-05-24'
...
May 25 13:02:36 pc83 QEMU[1554]: kvm: vfio_region_write(0000:65:00.0:region1+0x160de18, 0xff000000ff000000,8) failed: Device or resource busy
May 25 13:02:36 pc83 kernel: vfio-pci 0000:65:00.0: BAR 1: can't reserve [mem 0xc0000000-0xcfffffff 64bit pref]
...
May 25 13:02:36 pc83 systemd-journald[498]: Missed 8 kernel messages
May 25 13:02:36 pc83 kernel: vfio-pci 0000:65:00.0: BAR 1: can't reserve [mem 0xc0000000-0xcfffffff 64bit pref]

Ich hab das 3.1G große cuda-repo-debian11-12-1-local_12.1.1-530.30.02-1_amd64.deb installiert, kann damit aber nix anfangen:
root@pc83:~# dpkg -l |grep -i cuda
ii cuda 12.1.1-1 amd64 CUDA meta-package
ii cuda-12-1 12.1.1-1 amd64 CUDA 12.1 meta-package
ii cuda
...

Hat irgend ein Mensch ne Nvidia 3070 mit aktuellem Proxmox und nem Linux-Guest am Laufen?
Mein Vergleichswunsch: PiTiVi - mp4 rendern in MOV. Das kann bei nem 2G.mp4 2 Minuten oder >1Std. dauern.

LG, D.

 

[dcsapak]

Hi,

Sobald ich das PCI-Device 0000:65:00.0 auswähle, bootet der guest nicht mehr.

was genau heißt das? hängt der gast, bricht das starten ab, etc.?

hast du am host den treiber geladen? wenn ja kann das zu problemen führen sie auch (siehe https://pve.proxmox.com/wiki/PCI(e)_Passthrough#_host_device_passthrough wie man den treiber blacklisten kann)

kannst du auch den ganzen output von 'dmesg' posten?

 

[mr44er]

Kann das sein, dass das derzeit kaputte udev auch Auswirkungen auf vga hat?

https://forum.proxmox.com/threads/u...ert-seit-update-nicht-mehr.127901/post-559366

 

[pmdk]

was genau heißt das? hängt der gast, bricht das starten ab, etc.?

Der proxmox-Schirm kommt, und dann 1-3 Zeilen Text, eher unterschiedlich.
Jetzt gerade eben was von "nouveau" und der syslog läuft voll mit
May 25 19:20:24 pc83 QEMU[68855]: kvm: vfio_region_write(0000:65:00.0:region1+0x5c8988, 0x0,8) failed: Device or resource busy
May 25 19:20:24 pc83 QEMU[68855]: kvm: vfio_region_write(0000:65:00.0:region1+0x5c8990, 0x0,8) failed: Device or resource busy
bis ich die Maschine stoppe.

hast du am host den treiber geladen? wenn ja kann das zu problemen führen sie auch (siehe https://pve.proxmox.com/wiki/PCI(e)_Passthrough#_host_device_passthrough wie man den treiber blacklisten kann)

Das mit dem blacklisten ist sehr komisch; was für ein Durcheinander:
root@pc83:/etc/modprobe.d# more pve-blacklist.conf
# This file contains a list of modules which are not supported by Proxmox VE
# nidiafb see bugreport https://bugzilla.proxmox.com/show_bug.cgi?id=701
blacklist nvidiafb
## Das liest sich wie "nvidiafb" wird von PVE nicht supported.

root@pc83:/etc/modprobe.d# grep vfio *
root@pc83:/etc/modprobe.d# grep blacklist *
nvidia-blacklists-nouveau.conf:blacklist nouveau
nvidia-installer-disable-nouveau.conf:blacklist nouveau
pve-blacklist.conf:blacklist nvidiafb
## Irgendwie sind wohl alle geblockt.

root@pc83:/etc/modprobe.d# tll
total 16
lrwxrwxrwx 1 root root 53 May 25 12:13 nvidia-blacklists-nouveau.conf -> /etc/alternatives/glx--nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root 43 May 25 12:13 nvidia.conf -> /etc/alternatives/glx--nvidia-modprobe.conf
-rw-r--r-- 1 root root 76 May 21 13:41 nvidia-installer-disable-nouveau.conf
-rw-r--r-- 1 root root 171 Nov 16 2021 pve-blacklist.conf
-rw-r--r-- 1 root root 127 Feb 12 2021 dkms.conf
-rw-r--r-- 1 root root 260 Jan 7 2021 nvidia-kernel-common.conf
root@pc83:/etc/modprobe.d#

## Ich gebe zu, mir sind die Zusammenhänge nicht klar.

kannst du auch den ganzen output von 'dmesg' posten?

2741 Zeilen?

LG, D.

 

[pmdk]

Kann das sein, dass das derzeit kaputte udev auch Auswirkungen auf vga hat?

https://forum.proxmox.com/threads/u...ert-seit-update-nicht-mehr.127901/post-559366

Keine Ahnung. Ich kann auch noch paar Tage warten, ob sich was ändert.

 

[pmdk]

Oh, der zählt irgendwelche Speicherbereiche hoch und flutet damit den syslog.
Diesmal kam nach proxmox und Ubuntu-Kernelauswahlscreen folgender Srnsht zustande.
.....
May 25 21:01:24 pc83 QEMU[85443]: kvm: vfio_region_write(0000:65:00.0:region1+0x440320, 0x0,8) failed: Device or resource busy
May 25 21:01:24 pc83 QEMU[85443]: kvm: vfio_region_write(0000:65:00.0:region1+0x440328, 0x0,8) failed: Device or resource busy
May 25 21:01:24 pc83 QEMU[85443]: kvm: vfio_region_write(0000:65:00.0:region1+0x440330, 0x0,8) failed: Device or resource busy
May 25 21:01:24 pc83 QEMU[85443]: kvm: vfio_region_write(0000:65:00.0:region1+0x440338, 0x0,8) failed: Device or resource busy
May 25 21:01:24 pc83 QEMU[85443]: kvm: vfio_region_write(0000:65:00.0:region1+0x440340, 0x0,8) failed: Device or resource busy
May 25 21:01:24 pc83 QEMU[85443]: kvm: vfio_region_write(0000:65:00.0:region1+0x440348, 0x0,8) failed: Device or resource busy
May 25 21:01:24 pc83 QEMU[85443]: kvm: vfio_region_write(0000:65:00.0:region1+0x440350, 0x0,8) failed: Device or resource busy

 

[dcsapak]

Das mit dem blacklisten ist sehr komisch; was für ein Durcheinander:
root@pc83:/etc/modprobe.d# more pve-blacklist.conf
# This file contains a list of modules which are not supported by Proxmox VE
# nidiafb see bugreport https://bugzilla.proxmox.com/show_bug.cgi?id=701
blacklist nvidiafb
## Das liest sich wie "nvidiafb" wird von PVE nicht supported.

root@pc83:/etc/modprobe.d# grep vfio *
root@pc83:/etc/modprobe.d# grep blacklist *
nvidia-blacklists-nouveau.conf:blacklist nouveau
nvidia-installer-disable-nouveau.conf:blacklist nouveau
pve-blacklist.conf:blacklist nvidiafb
## Irgendwie sind wohl alle geblockt.

root@pc83:/etc/modprobe.d# tll
total 16
lrwxrwxrwx 1 root root 53 May 25 12:13 nvidia-blacklists-nouveau.conf -> /etc/alternatives/glx--nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root 43 May 25 12:13 nvidia.conf -> /etc/alternatives/glx--nvidia-modprobe.conf
-rw-r--r-- 1 root root 76 May 21 13:41 nvidia-installer-disable-nouveau.conf
-rw-r--r-- 1 root root 171 Nov 16 2021 pve-blacklist.conf
-rw-r--r-- 1 root root 127 Feb 12 2021 dkms.conf
-rw-r--r-- 1 root root 260 Jan 7 2021 nvidia-kernel-common.conf
root@pc83:/etc/modprobe.d#

## Ich gebe zu, mir sind die Zusammenhänge nicht klar.

es sieht für mich so aus als hättest du am host den nvidia treiber installiert. wenn du aber die vm durchreichen willst solltest du genau das nicht tun, also solltest du entweder den nvidia treiber wieder deinstallieren am host oder das 'nvidia' modul blacklisten

2741 Zeilen?

LG, D.

ja bitte (kann man auch als text datei anhängen hier)

und wenn möglich bitte auch den output von 'lspci -nnk' (dort sieht man beim device welcher treiber geladen ist)
auch die vm config wär ganz interessant (qm config ID)

 

[pmdk]

es sieht für mich so aus als hättest du am host den nvidia treiber installiert. wenn du aber die vm durchreichen willst solltest du genau das nicht tun, also solltest du entweder den nvidia treiber wieder deinstallieren am host oder das 'nvidia' modul blacklisten

Mist. Ist ne lange Liste. Welche muss ich wohl deinstallieren, wenn ich mit ./NVIDIA-Linux-x86_64-510.47.03.run installiert habe?

root@pc83:~# dpkg -l|grep -i nvidia
ii cuda-nsight-compute-12-1 12.1.1-1 amd64 NVIDIA Nsight Compute
ii cuda-nsight-systems-12-1 12.1.1-1 amd64 NVIDIA Nsight Systems
ii cuda-nvtx-12-1 12.1.105-1 amd64 NVIDIA Tools Extension
ii glx-alternative-nvidia 1.2.1~deb11u1 amd64 allows the selection of NVIDIA as GLX provider
ii libcuda1:amd64 530.30.02-1 amd64 NVIDIA CUDA Driver Library
ii libegl-nvidia0:amd64 530.30.02-1 amd64 NVIDIA binary EGL library
ii libgl1-nvidia-glvnd-glx:amd64 530.30.02-1 amd64 NVIDIA binary OpenGL/GLX library (GLVND variant)
ii libgles-nvidia1:amd64 530.30.02-1 amd64 NVIDIA binary OpenGL|ES 1.x library
ii libgles-nvidia2:amd64 530.30.02-1 amd64 NVIDIA binary OpenGL|ES 2.x library
ii libglx-nvidia0:amd64 530.30.02-1 amd64 NVIDIA binary GLX library
ii libnvcuvid1:amd64 530.30.02-1 amd64 NVIDIA CUDA Video Decoder runtime library
ii libnvidia-allocator1:amd64 530.30.02-1 amd64 NVIDIA allocator runtime library
ii libnvidia-cfg1:amd64 530.30.02-1 amd64 NVIDIA binary OpenGL/GLX configuration library
ii libnvidia-compiler:amd64 530.30.02-1 amd64 NVIDIA runtime compiler library
ii libnvidia-eglcore:amd64 530.30.02-1 amd64 NVIDIA binary EGL core libraries
ii libnvidia-encode1:amd64 530.30.02-1 amd64 NVENC Video Encoding runtime library
ii libnvidia-fbc1:amd64 530.30.02-1 amd64 NVIDIA OpenGL-based Framebuffer Capture runtime l
ibrary
ii libnvidia-glcore:amd64 530.30.02-1 amd64 NVIDIA binary OpenGL/GLX core libraries
ii libnvidia-glvkspirv:amd64 530.30.02-1 amd64 NVIDIA binary Vulkan Spir-V compiler library
ii libnvidia-ml1:amd64 530.30.02-1 amd64 NVIDIA Management Library (NVML) runtime library
ii libnvidia-nvvm4:amd64 530.30.02-1 amd64 NVIDIA NVVM
ii libnvidia-opticalflow1:amd64 530.30.02-1 amd64 NVIDIA Optical Flow runtime library
ii libnvidia-ptxjitcompiler1:amd64 530.30.02-1 amd64 NVIDIA PTX JIT Compiler
ii libnvidia-rtcore:amd64 530.30.02-1 amd64 NVIDIA binary Vulkan ray tracing (rtcore) library
ii libnvidia-wayland-client:amd64 530.30.02-1 amd64 NVIDIA client for wayland library
ii libnvoptix1:amd64 530.30.02-1 amd64 NVIDIA implementation of the OptiX ray tracing en
gine
ii nsight-compute-2023.1.1 2023.1.1.4-1 amd64 NVIDIA Nsight Compute
ii nvidia-alternative 530.30.02-1 amd64 allows the selection of NVIDIA as GLX provider
ii nvidia-cuda-mps 530.30.02-1 amd64 NVIDIA CUDA Multi Process Service (MPS)
ii nvidia-detect 530.30.02-1 amd64 NVIDIA GPU detection utility
ii nvidia-driver 530.30.02-1 amd64 NVIDIA metapackage
ii nvidia-driver-bin 530.30.02-1 amd64 NVIDIA driver support binaries
ii nvidia-driver-libs:amd64 530.30.02-1 amd64 NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries
)
ii nvidia-egl-common 530.30.02-1 amd64 NVIDIA binary EGL driver - common files
ii nvidia-egl-icd:amd64 530.30.02-1 amd64 NVIDIA EGL installable client driver (ICD)
ii nvidia-installer-cleanup 20151021+13 amd64 cleanup after driver installation with the nvidia
-installer
ii nvidia-kernel-common 20151021+13 amd64 NVIDIA binary kernel module support files
ii nvidia-kernel-dkms 530.30.02-1 amd64 NVIDIA binary kernel module DKMS source
ii nvidia-kernel-support 530.30.02-1 amd64 NVIDIA binary kernel module support files
ii nvidia-legacy-check 530.30.02-1 amd64 check for NVIDIA GPUs requiring a legacy driver
ii nvidia-libopencl1:amd64 530.30.02-1 amd64 NVIDIA OpenCL ICD Loader library
ii nvidia-modprobe 530.30.02-1 amd64 utility to load NVIDIA kernel modules and create
device nodes
ii nvidia-opencl-common 530.30.02-1 amd64 NVIDIA OpenCL driver - common files
ii nvidia-opencl-icd:amd64 530.30.02-1 amd64 NVIDIA OpenCL installable client driver (ICD)
ii nvidia-persistenced 530.30.02-1 amd64 daemon to maintain persistent software state in t
he NVIDIA driver
ii nvidia-settings 530.30.02-1 amd64 tool for configuring the NVIDIA graphics driver
ii nvidia-smi 530.30.02-1 amd64 NVIDIA System Management Interface
ii nvidia-support 20151021+13 amd64 NVIDIA binary graphics driver support files
ii nvidia-vdpau-driver:amd64 530.30.02-1 amd64 Video Decode and Presentation API for Unix - NVID
IA driver
ii nvidia-vulkan-common 530.30.02-1 amd64 NVIDIA Vulkan driver - common files
ii nvidia-vulkan-icd:amd64 530.30.02-1 amd64 NVIDIA Vulkan installable client driver (ICD)
ii nvidia-xconfig 530.30.02-1 amd64 deprecated X configuration tool for non-free NVID
IA drivers
ii xserver-xorg-video-nvidia 530.30.02-1 amd64 NVIDIA binary Xorg driver

ja bitte (kann man auch als text datei anhängen hier)

und wenn möglich bitte auch den output von 'lspci -nnk' (dort sieht man beim device welcher treiber geladen ist)
auch die vm config wär ganz interessant (qm config ID)

Platte war übergelaufen wg. exorbitanter syslogs/kern.log usw.. dmesg kommt gleich.

Schöne Pfingsten, D.

 

[pmdk]

So macht das dmesg mehr Sinn.

 

[pmdk]

So,
root@pc83:/etc/modprobe.d# ls -l
total 8
-rw-r--r-- 1 root root 127 Feb 12 2021 dkms.conf
-rw-r--r-- 1 root root 171 Nov 16 2021 pve-blacklist.conf

root@pc83:/etc/modprobe.d# cat pve-blacklist.conf
# This file contains a list of modules which are not supported by Proxmox VE

# nidiafb see bugreport https://bugzilla.proxmox.com/show_bug.cgi?id=701
blacklist nvidiafb

root@pc83:/etc/modprobe.d# nvidia-detect
Detected NVIDIA GPUs:
0000:65:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2488] (rev a1)

Checking card: 00.0 VGA compatible controller
Uh oh. Your card is not supported by any driver version up to 530.30.02.
A newer driver may add support for your card.
Newer driver releases may be available in backports, unstable or experimental.

root@pc83:/etc/modprobe.d# nvidia-modprobe
root@pc83:/etc/modprobe.d#

Also vermute ich mal, dass der nouveau-Treiber geladen ist.

root@pc83:/var/log# grep -i nou allmessages
May 28 14:46:23 pc83 kernel: [ 0.229946] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=12
May 28 14:46:24 pc83 /usr/libexec/gdm-x-session[1438]: (==) Matched nouveau as autoconfigured driver 0
May 28 14:46:24 pc83 /usr/libexec/gdm-x-session[1438]: (II) LoadModule: "nouveau"
May 28 14:46:24 pc83 /usr/libexec/gdm-x-session[1438]: (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
May 28 14:46:24 pc83 /usr/libexec/gdm-x-session[1438]: (II) Module nouveau: vendor="X.Org Foundation"
May 28 14:46:24 pc83 /usr/libexec/gdm-x-session[1438]: (II) NOUVEAU driver Date: Sat Jan 23 12:24:42 2021 -0500
May 28 14:46:24 pc83 /usr/libexec/gdm-x-session[1438]: (II) NOUVEAU driver for NVIDIA chipset families :
May 28 14:49:07 pc83 kernel: [ 0.229626] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=12


Start der VM: (jetzt müllt er das logfile nimmer voll)
(attached file)

Der Gast ist ein ubuntu22.04 ... erstmal Patches einspielen, inkl. neuem Kernel + reboot.

Wie finde ich raus, ob/wie der Gast die GPU nutzt?

 

[mr44er]

Wie finde ich raus, ob/wie der Gast die GPU nutzt?

Am einfachsten, wenn du da einen eingeschalteten Monitor anschließt. Das empfiehlt sich sowieso immer, da manche Karten sonst komisch reagieren. Später wenn dann alles sauber läuft, kann man austesten ob standby geht oder ganz ohne Monitor (ggf. noch Kaltstart der VM ohne Monitor testen).

 

[pmdk]

Am einfachsten, wenn du da einen eingeschalteten Monitor anschließt. Das empfiehlt sich sowieso immer, da manche Karten sonst komisch reagieren. Später wenn dann alles sauber läuft, kann man austesten ob standby geht oder ganz ohne Monitor (ggf. noch Kaltstart der VM ohne Monitor testen).

Hi, ich habe einen Monitor an der Maschine. Aber das ändert doch nix am Gast. Der ist ja virtualisierter Teil des PVE. Da kann ich keinen Monitor anschlissen, nur die PVE-Console nutzen. Mit PiTiVi sehe ich, dass ein rendering auf dem Gast >1Std. dauern soll, auf einem 6kerner-PC (auch ubuntu22) keine 10 Minuten.
Seit ich die invidia-Treiber disbaled habe, läuft keine grafische Oberfläche mehr auf dem PVE. Vor gnome oder xfce. Ich suche noch den "Fehler".

 

[mr44er]

Du kannst eine GPU nicht gleichzeitig mit passthrough für den Host und eine VM benutzen. Das ist entweder oder.

Was allerdings mit nur einer GPU geht ist: PVE booten (solange nutzt PVE die GPU) und dann einmalig eine VM starten, PVE hat ab da keine Ausgabe mehr über diese GPU, sondern nur noch die VM.
Wieder 'zurück' geht in den seltensten Fällen. Die bessere Option sind immer mehrere GPUs aufgeteilt, die schlechteste/älteste PVE zugewiesen, da sie nur die Konsole ausgeben muss.

 

[Hansen]

PVE booten (solange nutzt PVE die GPU) und dann einmalig eine VM starten, PVE hat ab da keine Ausgabe mehr über diese GPU, sondern nur noch die VM.

Was ist daran anders, als ich sonst meinen Server starte? Ich boote den PVE Host, starte dann aus der Web UI eine VM (in meinem Fall eher ein LXC). Und dann? Würdest du deinen Satz bitte näher erläutern?

Und dass es kein zurück gibt, ist kein Problem in meinem Fall, ich hab ja immer noch die SSH-Verbindung und die Web UI.

Vielen Dank, dass du mich auf deinen Post hier hingewiesen hast

 

[pmdk]

Du kannst eine GPU nicht gleichzeitig mit passthrough für den Host und eine VM benutzen. Das ist entweder oder.

Was allerdings mit nur einer GPU geht ist: PVE booten (solange nutzt PVE die GPU) und dann einmalig eine VM starten, PVE hat ab da keine Ausgabe mehr über diese GPU, sondern nur noch die VM.
Wieder 'zurück' geht in den seltensten Fällen. Die bessere Option sind immer mehrere GPUs aufgeteilt, die schlechteste/älteste PVE zugewiesen, da sie nur die Konsole ausgeben muss.

Das mag alles richtig sein. Aber die VM nutzt die GPU nicht. Die grafische Oberfläche ist auf 1280x800 Bildpunkte beschränkt, mehr geht nicht. Was soll ich da mit der GPU? Ich bin kein Gamer, bisschen Videoschnitt, ich mache das auch als VorTest für einen Kunden, der PVE auch mit einem Fujitsu GX2460M1 betreiben möchte, um Win11-Kisten mit ArcGIS flüssig laufen zu lassen.

 

[mr44er]

Was soll ich da mit der GPU?

Aber das ändert doch nix am Gast.

Na doch, wenn du die die GPU in einer VM nutzen willst, sei es auch 'nur' rendering oder so. Ich weiß jetzt nicht, ob wir aneinander vorbeireden, aber wie ich das verstehe, willst du die GPU in der VM benutzen. Auflösung oder ein angeschlossener Monitor sind da erstmal egal, aber entweder PVE oder die VM benutzt die GPU, beides geht nicht. Zumindest nicht via passthrough.

Würdest du deinen Satz bitte näher erläutern?

Die GPU wird in die VM gehoben und PVE quasi weggenommen.

 

[Hansen]

Danke, aber genau das funktioniert bei mir eben nicht. Ich wollte auch nicht pmdk den Thread klauen, ich dachte das passt thematisch. Sorry! Ich mache in meinem eigenen Thread weiter.

 

[pmdk]

Na doch, wenn du die die GPU in einer VM nutzen willst, sei es auch 'nur' rendering oder so. Ich weiß jetzt nicht, ob wir aneinander vorbeireden, aber wie ich das verstehe, willst du die GPU in der VM benutzen. Auflösung oder ein angeschlossener Monitor sind da erstmal egal, aber entweder PVE oder die VM benutzt die GPU, beides geht nicht. Zumindest nicht via passthrough.
Die GPU wird in die VM gehoben und PVE quasi weggenommen.

Gut, dann sind wir uns ja einig. Mir reicht es, wenn eine VM (gerne mehrere) sich die GPU schnappt. Wie machen wir das jetzt?

 

[mr44er]

Am besten wäre Proxmox frisch installieren, dürfte schneller als das rauskärchern irgendwelcher Dateien gehen, sofern das überhaupt möglich ist auf einen sauberen Stand. Zumindest hast du nach Neuinstallation einen garantierten, sauberen Stand.
Dann einen 6er Kernel drauf.
Windows oder ubuntu dann zunächst ohne passthrough installieren, davon auch erstmal alle updates ziehen.
Jetzt offizielle Anleitung für passthrough von PVE befolgen und dran denken, der Verlockung zu widerstehen Treiber auf dem Host zu installieren.

Teste es zunächst nur mit einer VM...nur jeweils in der VM brauchst du dann Treiber. Der nouveau von ubuntu sollte direkt funktionieren, der nvidia unter Windows wird ne Weile brauchen und einige Neustarts, bis das sauber klappt. Mein Tip für Windows 10/11: zunächst mal die alte Version durch Winupdate ziehen lassen, erst danach dann den aktuellsten von nvidia drüberinstallieren.
Später, wenn dann alles klappt, kannst du die nvidia beiden VMs zuweisen, aber nicht beide gleichzeitig starten, da die GPU nur an eine VM gereicht werden kann.

 

[pmdk]

Am besten wäre Proxmox frisch installieren, dürfte schneller als das rauskärchern irgendwelcher Dateien gehen, sofern das überhaupt möglich ist auf einen sauberen Stand. Zumindest hast du nach Neuinstallation einen garantierten, sauberen Stand.
Dann einen 6er Kernel drauf.
Windows oder ubuntu dann zunächst ohne passthrough installieren, davon auch erstmal alle updates ziehen.
Jetzt offizielle Anleitung für passthrough von PVE befolgen und dran denken, der Verlockung zu widerstehen Treiber auf dem Host zu installieren.

Ich mag es ja, wenn ich verstehe, warum etwas funktioniert oder nicht. Neuinstallation ist immer so Windows-Support. Und warum nen 6er Kernel, wenn Proxmox das nicht selber ausrollt?Das ist mir zu spooky. Ich bin dann mal gespannt, was der professional Service dazu schreibt.