Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Adventures in Virtualizing - A Long Journal of sorts so be warned

Featured Replies

Post #1: Abandon All Hope Ye Who Enter Here!

- A meandering discussion of my OCD process to decide on hardware

- A blow-by-blow of my battle with USB incompatibilities and IOMMU weirdness

- The boring tail of a man and his search for Xen

 

Post #2: The Secret Life of Walter Mitty

- Silo: A powerdown story

- How to Manage Users and influence people

- In the Mouth of Madness: Auto Mounting CIFS Shares

- If You liked it then you should've put a Static IP on it

 

Post #3: Sugar and Spice and Everything Nice

- The Joy of Plex

- What Time Is it?

- Girl, you looks good, won't you back that VM up (Alternate Title: Prepping for the Zombie Apocalypse)

- Tweakers gonna tweak

 

======================================

[glow=red,2,300]Hardware Acquisition (AMD motherboards)[/glow]

*ASUS M5A97 R2.0

*AMD FX-8320

*Kingston ValuRAM 8GB 1600MHz DDR3L ECC KVR16LE11/8KF

 

- I’m partial to AMD because while Intel may hold the Top Performer crown, and in some cases have a cpu based price:performance edge, for a total system that supports Virtualization AMD seems the better value proposition. 

 

- I don’t have any immediate plans to pass any devices through on my system but I wanted to leave my options open.  Unfortunately it just killed me to give up a SATA slot (irrationally so) by going with one of the ASRock Extreme boards even though their IOMMU capabilities were well established.  What's worse is I knew ASUS was known for flakey IOMMU but to me it was worth it to keep 6 onboard ports AND keep price down. So I ended up with the ASUS M5A97 R2.0 board for $53 from Microcenter (combo deal with my FX-8320 for another $129).  My hope is that ASUS bios updates will fix any IOMMU problems

 

- Another reason for going ASUS, even with its flakey IOMMU, is its support for ECC memory.  I started out with a single Kingston 8GB UDIMM ECC DDR3 DIMM because dual-channel memory performance is not even close to the top of my list of needs, but future expandability is (read: 3 remaining open memory slots for 23GB total).

 

- Similarly, another reason for my motherboard choice (ATX vice uATX) was the number of available PCIe slots for expansion cards.  I didn’t see the need to go with a 990 board (they cost more) so long as I had at least one 8x capable slot that could take one of the SAS cards as well as a few x1 for additional 2-sata card (to include my current HighPoint 1x 2-sata card). 

 

- To keep with the theme of lots of PCIe slots I got a PCI video card.  $13 for an ATI Rage PCI “server” video card.  In theory it should be able to pass through to a VM if I ever need to.  If not, then I’ll upgrade later but for now it should work perfectly.  It’s also very low power (not even a heatsink)

 

- So those were my personal purchasing decisions.  Everyone has their own needs and their own prejudices.  Just some food for thought for anyone looking at hardware trade space.

 

[glow=red,2,300]Hardware Swap and First Boot[/glow]

 

