Search results

an alternative would be to use '/dev/dri/by-path' which encodes the pciid and that should be more stable? (i hope at least)

hi, sure, the bug tracker is open to all, not bound to a subscription: https://bugzilla.proxmox.com please do file a bug for both issues! thanks

this sounds especially worrying as the pve ui does not touch this part of the system at all, even when adding a new user. i'd first try to re-establish a successful login via ssh, and then look in the journal/syslog to further diagnose the issue. if you have "physical" access (or via a ipmi...

could you also try with a linux guest? just to rule out it's a windows and/or guest driver related issue?

answered in your other thread: https://forum.proxmox.com/threads/proxmox-vgpu-configuration-troubleshooting.182337/ please don't double post in the future

hi, since this is an english forum, please write your posts in english. here the translated post: is that the correct ip range for your network? did you enter 'https://192.168.1.110:8006' as your url in the browser?

hi, did you try with other linux flavors too? only found https://community.frame.work/t/0x08000800-uncorrected-error-causing-a-data-fabric-sync-flood-event/79286 which points to a kernel issue (it's different hardware though)

interesting, did you do more than that? because there should be no difference between activating the 'ALL' service vs activating all 3 individually (nvidias script basically first finds all nvidia cards with 'ALL' and then does the same for each card what it would do if activated for a single...

i did not have access to such systems, but i think you could either do vgpu via ai enterprise, or passthrough everything, see this note in the nvidia docs: https://docs.nvidia.com/ai-enterprise/release-6/6.2/support/support-matrix.html#supported-platforms

you should be able to gzip it , e.g. by piping it into gzip journalctl <your journalctl parameters go here> | gzip > journal.log.gz a good start would be to use the '--since' and '--until' flags to limit the journal to a specific timerange an example could be journalctl --since 2026-03-31...

please don't double/cross post your issue across various threads. instead open your own when the issue is not the same (as i told you in the other thread)

it's definitely not the same issue, the OP could not passthrough at all for some reason. please open a new thread with a bit more info (e.g. the error code from the windows driver) also try without viommu=intel on the machine and see here: https://pve.proxmox.com/wiki/PCI_Passthrough#Troubleshooting

there is already an open bug on https://bugzilla.proxmox.com/show_bug.cgi?id=7374 but we don't currently know what's the underlying reason. (and we don't have the matching hardware here to try to bisect the kernel) are you by any chance using a gigabyte mainboard and/or gpu?

ok something caused the pdm to not reach the remotes though as seen by the journal. has one of the migrated vm anything to do with networking/routing? is it maybe the pdm itself?

hi, glaube zwar nicht dass es daran liegt, aber die zwei zeilen hostpci0: 15:00.0,pcie=1,x-vga=1 hostpci1: 15:00.1,pcie=1 sollte man durch hostpci0: 15:00,pcie=1,x-vga=1 ersetzen. Da werden dann auch beide devices durchgereicht aber als 'multifunction' device. manchmal mögen das die...

can you check/post the journal/dmesg of the host?

maybe the node was loaded so much that the requests took longer than usual and timed out? but the timeframe would check out with the missing task

the issue here is that the underlying tool (dd) prints '\r' as "newlines" (it's to overwrite the old text on the cli) on the commandline, etc. it's possibly "normalized" to a \n but the web ui framework simply print it as is, and \r will not be interpreted by the browser ... we could...

hi, was the vm 1000 located on another node perhaps? or is the 'pveEDGE' remote just a single node? can you show what the 'pveEDGE' tasks (on the pve gui, not pdm) looks like?

both would probably be best