pcmantinker

This hasn't happened in a few days for me now. It should be easy enough to move files between instances if need be in the future. It seems strange that activation is tied to an instance and not the management instance. I suppose that was done in order to keep attention on instance activation count.

Have you seen issues with instances losing license activation between container restarts? I tried to manually re-activate from the terminal for my Amp docker, but the Amp instance list doesn't appear to be available. When I try to activate a specific instance, it says that the instance can't be found.

Thanks for the quick reply. I walked through the setup again for a standalone install and tried on a different computer/browser. I think the computer I was using originally had issues with the JavaScript web application part of the AMP server. It could have also been an adblocker that was conflicting with the web page. I will try again on the original computer after clearing cache and updating browser adblock rules. I have now been able to successfully setup a MineCraft server with a full Amp license. I am trying to install an ARK instance now and it appears to be using a modified SteamCMD process that doesn't tie to a particular Steam account. This is nice because I have SteamGaurd on my account and didn't want to have to lift that.

I just tried your Docker container for Amp and it installed fine, but I can't setup any new instances of servers. Everything is readonly when trying to edit text or drop down boxes. Is there some configuration that is missing?

I just wanted to post a follow up to my original post. I am now running unRAID 6.8.1 and have been successfully running VMs for the past couple of months with VT-d turned off. It seems to be the way HP configured hardware passthrough on this machine and how it interacts with the Linux kernel. This is a strange case, but none of my VMs need hardware passthrough so it's not a big deal.

I have Unraid 6.8.0-rc7 running on my HP Proliant DL380 G7 server. My server has the following setup: Dual Intel Xeon E5649 72GB DDR3 LSI 9201-8i P20 HBA card HP SAS expander 512GB NVMe SSD NVIDIA Quadro P400 The BIOS is flashed to the 09/30/2010 version for quieter fans. After a few days of running the system with the BIOS settings reset, I started receiving NMI processor lockups similar to the following message: NMI: IOCK error (debug interrupt?) for reason 61 on CPU 0 Many of the search results for messages like the one above talk about updating the BIOS and setting different kernel flags to address HP's ILO 3 NMI watchdog. I know that HP provides drivers for RedHat for the ILO 3 NMI watchdog, but I haven't seen any for Slackware and I'm not sure how I would go about installing an rpm driver in a non RedHat distribution. I tried flashing the newest BIOS from 2018 and got the same results. I also added the following kernel flags to the Syslinux Configuration, but still got the NMI messages: intremap=off panic_on_unrecovered_nmi=1 unknown_nmi_panic=1 nmi_watchdog=0 According to Slackware's documentation on the nmi_watchdog flag, you should set it to "1" first. If you run "cat /proc/interrupt | grep NMI" and it returns 0, then you should then try setting it to "2" to see if that makes a difference. I've tried both "1" and "2" and neither seem to make a difference. Setting the flag to "0" turns off the watchdog. I was eventually successful though. With some fiddling with CPU settings in the BIOS, I managed to get these messages to disappear when turning off VT-x and VT-d. I suspect that the issue is related to VT-d and not VT-x, but I haven't yet tested with just VT-x enabled. I know that the CPUs are fine because prior to unRAID, I used to run Windows Server 2019 with VMs without issue. Has anyone else seen these errors with VT-x/VT-d? Maybe this is a Linux kernel issue? It would be nice to be able to use both of these CPU features for VMs, but it's not too bad if it doesn't work since I mainly use Docker containers.