- Not too much to say about the hardware swap other than the USB header on the ASUS M5A97 R2.0 has a collar on it that was such a tight fit for the USB header board I used (http://www.amazon.com/Koutech-Header-Pin-Dual-Type-A-Adapter/dp/B003UIM142/ref=sr_1_12?ie=UTF8&qid=1399903495&sr=8-12&keywords=usb+header)  that when I removed it, it actually pulled the collar part way off the motherboard.  It didn't pull the pins out, just slid up them.  I was able to push it back down.  I filed down the plug on the header board and it made all the difference. 

 

- Bios settings … this is my first UEFI board so I dug in pretty deep.  I’m not sure if some of the changes I made were really necessary (I’m going to test a bit more later) but I mostly focused on turning off anything that had to do with Windows Secure Boot / UEFI, getting my USB as the first boot device, confirming ECC, and for now turning off IOMMU until I had a cleanly booting Unraid.  A note on the USB boot drive; I had two options for that, "UEFI Jetflash USB" and "Jetflash USB".  The UEFI Jetflash USB option did not work. 

 

- So now we arrive at my first problem … on first boot bzroot was loading VERY slowly.  I remembered reading that sometimes with Linux you needed to have IOMMU turned on to get USB and Network working correctly so I went ahead and set IOMMU to Enabled and IOMMU Mode to “64mb”.  Note that those are two different settings even though the manual only shows a single setting.  Clearly that is a recent change and a web search turns up nothing about what it means to have IOMMU Mode set to 64mb vs. disabled.  And remember this is different than the main IOMMU enable/disable option.

 

- On next boot attempt bzroot STILL loaded very slowly but I let it proceed and then all hell broke loose.  Despite the flashdrive clearly being read to initiate syslinux, once it got to booting the OS Unraid couldn't find any USB slots and no network. I got errors about USB slots not accepting addresses, error -32 and error -110, and the most deadly, /dev/disk/by-id/UNRAID could not be found.  Yes my flash drive was correctly named "UNRAID"

 

- First I tried playing with the USB settings, particularly the one that says “EHCI handoff” … long story short that must be enabled or the M/B won’t even try to boot from USB.  Incidentally it was defaulted to DISABLED.  I played about with Legacy USB settings, and those too must be enabled to even boot.  I'm sure I threw a hail mary at a few other options to no effect.

 

- I tried a few different USB sticks because I had read here on the forums that some folks had problems with some sticks booting fine and then not being found once bzroot loaded.  Still no joy, BUT ... what I learned is that my stick was indeed a problem with bzroot loading slowly.  Sadly it was not the cause of Unraid’s failure to load though. 

 

- A completely clean install of Unraid 6 on the "new" flash drive (an expensive 32GB USB3.0 I'm not willing to press into Unraid service) loaded very quickly, right to the point where it still failed to actually boot. A completely clean install of Unraid 5 on the new flash drive also loaded very quickly AND loaded Unraid as expected.

 

- So I "solved" the loading speed problem and had a hint at for the OS loading problem; a working 32-bit OS and a failing 64-bit OS pointed directly at IOMMU.  The problem is that most everything I read said that they solved their USB and network problems by enabling IOMMU not disabling it.  But as you can probably guess as soon as I disabled IOMMU completely it worked like a charm.  Next I tried with my old USB stick and my “production” Unraid install and it booted cleanly (all be it still slowly).

 

- At some point in here I upgrade the bios from 2201 to 2301.  The change log only said “stability changes” and as best I can tell made no difference (see below). UPDATE: a few days after I wrote this they pushed out 2501 with the specific comment "Enhance compatibility with some USB device."  The fact that the same drives were slow as before showed that was a lie!

 

- My next test was to enable IOMMU but leave IOMMU Mode disabled (as in not set to 64MB).  I SWEAR I tried this at least once before.  But I must admit it might have been once, part of my first attempts to solve my slow loading bzroot, and I might not have even let it finish in my impatience.  Or it was the bios change [shrug].  But it worked.  My old USB was slow to load bzroot but it booted cleanly and everything worked just as if I had never swapped hardware.  Again, this is with IOMMU enabled, and IOMMU Mode disabled.

 

- I’m told that my results of “pci devices” means I should be able to pass-thru to a VM but I haven’t tested yet.  I also have no idea of the ramifications of “64mb” not being enabled since its description says it has to do with converting 32-bit IO to 64-bit MMIO [shrug].  Time will tell and I’ll update this thread if new info presents itself.

 

- As for my slow loading Jetflash USB I went ahead and purchased a SanDisk Cruzer Fit 16GB (Limetech recommended) and it still loaded slowly.  I then bought a PNY Classic Attache 8gb and it loads nice and fast.

[glow=red,2,300]

Turning on Xen[/glow]

 

- Not much to say here.  I modified my systlinux.cfg to boot Xen/Unraid and added “dom0_max_vcpus=4 dom0_vcpus_pin”.  I did that because for now I’m keeping Plex in dom0 until I get everything worked out.  For now I’m considering dom0 as production and domU as test and I’ll fire up an instance of Plex inside there to play around.  Once I get all the details worked out I’ll downgrade dom0 to only 1 vcpu

 

- So what is it I need to work out?  Mostly understanding how and where I want all my data laid out, how to give array access to domU, what distro I want to settle on (I’m starting with Ubuntu Server 14.04 LTS) and how to ensure clean shutdown and restarts of the array.  I know all of this is documented in the forums, and I’ve even read them at one point, but I feel like it is scattered all over in the middle of threads so I’m taking it slow and hopefully providing something useful by documenting it here in this thread.  So you know ... this applies of course http://xkcd.com/927/

 

- Turning on Xen was a non-event which is just as it should be.  Everything (read: Plex) still worked, I could see via top that Unraid now had 4 vcpus and xl top showed that I was using the same amount of memory as before.  Recall that I had not limited dom0 memory.  Some have said they set it to 2GB but right now I didn’t see the point; not until I see it starving domU for memory.  I also am not using cache-dirs right now which I know is the main reason to put thought into dom0's memory configuration.

 

- I turned on network bridging naming it xenbr0 … again what I believed to be the “standard” and that will bite me in the butt in a few moments.  So here Tip: leave / set the network bridging name to br0.

 

[glow=red,2,300]Creating an Ubuntu VM[/glow]

 

- I used BUUX to create my VM (http://lime-technology.com/forum/index.php?topic=33132.0).  This is a great little utility to get you up and running quickly.  I know setting up a Xen config isn’t that hard but BUUX also makes it easy to get the right OS install package and for my first foray I wanted the steep part of the learning curve to be the more practical areas of virtualization.  I’ll worry about nuts and bolts learning later.

 

- As instructed from the github page I used wget to grab the current version of BUUX.  Unlike the instructions I didn’t put it in /boot but instead put it in /boot/scripts.  I like to keep /boot “clean” as it makes it easier to perform heavy maintenance on the flash drive like when we made the change from 5.0 to 6.0 and I wanted to be sure I wasn’t leaving any detritus around.  I also just like to consolidate all my scripts in one place (like preclear, diskspeed, my plex library cron scripts, etc.).  I also edited Buux.sh with nano to make the root directory /mnt/appdisk/vm because I will be using my non-array SSD and not my cache drive for my VMs.

 

- My first, second, and third run through of BUUX had some good learning points

  -- Do not put spaces in the domain name, it will fail

  -- Don’t give the domain a long name because you won’t want to have to type a long name when referencing your VMs

  -- If you named your bridge “xenbr0” then you will need to edit Buux.sh in one place to match that. 

  -- I know this because attempts two and three failed, with no real notice.  My only clue was that the vm failed to boot and an inspection of the config file showed br0.  Changing that didn’t solve the problem either. Once I made the change in the script it became obvious just how truncated my VM creation was because NOW, on my fourth attempt, it took WAAAAAAAAY longer as it finally started the Ubuntu installation process which included downloading a lot of stuff. 

 

- So the fourth time was a charm, and Ubuntu 14.04 LTS started its install process. 

 

- Incidentally I gave this VM 2GB of ram, 20 GB of disk, 4 vcpus, and called it “ubu” to keep it short and simple :)  As I mentioned before when this finally goes into “production” I’ll up it to 7 vcpus and I might decide to give it 4GB though only if it looks like it needs it.  I can say for sure is that while transcoding a single 1080p DTS stream down to 480p DD 2ch for remote viewing memory usage climbed less than 512mb (probably less but that is from memory).  So I don’t see needing that much memory for domU

 

- My only major quandary came when Ubuntu asked me what software packages to install.  There were a lot of choices like Basic Ubuntu Server, a few Kubuntu options, Ubuntu Desktop, Ubuntu GNOME Desktop, Ubuntu USB Desktop, etc.  I was stumped, and I probably still didn’t pick the “right” one for me for sure, but I settled on Basic Ubuntu Server since it seemed like the leanest usable option AND because the tutorials in the forums were titled “Ubuntu Server Guide” not "Ubuntu Desktop Guide" :)

 

- I knew there would be no desktop package and that I’d probably need to add my own later for VNC purposes.  Specifically I want to run Handbrake GUI on here so I’m pretty sure I’ll need a desktop that I can remote into.  Otherwise I know Plex won’t need it.  I haven’t settled on a torrent client yet.  I use uTorrent on my PC and would like to use it still and I’m not sure if I’ll need to use VNC for that or if I can manage through its own remote webapp.

 

- Another “question” that left me curious, but wasn’t too hard to decide for now, was how to work out partitions.  For now I choose to let the installer handle it, but I’ll be looking to see if there are reasons to change things up.  There was an option for encrypted partitions as well but I discarded those quickly for now.  I can’t imagine ever needing to deal with that.

 

- So the Ubuntu install finished, Buux finished things up, and I was finally left, as promised at the console of my Ubuntu domU.  I played around a little looking around the file system, inspecting xl top, and confirming that the VM was registered in Unraid.  So there isn’t much to show for all my efforts right now but it was still rather satisfying.

 

[glow=red,2,300]Switch to Ironic Badger's Arch VM[/glow]

 

I could write about the back and forth in my head about moving over to Arch, but in the end it just came down to I wanted to try it and I knew it was very slim. Despite being much further along now in my build I can still see myself switching back to Ubuntu so that I'm working with a distro and a Plex package that isn't run by one person (all be it a very helpful and generous person).  But for now, the rest of this will detail the steps I took to get Arch setup how I felt it should and the problems I ran into.

 

[glow=red,2,300]OK so you have a working Arch VM ... now what?[/glow]

What comes next is as much a how-to to help folks out as it is build documentation for myself so that I know what I need to do if I have to rebuild. 

  • Author

[glow=red,2,300]Clean VM Shut down on power loss[/glow]

 

You need to look at the powerdown thread here http://lime-technology.com/forum/index.php?topic=31735.0 about installing and apcupsd considerations.  Once you've done that you will see that you need a "kill script".

Create the new script: from unraid terminal

nano  /boot/config/plugins/powerdown/rc.unRAID.d/K00.sh

 

Add the required lines

 GNU nano 2.3.2     File: /boot/config/plugins/powerdown/rc.unRAID.d/K00.sh

#!bin/bash
[ -f /var/run/xenstored.pid ] && xl shutdown -a -w

 

Update your system:

/etc/rc.d/rc.unRAID update

 

Test it:

powerdown -r

 

[glow=red,2,300]Manage Users[/glow]

 

By default Ironic has created two users accounts: root and user both with default passwords of unraid6. You'll want to deal with that pretty quickly IMO.  My understanding is that it is a good idea to disable root entirely or at least disable root login via SSH.  Right now I'm not going to give detailed instructions because you can find everything you need here https://wiki.archlinux.org/index.php/users_and_groups and here https://wiki.archlinux.org/index.php/sudo

 

But here is what I suggest you accomplish:

- Create a new user with a name you want and make it part of the wheel group so it can use su / sudo

- Give that new user a decent password

- Confirm the new user is part of wheel and can use su / sudo or you will lock yourself out in the next few steps

- Disable the root user / disable the root user ssh login

- Disable the user user or change its password to something other than unraid6

 

[glow=red,2,300]Auto Mount Unraid Samba shares in the Arch (might not work in OS w/o Systemd)[/glow]

 

I tried a lot of stuff in vain, but this seemed to settle it. Before you start, make sure your VM can actually see your samba shares using "smbclient -L server.  If it can't then you have other things to deal with and that is for another tread.

[jumperalex@arch_vm ~]$ smbclient -L tower
params.c:OpenConfFile() - Unable to open configuration file "/etc/samba/smb.conf":
        No such file or directory
smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it
Enter jumperalex's password:
Domain=[WORKGROUP] OS=[unix] Server=[samba 4.0.15]

        Sharename       Type      Comment
        ---------       ----      -------
        flash           Disk      Flash share
        Appshare        Disk
        Movies          Disk
        Music           Disk
        PC_Backup       Disk
        TV Shows        Disk
        Torrents        Disk
        Videos          Disk
        plex            Disk
        IPC$            IPC       IPC Service (Media server)
Domain=[WORKGROUP] OS=[unix] Server=[samba 4.0.15]

        Server               Comment
        ---------            -------
        BRN001BA921F6C1
        TOWER                Media server

        Workgroup            Master
        ---------            -------
        WORKGROUP            TOWER

 

When prompted for a password you can just hit enter if your Unraid shares are "Public".  If they are not then your usernames better match and you should be able to enter your password.  I don't have that set up so I'm not 100% sure though.

 

Now you have to create your mount points.  I put them in /mnt and not /media.  It seems there is some debate about what is right and what is wrong.  I settled on /mnt but you can easily change it as you see fit.

 

$ sudo mkdir /mnt/movies
$ sudo mkdir /mnt/tv_shows
$ sudo mkdir /mnt/music
...

 

Next you'll be editing /etc/fstab as expected.  The trick to getting it to automount, and thus not fail to mount during boot because the network isn't ready yet, is the additional options of "auto,x-systemd.automount". Your fstab will look something like this:

$ sudo nano /etc/fstab

# /etc/fstab: static file system information
#
# <file system> <dir>   <type>  <options>       <dump>  <pass>
# /dev/xvda1
UUID=93ec2c22-36c1-487c-a888-adde602a16fe       /               ext4            rw,relatime,data=ordered        0 1
/dev/xvdb1              /mnt/data ext4 defaults 0 1

//Tower/Movies    /mnt/movies cifs auto,x-systemd.automount,guest,noperm,noserverino,uid=nobody,gid=users 0 0
//Tower/plex      /mnt/plex cifs auto,x-systemd.automount,guest,noperm,noserverino,uid=nobody,gid=users 0 0
//Tower/Videos    /mnt/videos cifs auto,x-systemd.automount,guest,noperm,noserverino,uid=nobody,gid=users 0 0
//Tower/Torrents  /mnt/torrents cifs auto,x-systemd.automount,guest,noperm,noserverino,uid=nobody,gid=users 0 0
//Tower/TV\040Shows /mnt/tv_shows cifs auto,x-systemd.automount,guest,noperm,noserverino,uid=nobody,gid=users 0 0
//Tower/Music     /mnt/music cifs auto,x-systemd.automount,guest,noperm,noserverino,uid=nobody,gid=users 0 0
//Tower/PC_Backup /mnt/pc_backup cifs auto,x-systemd.automount,guest,noperm,noserverino,uid=nobody,gid=users 0 0

guest - because I'm not using share security

noperm - no idea, still researching

noserverino - I know what the web says it does, and I know a thread here on the forums says it solved someone's problems, but I cannot validate that it is 100% needed, why, or what it specifically does.

NOTE: From looking at my logs it is clear that automount attempts are occurring before the network is available and I'm seeing "Failed to mount" msgs.  Once the network comes up i immediately see successful automounts.  So delaying service's is still important if they cannot graceully handle missing files/folders.  Fortunately Plex does.

 

[glow=red,2,300]Set Static IP for VM[/glow]

 

I tried using the more detailed instructions in the archVM thread but it didn't seem to work.  So I went for Ironic's other suggestion: setting my router to reserve a given IP for the mac assigned in arch.cfg.  That seemed to work through several reboots.  That said, the above note about failed automount attempts and network status may relate to the fact that the system is still using dhcp to get an address, all be it the same address every time. So actually establishing a true static IP might help.

 

  • Author

[glow=red,2,300]Install Plex[/glow]

sudo pacman -S plexmediaserver
or
sudo pacman -S plexmediaserver-plexpass
as appropriate.

Set up the config file

sudo nano /etc/conf.d/plexmediaserver

will get you something that looks like this.  However this version has two modifications I made.

PLEX_MEDIA_SERVER_USER=plex

 

PLEX_MEDIA_SERVER_HOME=/opt/plexmediaserver

 

# the number of plugins that can run at the same time

PLEX_MEDIA_SERVER_MAX_PLUGIN_PROCS=6

 

# ulimit -s $PLEX_MEDIA_SERVER_MAX_STACK_SIZE

PLEX_MEDIA_SERVER_MAX_STACK_SIZE=3000

 

# where the mediaserver should store the transcodes

PLEX_MEDIA_SERVER_TMPDIR=/var/tmp

 

# Change this to be what you like

#PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR="${PLEX_MEDIA_SERVER_HOME}/Library/Application Support"

PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR="/mnt/data/plexmediaserver/Library/Application Support"

 

# Logs live in /opt/plexmediaserver/Library/Application Support/Plex Media Server/Logs

# Uncomment this to send to syslog-ng

PLEX_MEDIA_SERVER_USE_SYSLOG=true

1) I added a custom location for "PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR" Notice that I'm placing the PMS Library into my data.img virtual disk via /mnt/data into a directory I created called "plexmediaserver".  The exact location (Unraid cache, VM.img, data.img, Unraid Array) and the top-level directory name are both up to you.  The pros and cons are out of scope for this post and are generally addressed elsewhere.  I will say my main reason for going data.img and not arch.img is for easy portability if I go with another VM.

 

