spotopolis
-
Posts
67 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by spotopolis
-
-
@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)-
1
-
-
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-
1
-
-
15 minutes ago, ich777 said:
I just pushed an update, please update the container itself.
You also have to add the port 7777 TCP like this in the template:
and you can delete those ports from the template:
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.
-
36 minutes ago, SimonF said:
Looks like to can add this option to the vfio driver and reboot.
options vfio-pci disable_denylist=1
https://patchwork.kernel.org/project/linux-crypto/patch/[email protected]/
The reason in the post above seems to indicate that it may make the system unstable if you bind qat to vfio.
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. -
16 hours ago, SimonF said:
If you cannot get it bound to vfio you will need to do a manual edit. Will only show other pci devs if bound to vfio in gui.
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
-
12 minutes ago, SimonF said:
If you cannot get it bound to vfio you will need to do a manual edit. Will only show other pci devs if bound to vfio in gui.
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.
-
26 minutes ago, SimonF said:
try changing blacklist
to blacklist qat_dh895xcc
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
-
21 minutes ago, SimonF said:
Does it show boumd to vfio on lspci -k?
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. -
10 minutes ago, SimonF said:
YES but system drivers wil! create the file.
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.
-
13 minutes ago, SimonF said:
Yes it is fine it is just an override file for vmmanager. No reboot.
But you will need to blacklist the kernel driver as it is bound to the device. Will only show in vm manager if bound to vfio and the override file is set.
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. -
3 minutes ago, SimonF said:
No does not need bind=
So the Fix common problems error is safe to ignore in this case? Should this need a reboot to apply as well?
-
32 minutes ago, SimonF said:
nano /boot/config/VMPCIOverride.cfg
and add 8086:0435 then save. Should show in VM Manager if bound to vfio now.
Looks like already bound to VFIO, have you rebooted?
also check to see if bound to a driver other than vfio.
Example
root@computenode:/mnt/user/VMbackup# lspci -s 0000:09:00.0 -k
09:00.0 VGA compatible controller: NVIDIA Corporation TU117GLM [Quadro T400 Mobile] (rev a1)
Subsystem: NVIDIA Corporation Device 1489
Kernel driver in use: nvidia
Kernel modules: nvidia_drm, nvidiarun lspci -s 0000:83:00.0 -k
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? -
5 minutes ago, alturismo said:
nope, 4 core with each 2 threads ... its correct like this
sample Gaming VM here
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.
-
1
-
-
6 minutes ago, alturismo said:
HT setup ... 4 cores "Hyperthreading"
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.
-
Necro again. But good job team.
-
Thats awesome. The downside is (for me anyway) Im running a vanilla dedicated server (without TShock). But the deeper I go into getting this server up and running it looks like I may have to start using it. Another issue is that you have to wait for TShock to be updated once an official Terraria patch has been released.
[Support] ich777 - Gameserver Dockers
in Docker Containers
Posted
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.