kaiguy

Hey all, So when I made the transition from ESXi to baremetal unRAID, I decided to ditch my Windows 7 VM on ESXi and start fresh with a new Windows 10 license on unRAID. For whatever reason, I just couldn't get OVMF to work so I just went with SeaBIOS, but for my (headless) needs, it worked just fine. Since the upgrade to 6.2, my VM performance seems pretty terrible. Instead of troubleshooting (since I don't use my VM for all that much), I figured I can just ditch the existing VM and create a new one. Here's where I need advice: assuming I can get OVMF working, what's the best method for reinstalling Windows 10 with my existing (OEM) license? Create a system image via Windows, create a new Win 10 VM and restore via system image? Just try installing again with my same license key? Truth be told I'm not very familiar with MS since I transitioned to Mac years ago, so I really don't know how strict MS is with regard to OEM licensing and (re)activation. I really just want to make sure that my VM is as optimized for 6.2 as possible. Thanks for any insight you can offer!

Thank you for this! First time installing it on unRAID and it works great! Now have my Haiku fan and Chamberlain garage door opener homekit-enabled!

Apologies if this has been asked before, but is there a recommended interval to run SSD Trim? Would this interval be influenced if I'm running a cache pool of multiple SSDs? Thanks in advance!

Thanks for your reply. I have the Sandy Bridge. I don't really have a specific need, per se. I guess I was thinking if I could upgrade the mobo and cpu relatively cheaply, I could buy myself a few more years of having a capable server while decreasing my power consumption. But perhaps you're right and it's not really worth it at this point. I probably need to get better about the "if it ain't broke" mentality.

Been rocking pretty much an identical build to John's Atlas build from 4-5 years ago. It's still working well, but I'd imagine I can get more energy efficient while not losing (or even gaining?) some performance. I could also then use my old 16GB of ECC RAM and build an unRAID backup/test box, since I have an extra unused unRAID key anyway. I used to run ESXi on my server, but now I'm running baremetal. Please look at my build in my sig. Ideally, I'd like to keep using my current ECC RAM, so really if possible, I'd like an unRAID-confirmed recommendation for an IPMI server mobo with DDR3 support, similar SATA setup, and an Intel CPU with solid ability (running Plex on my unRAID box). Any input would be greatly appreciated! Thanks! Edit: I should mention, DDR3 support is not a must-have, but more of a preference to save myself some $... If there's a much better mobo that requires DDR4, I'd still appreciate the suggestion!

Back up and running for me! Thank you if anything was done behind the scenes!

So this has happened a few times now, but I never see anything about it in the sab forums. Is this the same PPA that everyone else uses? Does this problem only seem to become apparent when used within a Docker? So confused why it affects us (unRAID users) but not the sab userbase as a whole. Edit: Not sure if this can be circumvented on the container side by incorporating "six", but that's what QNAP users did apparently to solve their similar issue.

I, too, am waiting until there is a general consensus it is safe to upgrade, as I only have my production server.

One more question, please... any movement on getting the ssh shutdown command to work when shutting down unRAID? Last I read was a post back in November saying that unRAID is trying to close the VM before the K00 script gets kicked off... Curious if anyone has a good solution for a clean guest shutdown. Thanks again! Edit: I'm going to try to insert the ssh shutdown command via the "stop" script, as I think it gets kicked off before anything else. Didn't even know that was an option until today.

Oh my bad. Thanks for replying! And, by the way, there's a small typo on your blog post where it says to delete the following lines to the XML: <qemu:arg value=’-drive’/> <qemu:arg value='ide-drive,bus=ide.1,drive=MacDVD'/> <qemu:arg value='-drive'/> <qemu:arg value='id=MacDVD,if=none,snapshot=on,file=/mnt/cache/vm_images/installer/Install_OS_X_10.11_El_Capitan.iso'/> Should be (first line): <qemu:arg value=’-device’/> <qemu:arg value='ide-drive,bus=ide.1,drive=MacDVD'/> <qemu:arg value='-drive'/> <qemu:arg value='id=MacDVD,if=none,snapshot=on,file=/mnt/cache/vm_images/installer/Install_OS_X_10.11_El_Capitan.iso'/> Thanks again!