2) I uncommented "PLEX_MEDIA_SERVER_USE_SYSLOG=true" because I want all PMS logs to be sent to journalctl.  If you have not yet learned about journalctl then read up here https://wiki.archlinux.org/index.php/systemd#Journal ... it is the roxor!!!  Now you don't have to dig deep into the PMS folders to find the log folder.  Just use "journalctl -f -u plexmediaserver" to watch plex logs as they roll in; both the server logs and the scanner logs and probably the DLNA logs but I'm not using those to validate it.

 

Manually start start plex with

sudo systemctl start plexmediaserver

Autostart plex on boot with

sudo systemctl enable plexmediaserver

 

From your PC browser visit http://[VM IP]:32400/web.  If that worked, then you are good to start following Plex's documentation to set up your libraries using the VM mount points for your content you should have defined above.  If however you are migrating from another instance of Plex (like from an Unraid Plug-in) then see below.

 

[glow=red,2,300]Migrate old Plex-Plugin Library into VM Plex [/glow]

Question: Why not just setup my libraries and let Plex recreate the database?

Answer: Because if you created media indexes to show the filmstrip style seek bar in Roku it can take a long time to recreate those with a large library.  So copying those over would be nice.  Otherwise this step is not needed and you can just let plex scan your library.

 

So these instructions are a hybrid of what is unRaid / VM specific and what the Plex docs say here: https://support.plex.tv/hc/en-us/articles/201370363-Move-an-Install-to-Another-System  I'm not going to recreate the wheel.  Where needed i'll give specifics, otherwise I'm going to point back to the Plex docs link.

 

