shawly

That is true. Though this could be an unsupported or experimental feature. But yeah you're absolutely right. Aren't shares available on boot or rather when plugins are installed? Of course the users would need to rebuild the driver package for that version. But wouldn't the same scenario happen right now if someone upgraded from an UnRAID version that has the OpenSource driver support to a newer version that doesn't have an OpenSource driver package like the latest version? These are all the supported cards: https://docs.nvidia.com/grid/gpus-supported-by-vgpu.html No sadly NVIDIA still locks the vGPU drivers behind a subscription model so the drivers can only legitimately be downloaded if one has access to the enterprise support portal and a license for guests is required as well. Which is why the only way for now would be that the users themselves would need to compile their driver packages for UnRAID. But yeah, you have convinced me that it might make more sense to provide all that functionality in a separate plugin. When I got more time on my hands I'll definitely give it a try. Though I have to say the developer documentation for implementing UnRAID plugins is quite terrible, being scattered over multiple forum threads with lots of outdated info is quite tiresome.

Providing the enterprise drivers publicly would definitely violate the EULA which is why I suggested the custom URL support or local storage support. That way people that have legitimate access to the driver can compile their own version locally. That way the plugin will never violate any EULA. I didn't want to implement a separate plugin since the fork would be exactly the same but with custom URL/share support for driver packages which is why I asked if you would accept such a PR. I imagined something like this, where if one would select GRID it would pull the latest compiled version from the local share. The settings could also be enabled through an "Advanced settings" section so regular users with consumer cards won't need to bother. Of course "easy to use" is kind of a hard requirement to fulfill with this, though I could imagine providing a script where users just put the enterprise drivers in a "build" folder on the share, press a button in the UI to compile the driver package and a script would compile it. Then the compiled package would be copied over to the "driver share" for the plugin to use or something like that. The cards themselves are supported by the consumer drivers yes, but not the vGPU functionality they technically support through the enterprise driver. Yeah it would definitely make sense to include it in the self compiled packages for the users instead of having to install it separately.

Just edited my post with more details on why this would be useful. Small correction, the enterprise GRID drivers need a subscription. So they can't be downloaded from public servers. That's why one would need to provide their own webserver to host the files on their internal network for UnRAID to download them. I mean technically the scripts wouldn't even need a custom webserver, they could just pull the packages from a disk on the UnRAID host. With vGPU support one can create multiple vGPUs that can be used with KVM + QEMU so you can use your GPU in a virtual machine without having to passthrough the whole GPU to a guest and it can be split into multiple vGPUs as well so one can use multiple guests AND simultaneously use the host GPU via Docker.

Hey @ich777! I wondered if you'd implement custom URL support (or accept a PR?) so drivers can be downloaded from another location, namely a locally hosted WebDAV server or another webserver. That way users could compile their driver packages themselves and host them on their local network. This would be useful for users with GRID cards where the drivers need a subscription. But with that people could use the vGPU functionality of GRID/Tesla/Quadro etc. cards on UnRAID, though mdevctl would need to be compiled for UnRAID/Slackware and be added to NerdTools as well for creating mdev devices.

I can confirm the libffi.so.7 error as well. When running "pip install docker-compose" the issue happens as well. You don't have to build it yourselves though, just download the .deb from the Ubuntu Archive and extract it http://archive.ubuntu.com/ubuntu/pool/main/libf/libffi/libffi7_3.3-4_amd64.deb Like this: # create a dir for extraction mkdir libffi7 # change into dir cd libffi7 # download libffi7 wget http://archive.ubuntu.com/ubuntu/pool/main/libf/libffi/libffi7_3.3-4_amd64.deb # extract deb file (you need to install binutils for the ar command!) ar x libffi7_3.3-4_amd64.deb # extract the data.tar.xz tar -xf data.tar.xz # secure copy the files to your unraid host (change unraid.local to whatever your unraid host is or use the IP) scp usr/lib/x86_64-linux-gnu/* [email protected]:/usr/lib64/