testdasi

Read through the manual pdf. Find out if the BIOS says anything like "Initial display output" or "Primary display output" or something like that. Having a skim through the pdf on Asus website, I don't think it has that (in fact, it looks surprisingly quite limited - I can't even find PCIe bifurcation but then I skim). PCIe slots are not all the same. And don't confuse "lane" with "slot". A x16 slot can only have x4 lanes. The 2nd PCIe x16 slot on your X570 motherboard only supports up to PCIe x4 speed (i.e. lanes) which, depending on the GPU, can be too slow. If the BIOS allows you to pick the slow slot as primary display then you can put a cheap GPU on that slot to boot Unraid with (e.g. a GT 710) and have your powerful GPU to pass through. You seem to misunderstand what the 2nd ("Unraid") GPU is used for. It doesn't matter if you have never used the Unraid GUI. Having a GPU for Unraid is less a requirement for Unraid but rather to stop the other (main / powerful) Nvidia GPU from booting up (so to speak) so that when it's passed through to the VM, it is less likely to detect that it is being used in a VM and thus doesn't throw error code 43. It also makes things easier to dump vbios etc. Again, there is no guarantee. You can only have 1 GPU and pass it through fine without error code 43 and vice versa may have 2 GPU and have the problem.

Just notice you mentioned 12i BIOS. The 12i BIOS is bugged (at least on my Designare EX). It doesn't even boot properly with my settings, let alone passing through any device. I am now sticking to 12e. With regards to ACS Override, you are not running enterprise-level security. For home users, 99% of any concern over ACS Override is completely irrelevant. It's a crude example, but it's like of course you don't want to wear underwear to work but at home, who cares if you are in your underwear if that makes your life (at home) easier? Last but not least, you are not using Unraid.

As always, Tools -> Diagnostics -> attach zip file.

Possible without guarantee. You misunderstood odds vs guarantee Having a GPU for Unraid to boot with improves your odds (i.e. probability) of avoiding problems passing through the (other) GPU. It is NOT a guarantee that you will have NO problem at all (or that it is even possible) Conversely, it does NOT mean that it is IMPOSSIBLE to pass through the only / primary GPU. Note that dumping vbios does require a 2nd GPU for Unraid to boot with (so you can dump the vbios for the other card) but once dumped, it does not require the 2nd GPU to use the vbios file. Having said the above, I recommend you have a look at the owner's manual of your prospective motherboard to check if its BIOS settings allow you to pick any PCIe slot to boot with (the primary slot). That gives you the flexibility to go the Unraid GPU route without sacrificing the 1st PCIe slot (which is usually the fastest with best clearance for multi-slot GPU).

The 3700X does not have integrated GPU. The 2070 should be pass-through-able. Check your BIOS to see if you can pick an alternative PCIe slot as primary.

Surprised no body asked for: Tools -> Diagnostics -> attach zip file Preferably do this AFTER you start your VM (and fail and/or syslog shoots to 100%). Attach your VM xml (if copy-paste, use the code function - the </> button next the smiley button) Syslog shooting to 100% suggests you have an actual problem that is spamming your log.

I remember there was a patch but it was proven to be unreliable so it was removed in the subsequent rc. If there's a new patch coming then LT is usually good with at least try including it in the next minor version. @Mihael: You don't NEED a GPU for Unraid. It's just that NOT booting Unraid on a to-be-passed-through GPU reduces the chance of problems. That's why I only picked motherboards that (a) have integrated GPU (mostly server boards) or (b) supports iGPU (if CPU supports it) or (c) allows users to pick any PCIe slot are primary GPU to boot with (usually Gigabyte).