Overview:

- disable "Empty trash automatically after every scan" on unraid-plex if enabled

- shutdown Unraid-plex

- shutdown vm-plex

- copy library from unraid-plex to vm-plex library

- set ownership of vm-plex library

- start vm-plex

- update your vm-plex Media Server Configuration

- confirm correct operation

- Enable "Empty trash automatically after every scan" if desired

- wait a few days before deleting unraid-plex library and removing unraid-plex-plugin.

 

Disable Emtpy Trash: See Plex Docs

 

Shutdown Unraid-plex: Use Unraid's Plex GUI

 

Shut Down vm-plex:

sudo systemctl stop plexmediaserver

 

Copy library from Unraid-plex to vm-plex library: Now comes the fun part.  I don't know where you stored your Plex library so you'll have to adjust accordingly.  I stored mine in "/mnt/appdisk" with "appdisk" on an SSD I mounted external to my array.  You might have used something else like "/mnt/cache/plex" with "plex" being a cache only (or not) user share.  I don't know, but you'll have to figure it out.  We don't care about the tmp directory.  Also, Plex says not to copy the plug-ins (they mean their's not unraid's).  I have never worried about this and I've never had problems.  If you find you have problems, please let me know.  Chances are the fix will be to go back after the copy and empty out that specific folder.

 

