testdasi

A few things I noticed: You seem to have set close to 16GB RAM per VM which means it's likely that starting 1 VM will cause the other VM to crash due to out of memory error. You need to reserve some RAM for unRAID itself. Try setting each VM to 12GB RAM Your xml looks quite different to mine. What unRAID version are you on? Also, someone probably will ask you for full diagnostic log.

Is there a list of GPU with reset issue to avoid?

Awesome idea! I think right now, unRAID can be made resistant to Ransomeware attack but it would be a quite round-about way (e.g. having an isolated "high risk" VM with only some share accessible). The above would make it even better.

Never is a strong word. I did read on the forum that some people have had no problem with SSD on array (beside write speed being slowed down by the parity HDD but read speed is still good). I think the "never" only applies to the parity disk cuz LT says they are not sure how TRIM would affect it.

Awesome! I have been manually distributing some files across the array by copying directly to the disk inside the top level folder with the share name. Have been worrying if I'm supposed to do that but this sounds like that's 100% fine. That's correct. Generally docker image, docker data (aka "app data") and VM vdisk (aka "domain") should be set to Cache Only.

It only has 1 resolution. I can't increase it.

Please please please. I'm very interested in knowing too.

TiHKAL here says he has only uses 12.5GB of RAM for VM (on a 16GB rig) so 3.5GB for unRAID. He got OOM crash. Link I had frequent but irregular OOM crash booting up VM when leaving 1.5GB to unRAID (8GB RAM total). Things get better when I left 2GB but VM still crashes every now and then. So wondering how much RAM should I reserve for unRAID? Is there a rule of thumb or something? I'm thinking to leave 8GB for unRAID on my main rig once I fully test unRAID out but that sounds a bit excessive.

unRAID error log is hillarious. It sounds like Skynet is coming. Anyway on a serious note, I did notice my VM on 6.2.0 beta crashing frequently due to out-of-memory error too. You have 16GB RAM, dedicated 12.5GB to VM. That leaves 3.5GB to unRAID. That's a bit high - unRAID is supposed to be a low footprint kinda thing - am I missing something?

I totally agree with you. I don't have any share set up with Cache = Yes. Either "Only" for performance or "No" for parity. A sizeable 25GB file takes only 2 minutes to write to array. A word doc takes not even 1 second.

It might just be anecdotal but I have had some bad experiences with Seagate Desktop range. I think I read somewhere that it has like the lowest reliability rating or something - which is consistent with my personal experience - but then it might just be confirmation bias.

Disable, I understand but is it too drastic to require a rebuild every time? Is there anyway to avoid it? I mean all it can be is just a wonky cable.

If the Z drive is part of the array and VM "C" drive (presumably your OS drive) is on Cache, how is that related to Unassigned? Your VM is on a vdisk file on cache, so your scenario of copying from cache + being cached shouldn't be a problem as they would be 2 different files as far as unRAID is concerned. I have tried copying files up to 8GB each around in various permutation between cache, vdisk, array and unassigned and have never had anything crashed, let alone automatically turned off (and I'm on 6.2.0 beta which should be buggy). In your case, I would suggest having a look at the PSU. Machine locking up is nothing strange. Machine turning itself off suddenly is an entirely different story.

Wow, what about Windows? any similar Windows app?

You can mount the other drive outside of array using Unassigned Devices and set up Crashplan docker to automatically back up the extra-important data on array (perhaps by putting it in a separate folder / share) to this drive. I think Unassigned Devices can even mount a network share (I never tested it!) so you can even back it up to a different PC. Crashplan subscription will allow you to back up to their storage for a 3rd layer of protection. Your coming from RAID 5 though, I have to warn you: performance difference is day and night.

My suspicion is the SATA card and GPU are on the same IOMMU groups - assuming everything works before the SATA card was introduced. Perhaps, trying turning on ACS Override to see if it helps. Otherwise, I bet someone will ask for full diagnostic log.

Caveat: the performance improvement is more significant without Turbo Write (selectable option in 6.2.0 beta). With Turbo Write, I get 110MB/s on array and about 210MB/s on cache. Still significant improvement but for most daily incremental changes, you might not even bother. Cache is still very relevant with VM vdisks and docker images. A vdisk on the same SSD cache gets me to 400MB/s (because a vdisk doesn't get the same network penalty).

Then no Upgrade should be a "need" and not a "want".

A bit of clarification: that figure is probably with reconstruct-write (aka Turbo write) turned off. 6.2.0 beta has it as an selectable option so can change with GUI. 6.1.9 I think you can edit some files to turn it on. My experience with turbo write is about 110 - 130 MB/s on array.

My VNC-based VM (which as I understand it uses a virtual GPU of sort) seems to be stuck at a fixed resolution i.e. tiny screen. Is there anyway to increase the resolution? I don't know maybe adding some RAM as graphic memory or something. I'm certainly not asking for 4k, but 720p would be really nice. *Edit: I did check in the VM display properties and it only has 1 resolution. I can't increase it. Hence this question.

I passed through a dedicated SSD to a Windows 10 VM (formatted as ntfs) via the scsi method to try eliminating network latency and everything is ok so far. The problem is Crashplan can't see this disk so can't back it up. So in a lightbulb moment, I set the same SSD to be a share via Unassigned Devices so Crashplan can see it. Tested it small scale (just did a 6GB iso file simultaneously being backed up by Crashplan and copied by Windows to another drive) and everything is still fine but I keep on having some uneasy feelings about it. Am I being paranoid or do you see any potential issues?

Wouldn't that just be Unassigned Devices?

ASRock seems to be on the "activate everything" crowd. E.g. their X99 mobo allows ECC RAM, unlike Asus.

You must have a really good sample.

I think (feel free to correct me) Plex and Emby are more server (i.e. supplying media to devices) and Kodi is more a client media centre (i.e. have some media locally, how to show / play them in a pleasing manner). So I'm a bit puzzled as to why would you want to have both Plex / Emby and Kodi on the same unRAID server though? I kinda feel like the answer is very obvious but can't seem to pin point it.