spotopolis

Sorry. Not trying to be demanding. Trying to assist. No rush on my end. I appreciate your work. I use a lot of your containers.

@ich777 Here is a link to the github where they (Wolveix) are working on the API issue. (4) 1.0 API Connection Issue · Issue #260 · wolveix/satisfactory-server (github.com)

I see there is another user hosting a Docker for Satisfactory on the official Discord. It looks like they are working on the API fix as well.

Yes. And this is a local server on my home network, so even If I didn't, port forwarding shouldn't matter as I am directly connecting to the local IP

Trying to connect on 7777

I tried this and also updated the container and while in-game, trying to connect to the server, I am getting an API error

Did you ever find a solution to this? I would like to do the same.

I just tried that, and I didn't see any difference after another reboot. I ran lspci -k and the card is still not binding to vfio-pci

I did find this LINK in the Netgate documentation about this specific QAT device and the issues with VFIO-PCI checks. On their devices the drivers have the QAT on a denylist. Is it possible this is also in a denylist that can be overridden in Unraid?

I undid everything and rebooted to start over from scratch thinking maybe something was done out of order causing the issue. I started by just editing /boot/config/VMPCIOverride.cfg and adding to it "0000:83:00.0|8086:0435": I then rebooted and checked if that made a difference on its own. No. It did not. So I then checked the corresponding box under Tools->System Devices: and then verified that it was actually written to the file in /boot/config/vfio-pci.cfg: (the other two devices are a dual port Intel NIC I have already passed to the VM successfully) Yes it is actaully showing up in the vfio-pci.cfg when the box is ticked in the GUI. So I rebooted once more after making that change. This still did not allow me to add the QAT to the VM. I then checked the VFIO-PCI log in Tools->System Devices. At the top of the log, the device is being detected and has been bound to the vfio-pci, however, at the bottom of the log, I am only seeing the dual port Intel NIC that I have already passed though to the VM. The QuickAssist card is not showing up as listed in /sys/bus/pci/drivers/vfio-pci: I went ahead and tried to add it to the VM XML again anyway: This is how it was added. I got the same error again about the device not being found. So I went back to edit the XML to revert the changes I made, and noticed the bus had changed from '0x00' to '0x04': Im assuming this is referencing the VMs virtual bus that it is attached to, and not the physical bus on the host, correct? I also checked the path for the IOMMU groups since I was getting the error that 37 did not exist: Indeed only the dual port Intel NIC is showing up in that path and 37 for the QAT is not listed.

I got back home and did a manual edit to the XML: After saving the XML and trying to boot the VM, the VM would not boot and I got this error: 37 is the correct IOMMU group

Ill have to pick this up tomorrow if I am going to be editing the XML. I am away from home right now, so anytime I have rebooted my server, I have to wait for that VM to come back up to be able to connect to my VPN, to check the changes made. If I need to edit the XML, that means the VM is down, and I wont have a remote connection.

That resolved the errors at the top of the lspci -k output, but the device is still not showing as in use by vfio EDIT: brain fart. I just realized that the device would not show up as "in use" until it was attached to the VM and "IN USE", however, it is still not displayed as an option to add to the VM when I go to edit it. Am I going to need to manually add it in the XML view again? I dont believe that would work at this point though because I am still not seeing the QAT in

After running lspci -k, I happened to scroll up and caught this up top. It does not look like it is bound to vfio. EDIT: This is what I am seeing in the VFIO-PCI log I dont understand because it looks like its bound to VFIO in the logs.

Came back from a reboot and the option is still not available to pass to the VM. I did notice if I expanded the view from "in use" to "all" drivers, the Common is listed in use as well. Im going to blacklist that as well, reboot and see if that helps.

Is the correct way to do this still to do this in modprobe.d ? /boot/config/modprobe.d/qat_dh895xcc.conf EDIT: Got it. Did it though the GUI. In process of rebooting now. Ill report back once I can determine if that has resolved the issue.

So the Fix common problems error is safe to ignore in this case? Should this need a reboot to apply as well?

Yes I have rebooted already. Do I need to add "BIND=" before the line because that file does not exist in my "/boot/config" folder so I would need to create it. Im assuming so, cause after adding just "8086:0435" fix common problems said "Your flash drive has possible corruption on /boot/config/VMPCIOverride.cfg." This is the output of running lspci -m -nn EDIT: I modified /boot/config/VMPCIOverride.cfg to read as below: no more errors in fix common problems, however this device is still not listed as a device to select in the VM