You need to make your old Plex Library accessible to your VM.  The easiest way to do that is to mount it.  From your VM console:

sudo mkdir /mnt/oldplex (we will delete this later)
sudo mount -t cifs //Tower/[your plex unraid user share] /mnt/oldplex -o guest
ls /mnt/oldplex (If you see the contents of your Plex Library Folder, SUCCESS!)

 

OK so this part can be tricky because I don't know for sure how your folders are set up.  From your vm-console navigate down into /mnt/oldplex until you reach "/mnt/oldplex/.../Plex Media Server".  Inside will be a bunch of directories.  We want to copy "/mnt/oldplex/.../Plex Media Server" into the "$PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR" that you defined in conf.d/plexmediaserver.  I will use mine as an example.  From your VM console:

sudo rsync -av /mnt/oldplex/Library/Application\ Support /mnt/data/plexmediaserver/Library/Application\ Support/

Don't worry; this is non-destructive so mistakes can be dealt with.

 

Set ownership of vm-plex library:  Per the Plex docs the owner:group should be plex:plex

sudo chown plex:plex -R /mnt/data/plexmediaserver

 

 

Start vm-plex

systemctl start plexmediaserve

 

Update your vm-plex Media Server Configuration - See Plex docs, scroll towards bottom.

 

Confirm correct operation: make sure all your media is there.  Make sure you can play it from your preferred client.

 