Plug your USB stick to another machine and attached in your next post the 2 zip files in the screenshot (tower-diagnostics-20191209-1038.zip and tower-diagnostics-20191209-1048.zip - they are under \logs folder). Someone on here probably can help have a look. The booting issue is probably unrelated to what you did to the share cache settings. Also, with regards to cache, you should have set it to "Yes" (EXCEPT for the appdata / docker / vdisk) and run the mover to free up cache space first. Yes = store in cache first, mover always moves out of cache into array Prefer = always store in cache, unless cache full then mover moves into array, if cache frees up move back onto cache Only = no array storage, mover is disabled for the share No = no cache storage, mover is disabled for the share Setting it to No, will not move the files out of your cache because the mover is (effectively) disabled for that share. "Prefer" is a relatively complex operation that is in the "do it if you know what you are doing" category. If you are not sure, please ask questions and not try to fix it without guidance.

What version was you before that? The kernel was downgraded from rc7 to rc8 (and then rc9 was a kernel bug fix of rc8).

No details, no diagnostics, no syslog, no xml => no answer. Bumping aint gonna help.

I have she-who-must-be-obeyed put it in her weekly reminder. (She) say it - (I) do it - (backup) sorted.

More RAM alone won't necessarily resolve your problem. Crashplan is known to eat memory for breakfast lunch and dinner (btw, I believe Crashplan uses java so that's what Brit saw). The short term way around it is to limit Crashplan docker memory usage so it doesn't end up eating other stuff. In Docker template, click Advanced View then in the Extra Parameters box add --memory=8G (in the above example, it will limit the memory available to Crashplan to 8G - I actually had to use 8G because 4G crashes my Crashplan - just to demo how much memory Crashplan needs). In the medium term, add more RAM so you have more available for other stuff. In the long term, I would recommend moving away from Crashplan all together. They used to be great but no more.

I go for a simpler approach: my backup trigger is manual. I trust me more than any script and automatic backup, in my opinion, defeats the purpose even without the cryptovirus scenario e.g. maybe I accidentally delete something or edit something wrongly -> automatic backup -> no recovery.

Let's try these: Update to latest (6.8.0-rc9) Change your Q35 machine type to Q35 4.0.1 (6.8.0 has qemu 4.x which has better PCIe support for Q35 machine type). Add <ioapic driver='kvm'/> to before </features> in your xml Tools -> Diagnostics -> attach new zip file (every time you make major changes like ACS Override etc, it's always worthwhile to dump a new set of diagnostics since your config would change rather drastically).

Are you looking to sync or to back up? Same same but different. For example, if u accidentally delete a file, a sync will ensure that file is also gone on the other side. That is why we don't run back up as a sync. Specifically to your case, you don't want the Unraid server to perform the back up (a "pull" ). You want your main PC to decide what and when to back up onto the Unraid storage (a "push" ).

You didn't read my entire post, did you? I specifically mentioned: "For CPU before 2015, you need to multiply the passmark by 2, hence, the 2000 passmark per stream general advice." Your Xeon E5-2680 v2 (there wasn't a 2860 so probably a typo there) came out in 2013. The OP asked specifically about Ryzen (which came out in 2017) so I am comfortable with providing the post-2015 estimate and, even so, tried to protect myself with a specific statement about CPU before 2015. Your point about bit-rate, while valid, is also missing the point about the estimate. The Plex 2000 passmark estimate is conservative to begin with because Plex doesn't want people who skim and blame their (official) guidance that their exactly-2000-passmark CPU can't handle a 20Mbps 1080p stream. Peak bit rate is the reason why we have buffer. The passmark estimate is based on average because with a buffer, the peak is evened out by all the time that the bit rate doesn't reach 50Mbps. Let me quote myself again: "We are estimating, not calculating the trajectory of a nuclear missile." I would say 1x H265 or 2x H264. 3x H264 depends on the actual vids. My 2990WX on a single core (provided it is on the NUMA node with memory controller) can do 2x H264 1080p streams at about 95% load and its single core passmark is 2072 LOL.

