Jump to content

aterfax

Members
  • Content Count

    41
  • Joined

  • Last visited

Community Reputation

9 Neutral

About aterfax

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

656 profile views
  1. I might be wrong, but when I have set different UID and GID this does not seem to be respecting that. Edit: Looking at the files, the UID and GID are currently hardcoded in the dockerfile and I do not see anything in the start scripting to change from the default values of 99 and 100. So if you need to change this, you need to use the dockerfile and build the image yourself currently. Might be an improvement to add something to the built in start script to account for this. Many thanks @ich777
  2. Looks like this is related to the VM XML config: -<hostdev type="pci" mode="subsystem" managed="yes"> <driver name="vfio"/> -<source> <address bus="0x04" function="0x0" slot="0x00" domain="0x0000"/> </source> <rom file="/boot/vbios/gtx 1060 dump.rom"/> <address type="pci" bus="0x00" function="0x0" slot="0x05" domain="0x0000"/> </hostdev> -<hostdev type="pci" mode="subsystem" managed="yes"> <driver name="vfio"/> -<source> <address bus="0x04" function="0x1" slot="0x00" domain="0x0000"/> </source> <address type="pci" bus="0x00" function="0x0" slot="0x06" domain="0x0000"/> </hostdev> Assuming these are the GPU and GPU audio devices you have the audio in a different slot in the VM. These need to be matching the physical layout from the source hardware, i.e. same slot, different function. Correct the second address to the same slot and one function higher i.e. : <address type="pci" bus="0x00" function="0x1" slot="0x05" domain="0x0000"/> Which will probably fix the issue. See reasoning below: This is assuming that the passthrough is actually working* and the VM can actually see the GPU hardware.
  3. You should read what I said then - "I still get an RMRR warning on a ethernet passthrough on my server" i.e. I get the warning on a device that is passing through correctly. Ergo, red herring.
  4. I still get an RMRR warning on a ethernet passthrough on my server- given it is working in the VM, I assume you are getting a red herring of a warning. Edit: I suppose you can test by setting up a Ubuntu / linux VM and taking a look for the device.
  5. IOMMU RMRR warning is probably a red herring. I suspect you need to follow / attempt to avoid error 43 with the link I sent above: https://mathiashueber.com/fighting-error-43-nvidia-gpu-virtual-machine/ Specifically - KVM hidden via Libvirt xml - you will need to edit your VM in xml mode. (Top right toggle in the VM editor.) Another user fixed it here: You should probably search the forums first?
  6. Your poor grammar makes it very difficult to read. Try using bullet points, commas and paragraphs to separate your different points. Post diagnostics - what space invader video? Pastebin the error 43 stuff. Do you mean this error 43? https://mathiashueber.com/fighting-error-43-nvidia-gpu-virtual-machine/
  7. Personally I have to try to integrate the nvidia patch, rmrr patch and dockerswarm patching so I understand where you are coming from. Don't worry about delays, the effort is much appreciated.
  8. In the short term you could compile it yourself with the RMRR patch - but I'd imagine you will come across whatever the issue is in terms of compatibility. https://github.com/AnnabellaRenee87/Unraid-HP-Proliant-Edition Edit: I might be able to help with maintaining it?
  9. For users who want the letsencrypt in Poste IO working but are already using a letsencrypt docker, all you need to do is share the .well-known folders between your Poste IO and letsencrypt docker i.e. in the Poste IO docker config:
  10. Yes, wouldn't have posted about how to do it if it didn't work
  11. We should probably summon @CHBMB for his thoughts on that for the unraid nvidia plugin then.
  12. I think the custom packaging is necessary for the nvidia stuff in order for acceleration to be passed through to dockers (i.e. the CUDA libraries, which either need to be present in the install bzroot on the USB or to be installed at boot time. WRT to modules, I agree we could do with the Unraid devs maintaining and standardising a repo of kernel modules afaik. (That way there's a chain of trust in the compilation rather than just random users and modules can be tested/tweaked to match releases if needed.)
  13. Probably should have added - I have this working via doing the following: Install from the nvidia unraid plugin - boot and check it works! i.e. GPUs showing up with 'nvidia-smi' Extract and save the nvidia kernel modules from the bzmodule provided by the nvidia unraid plugin. They will be in the KERNELVERSION/kernel/drivers/video Keep these files for later. If you need to use the HP RMRR patch then apply the following ensuring you change the file path to the correct one between step 1 and step 2: ##Make necessary changes to fix HP RMRR issues sed -i '/return -EPERM;/d' ./kernel/drivers/iommu/intel-iommu.c Compile and install the bzimage-new and bzmodules-new using the method above in this thread with the correct options for IP_VS support replacing the existing files in /boot (they will be called bzimage and bzmodules - make a backup just in case!!!) Boot up and 'modprobe ip_vs' then check it is working via docker swarm. (Modprobe might not be needed but I didn't see it loaded...) For testing I hosted a default nginx on my nodes then used curl to check they were alive with: 'curl localhost:8888' docker service create --name my_web \ --replicas 3 \ --publish published=8888,target=80 \ nginx Assuming you get the standard nginx response from each node, it should be working. Now to get nvidia stuff working again. Now navigate back to where you saved the nvidia modules and 'insmod nvidia.ko' and the remaining modules. Now check that they are loaded and your GPUs show up with 'nvidia-smi' I've had no success trying to include the nvidia stuff into the former compilation as yet but I suspect it is absolutely key for you to ensure you are using the bzroot file from the unraid nvidia plugin as it includes some nvidia/CUDA software required. I've added my working bzmodules and bzimage that I compiled with RMRR patch to the post so people can skip compiling if they wish. Also added the nvidia modules to the post so you don't need to extract them with 7zip etc... bzmodules bzimage nvidia-modeset.ko nvidia-uvm.ko nvidia.ko nvidia-drm.ko
  14. Hi all, I cannot see any downsides/issues considering people have been doing this to enable docker swarm support. Should be a simple change to the .config file used for compiling the unraid kernel by devs. Could we get IP Virtual Server support turned on in the kernel as per: This should only require the IP_VS options enabling shown with current status below i.e. - Generally Necessary: - CONFIG_NETFILTER_XT_MATCH_IPVS: missing - CONFIG_IP_VS: missing Optional: - CONFIG_CGROUP_HUGETLB: missing - CONFIG_NET_CLS_CGROUP: missing - CONFIG_CGROUP_NET_PRIO: missing - CONFIG_IP_VS_NFCT: missing - CONFIG_IP_VS_PROTO_TCP: missing - CONFIG_IP_VS_PROTO_UDP: missing - CONFIG_IP_VS_RR: missing - CONFIG_EXT4_FS: enabled (as module) - CONFIG_EXT4_FS_POSIX_ACL: enabled - CONFIG_EXT4_FS_SECURITY: missing 
  15. @CHBMB looks like I am not the only one with nvidia and needing some kernel compile options to support docker swarm. Have to say that my compile is further complicated by the requirement for the HP RMRR patch and the nvidia support!