Enable "Empty trash automatically after every scan" if desired: See Plex docs

 

wait a few days before deleting unraid-plex library and removing unraid-plex-plugin

 

That should be it.  I did this a few days ago so there is a small chance I missed something.  Let me know if something isn't working or is confusing.

 

[glow=red,2,300]Set domU Time NTP[/glow]: This is a trick section.  You don't need to based on this http://wiki.xen.org/wiki/Xen_FAQ_DomU#How_can_i_synchronize_a_dom0_clock.3F and Unraid/dom0 should already be set up to keep time via NTP.  You can check in the Unraid gui under "Settings|Date and Time" and you can check your archVM time with "timedatectl status".

 

[glow=red,2,300]Back up the entire VM[/glow]: Short and sweet, go here http://lime-technology.com/forum/index.php?topic=33497.0

 

[glow=red,2,300]Back up your Plex Library[/glow]: So I know we just backed up our entire VM but I like the idea of keeping my Plex library accessible without being dependent on reading data.img.  If you don't create index images in plex then your library is probably pretty small so rebuilding it won't be such a chore.  Then again if it is that small, why not still just keep a spare copy of it around :)

 

Unless you want to enable samba sharing in your VM so that Unraid has access to data.img, you'll be running this script from your VM to push the backup into an Unraid share. 

 