Tools -> Diagnostics -> attach zip file. Also provide your VM xml (if copy-paste, use the forum code functionality - the </> button next to the smiley button). Also, your whole paragraph about vfio and initrd suggests you are not following instructions exactly. It is very hard to know what is wrong to help if we can't be sure if what is in the guide was followed or not.

Try switching machine type. I noticed if shutting down Q35 VM = GPU fans still spinning but shutting down i440fx VM = GPU fans stop. That suggests at least a difference in power draw when VM is not running between the 2 machine types.

+1 Customisable grouping would be very useful if incorporated with additional functionalities such as the ability to start/stop a group together. Imagine having 2 set of dockers, 1 for when gaming VM is run and 1 otherwise. In a few clicks, you can switch between them. This can be done using scripts easily (e.g. what I'm doing) but would be a lot more user friendly on the GUI.

Exactly 8 cores, and should be the last 8 physical cores (+ their hyper-threading sisters). The 3950X has 2 CCD's linked together with Infinity Fabric. You don't want to jump CCD when processing things as cache needs to be copied to the other CCD, introducing latency. The IO die design only mitigates cross-CCD latency but cannot eliminate it. The 1st CCD (first 8 physical cores + HT sisters) contains core 0, which should generally be left free for Unraid to do Unraid things - so the 1st CCD can't be fully isolated. The 2nd CCD, in contrast, can be fully isolated to the VM in syslinux for the lowest possible latency. 8 cores are more than enough for all current triple-A titles. For games that don't need that many cores, 4 cores (i.e. same CCX) are probably even better for more consistent performance. But that's overthinking things in a sense. RAM is less important. 16GB is sufficient for most games. 32GB is an overkill. In fact, your rig, with the usage you are reporting, is an overkill.

TL;DR - I don't think his result is different from the expected performance of Ryzen. You can actually get a pretty decent estimate from the passmark score and the relative complexity difference between 4k vs 1080p and H265 vs H264. Each 4k H265 stream needs about 7500-8000 passmark => each 1080p H265 stream about 1800-2000 => each 1080p H264 stream about 1000. Note: the above only applies to CPU after about 2015 when H265 hardware accelerated video became a thing. For CPU before 2015, you need to multiply the passmark by 2, hence, the 2000 passmark per stream general advice. I think there was also a period before 2015 that H264 was accelerated but H265 was not and AMD implementation was different from Intel etc. but that is overly complicating things. We are estimating, not calculating the trajectory of a nuclear missile. So just to estimate from my 2990WX, which has about 23200 passmark. I only use 1 bank of the hyper-threaded pairs for Plex and an additional hyper-threaded core adds about 30% performance so using 1 bank drops my (estimated) score to 17800. I only use half of the cores (let's ignore NUMA problem for now), so I'm down to about 8900 passmark for my Plex. So based on the estimate, I should be comfortable with 1x 4k stream or 4x 1080p streams - which is very much consistent with my own experience. If I ever have to do more than 2 4k streams simultaneously, I will certainly get a P2000 and donate a few beers to Unraid Nvidia guys.

I suggest perhaps you post in the UD support topic. I haven't seen this before.

Press the black + button on the lower right of the black disk icon below the "T" in IDENTIFICATION to show the individual partitions.

Yes and no. You can get a SATA power cable extension to really run as many output from a single PSU cable as you want. However, the power draw (i.e. current) on the cable can exceed what it is rated for and causes it to literally melt. This can happen even without actual failure of the connector / cable due to HDD power surge when spinning up. When this happens, at best, your PC smells really bad and you need to rebuild parity due to drives dropping offline but at worst, your disks are dead. Note: not that it will definitely happen, just that the chance of it happening increases with every additional drive you add to the same line. So you are better off running multiple cables (i.e. using multiple plugs on the PSU).

Turn on Syslog server to mirror to flash (Settings -> Syslog Server). Start your server, wait till crash happens, reboot. Tools -> Diagnostics -> attach zip file Attach mirrored syslog file (which should include both pre and post crash events).