So I have an old QNAP 8 bay (TS-879U-RP) - the specs are a Core i3 w/ 16GB memory.  I have it setup in a Raid 10 configuration with 4TB WD Reds and primarily used it for storage & VMware ESXi Datastore over NFS for VM's running on another server.

 

I recently purchased a 24 bay Supermicro running dual Xeon E5-2690's with 100GB of memory.  My array is setup of 8 6TB SAS 12gbps drives.  So far in my experience it is EXTREMELY slow for VM's.  Especially if I'm transferring files to the server at the same time I'm trying to run a VM.  I run 10+ VM's pulling from my QNAP over an NFS share that run significantly better than this MUCH beefier box running unRAID.  Is this normal? Is there anything I can do to improve this? I've looked into the cache drives and all that, but so far that's another issue I have is how unRAID uses cache drives.  Doesn't seem to work at all like a QNAP uses it's cache drives.  I planned on using this box for Plex, NZBGET, VM's, etc.  But so far it feels like it can barely support file transfers + VM's so I'm wondering if I went with the wrong OS (unRAID).

 

Any ideas you have I would greatly appreciate it.  Would FreeNAS be better for what I'm trying to do?

With unRAID you do not want to run VMs with their vdisks on the main array is parity protection is being used.    The architecture of unRAID gives slow write performance to array disks due to the overheads of the way parity is maintained in real time and this severely affects VM performance.

 

You will get much better performance if vdisks are stored on either the cache pool, or on disks external to the array (mounted via Unassigned Devices plugin).

19 minutes ago, physikal said:

another issue I have is how unRAID uses cache drives.

Could you be more specific? There are a number of ways to configure the cache pool, and a number of ways to use it.

1 minute ago, trurl said:

Could you be more specific? There are a number of ways to configure the cache pool, and a number of ways to use it.

 

Sure.

 

On my QNAP you specify a disk (in my case an SSD) as a cache drive.  From that point forward it's invisible to the user.  It just works and functions exactly how you would expect a cache to work, a temporary spot for files that are accessed more frequently than others over a period of time.  With unRAID it feels like the cache drive is more like an unassigned drive that you have mounted and the mover/scheduler stores files to and fro based on your settings (shared settings prefer/only/etc).  It's not really automated based on usage.  

 

I could be wrong on all this, but that is my current understanding of how things work.

You are correct in that the unRAID cache drive does not function in the way you describe.   In unRAID it is effectively a ‘staging’ drive to support a higher speed way of getting data into unRAID.    There have been requests for it to act more like you describe but there has been no indication of whether it is deemed as of enough benefit to justify developing it to work in that manner.

There are, of course, settings that will allow certain files to stay on cache (including cache-no). And since larger SSDs are getting more affordable, it might be nearly as useful to just keep files there that "might" be used frequently.

 

And not moving files to/from cache would be less wear on the disks.