[glow=red,2,300]Adjust vcpu and memory assignments[/glow]

dom0: You control from the syslinx.cfg in Unraid.  Click on "flash" in the main page.  Right now yours looks something like this:

label Xen/unRAID OS
  menu default
  kernel /syslinux/mboot.c32
  append /xen --- /bzimage --- /bzroot

and you can change it to look like this

label Xen/unRAID OS
  menu default
  kernel /syslinux/mboot.c32
  append /xen dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=2048M,max:2048M --- /bzimage --- /bzroot

or any combination you want.  See discussion below

 

As to your domU guests, a typical .cfg looks like

name = "arch"
memory = '4096'
vcpus = '7'
vif = [ 'bridge=xenbr0,mac=00:16:3E:1E:66:1F' ]
disk = ['file:/mnt/appdisk/vm/arch/arch.img,xvda,w','file:/mnt/appdisk/vm/arch/data.img,xvdb,w']
bootloader = "pygrub"

 

Discussion:

VCPU - When I started this I had two reasons to pin dom0 with one cpu vice letting it float.  First, the Xen best practices web page said it "may" help.  There is also evidence that not giving unraid 1 vcpu and pinning it has led to system crashes.  I followed that wisdom until I ran into some cpu bottlenecks which led me to think about giving it 2 vcpus (0,1) and still giving domU access to 1-7.  Plex still gets 7 vcpus and unraid gets one more vcpus for when it needs it.  I posted to the Xen list asking about my strategy.  Basically they told me I should just be giving all the doms access to all vcpus and at most consider playing with the "credit scheduler" to give unraid more priority if needed. http://xen.1045712.n5.nabble.com/Give-dom0-2-pinned-vcpus-but-share-one-with-domU-td5722792.html#a5722831  They also took it as a "todo" to change the Xen wiki to make it more clear that pinning a vcpu to dom0 isn't such a "best practice".  I've been running now for a few days allowing Xen to completely handle the vcpus.

 

Memory: There are tons of ways to look at it but the one constant theme I've run across is that you do NOT want to allow dom0 to boot with a lot of memory and then it loses it as the guests start using memory.  It has to do with certain parameters that are set based on available memory and then when it is lost it hurts performance.  So the advice is to give dom0 whatever memory you want and to hold it there.  Hence this setting, "dom0_mem=2048M,max:2048M" in my example above.  I figured 2048mb is MORE than plenty for unraid.  I don't even use cache-dir (a memory hog) but I might. I also might shrink dom0 memory in the future as I add more VM's or my current one (with 4096mb) starts growing (it uses 466mb right now)

  • Author

reserved

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.