I am having this same issue with an Intel QAT card on UNRAID 6.12.10. Im trying to pass it though to my pFsense VM. I tried adding the "boolBlacklist=false" for this device as shown in the first page of the thread, but it didnt work for me. This is considered a system device as it is a 0b40. If I try and manually ad it to the VMs XML file, it says that the device is currently in use. I have also tried to remove the whole of the "0b" class from the blacklist and saved the libvirt_helpers.php file, and I still did not see it as an available options for my VM to select. Being how the system grabs this at boot, I figured it need to be configured to not grab it during the boot process. Trying to release it, or modify the config once the system is running didnt make sense to me. I saw that the libvirt_helpser.php changes are lost on reboot, and I did verify that is the case. What else could I try to get this device to pass though?

Aaaah. I understand now. Thank you for the clarification. I see what you are saying. I hadn't considered it was listing it as 2 threads per core. I figured since it displayed the total number of cores, it would display the total number of threads. I was thinking my configuration was somehow corrupted and had mismatched information.

Shouldn't it be 4 cores and 4 threads, not 2 with my above settings? I have 8 total selected. EDIT: I initially configured this though the "form view" and just happened to notice the way the xml was configured as 4 core and 2 thread. I was surprised by that cause I thought it should read 4 thread.

Can someone please explain this to me? I have my VM set to 8 cores, but in the XML view under "cpu" , it looks like its set to use only 4 cores and 2 threads. <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' cores='4' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </cpu> I dont understand why that is when just above that section I have this: <vcpu placement='static'>8</vcpu> <cputune> <vcpupin vcpu='0' cpuset='20'/> <vcpupin vcpu='1' cpuset='84'/> <vcpupin vcpu='2' cpuset='21'/> <vcpupin vcpu='3' cpuset='85'/> <vcpupin vcpu='4' cpuset='22'/> <vcpupin vcpu='5' cpuset='86'/> <vcpupin vcpu='6' cpuset='23'/> <vcpupin vcpu='7' cpuset='87'/> </cputune>

I wanted to chime in here and I am having the same issue. My VM that is freezing is the latest version of PfSense (FreeBSD) that is locking up. No response from the console/ssh or the firewalls WebGUI. Nothing in the VMs logs or in UNRAIDS logs (even using the Enhanced Logs plugin). The only thing that kind of stood out to me was looking in the system processes in UNRAID, PfSense was recorded as using near half of my servers CPU resources (47% of my 24 total cores) . Im running a dual Xeon X5670 system but have VM CPU Pinning enabled for it ( cores/threads 8, 9, and 20, 21 ) Im not sure why its listed so high. In the VM, the PfSense WebGUI dash its only reporting 7%-10% CPU usage while the UNRAID Dashboard is reporting roughly the same for those cores. The update times look to be more frequent in the UNRAID dash, and I do see some quick jumps occasionally to around 40% on each of those 4 cores, but then falls right back down to single digit numbers. Is the 47% usage I'm seeing in the UNRAID logs reporting it as 47% of the 4 cores I have pinned, or is it reporting 47% of the 24 total cores in the system? I have another VM running Windows 8.1 Pro, with 4 cores pinned to it, and it has not frozen ever. I've only just had the PfSense VM freeze on me, and this is maybe the 2nd or 3rd time in 6 months to a year it has happened. The PfSense VM is my Firewall/Router for the whole house. When It freezes, I lose WAN connection, but my static LAN connections are all still working. I tried just restarting it from the VM popup menu in UNRAID and it didn't do anything. I had do Stop and Start the VM for it to come back up.

You might be able to come up with something using a boot cd ISO. I built one using http://www.plop.at/en/bootmanagers.html and use it on my server. It doesn't want to boot to the flash drive, so I have it boot to CD, it then runs a boot menu that allows me to boot to USB. Maybe you can make it work for you in someway that works for you?

Thanks for suggestion, but I'm afraid this will not work, looking at the addition suggested to the GO file I checked around my file system and "/usr/local/emhttp/plugins/webGui/phaze.page" does not even exist on my system. Hopefully we will see native support of b12+ within this plugin soon, until then I'll wait! I just tried it on v6b14b and it worked for me! Thank you! Down side is even though the page is showing up, there hasn't been any compatible Virtualbox releases for it, so it still will not run. At least the page is showing up now.