Thanks for this guide! I'm an all-Apple household, and I'd really like a non-Linux VM that I can remotely connect to. Install was pretty much a breeze, except for the whole mouse deal within the web-VNC viewer. Now using the Mac native client to connect. A question for anyone--is there anyway to force a higher resolution when running headless? It looks like I don't have any resolution options. Thanks!

If I were a betting man, I'd say that's due to the web client transcoding. Maybe download OpenPHT to see if you experience the same issue.

What client are you using? OpenPHT or Plex Media Player? You don't necessarily have to use another computer, just try another client. I can keep my OpenPHT on Mac paused for as long as I want without issue. The only problem may be that unRAID has spun my disks down during that time and requires a bit more time to spin back up before the video will fully resume. Other clients sometimes kick me out of the pause after a while if its being transcoded... really is quite client-dependent (which would have little or nothing to do with this Docker container).

Awesome plugin! Two minor suggestions: First, it might be nice to have an option to not automatically perform the scan/tests upon accessing the Plugin. I know I just wanted to look at what options were available to me, but then it was scanning for a few minutes. Secondly, when suggested fixes are selected, it takes me to whatever section I chose, but then it has to scan again when I return to the plugin. Maybe a pop-up with the area to fix? Just some thoughts.

Wow. It really is that simple. I just confirmed that Plex is indeed creating the transcode files in /tmp when mapped (and set within PMS settings). I tried it on this version before and it didn't work for me. Guess it's just one of those things. Thank you to you both.

No. As a test, I entered the container, navigated to the mapped folder, and did a "touch test" to create a file. Exited the container and looked at that folder. Nada. Here's the weird thing. If I unmounted the tmpfs or the symlink to /tmp, then the file showed up.

Ok, well I tried symlinking a folder under unRAID to /tmp, then mapping that directory for the container. No go. Also tried creating a new tmpfs mount, and that didn't work either. Despite Plex's desire to limit transcoding to tmpfs, does anyone know how to go about exposing a tmpfs folder for use within Docker? I'm all out of ideas with my limited knowledge. I'd really like to transcode to RAM, as I have plenty of extra to use. Thanks!

Confirmed that utilizing the ADVANCED_DISABLEUPDATES variable let sab launch. Which is weird is that it had been working with v.1.0.2 for the last few weeks, and now that I have enabled that variable, it's running 1.0.1. Is this the related issue? I wonder if we need to report it over there...

Yup. Also not working here. Weird, because I haven't touched my server at all today. Wonder why it bombed out.

Pretty sure its a combo of both. I think Plex asked LSIO to remove the capability to map a transcode directory to /tmp in the container settings. Yet PMS still enables you to manually specify a transcode directory. Not sure if its default Docker limitations or PMS on top of that that prevents /tmp mapping...

I still don't really understand Plex's justification in limiting the ability to even allow an advanced user to setup transcoding to RAM. I want to move back to baremetal unRAID, but then I'd lose that ability (I run a ramdisk in my Windows 7 VM with PMS for transcoding and it works fine). The reasoning I got over on the Plex forums was that some people were encountering issues and it was done to maintain user experience, but that's painting with a pretty big brush.

I asked and got a response from a Plex "Ninja" about it: I got the answer that the change of transcoding directory as such will not be removed or altered, but the idea of putting the transcoding director for Plex in a RAM wasn't a good one. The output of a transcoding session can be quite large. if it fills your RAM - kernel will start killing things (but this I'm sure you already know). So I'm under the impression that there might be some sort of misunderstanding. That Plex doesn't want their software to use initramfs (as in Unraid) and possibly not even tmpfs, so that will be limited, but the actual change the location to another disk will be kept.

Does anyone happen to know why the Plex devs made this change? Seems like an unnecessary limitation without other info, as quite a few people like to configure this (heck, I even put my transcode directory on a spinner before I switched it over to RAM, since my ESXi environment had serious SSD space limitations).

So does that mean that there is no way to set the transcode directory to memory (i.e. /tmp)? I have been debating switching from ESXi to bare metal, and that is something I'd love to keep since it reduces wear on my SSDs...