HP Autoloader mount, ESXi 4.1 through SAS – will it work

Please see the notes about configuring an all-in-one ZFS setup in my post at: Hosting a ZFS server as a virtual guest.

If you're talking about creating an SSD pool or adding drives as raw device-mappings (RDM's), disregard the rest of this answer. The preference there would be to run through the HBA versus RDM. Use SAS expanders if needed. The main reasons are easy portability, configuration simplicity (you don't want this or this) and consistency with what you've already configured. The performance impact is negligible. The management overhead isn't.

If you're instead thinking about using VMDK files on disks presented to ESXi, the general answer is that you can go either way. The performance difference probably won't matter. This assumes that the application is adding ZIL log or L2ARC cache devices to your virtualized ZFS system. There are instances where I'll add an SSD to a physical system and add VMDK's on top to present to the NexentaStor VM. Other cases, I may present an entire raw drive to the instance.

I base it on convenience versus performance. If performance were absolutely paramount, we wouldn't be virtualizing the storage, right? The convenience part comes with the flexibility to provide a reasonable performance boost to an existing system without dedicating an entire 100GB+ SSD to ZIL use (which only needs 4GB for my purposes). This leaves room for L2ARC if I'm constrained in some other way.

So my questions would be:

• Is your motherboard's SATA controller supported/recognized by ESXi? Is it 6G?
• What are you doing? ZIL? L2ARC? Both? This matters because L2ARC isn't write heavy and the read performance is going to be a function of your data set and your cache hit-ratio. If ZIL, you want lower-latency writes, and would need to make sure that your device choice isn't going to slow you down.
• Have you examined your read/write profile? arcstat, arcsummary and zilstat will give you some insight into what's possible. It's also a decent way to test this. Try using a VMDK presented by ESXi and identify your bottlenecks under a representative workload.
• What type of SSDs will you be adding? You're talking about SATA, so that immediately excludes the high-end SAS SSD's available. Will you be using 6G SATA SSD's?

You didn't provide the version of CentOS installed as your VMWare guest... but let's assume it's CentOS 6.x.

The default CFQ I/O scheduler is a poor choice for guest virtual machines (and most systems). You'll want to modify it. I used to just recommend setting the scheduler to deadline, but there's an easier method now for RHEL/CentOS systems...

The best way to handle that and a couple of other tunables is to download the tuned framework and apply a better profile to the system.

In your case:

yum install tuned tuned-utils

Once installed, try one of the appropriate profiles. For VM's, I either do enterprise-storage or virtual-guest. Test and see which works best for you. A reboot is NOT required between profile changes.

tuned-adm profile virtual-guest

The reasoning:

Edit:

Well, that's an improvement. Make sure you have the VMWare tools installed in your guest. Other items include filesystem tuning (e.g. noatime) and such... but really, those results should not matter beyond a certain point. A dd test is not representative of realistic usage patterns.

One of the other benchmarking tools like bonnie++ or iozone would be more helpful. Grab them via yum.

As a virtual machine, you need to be concerned with small random reads and writes. That will matter far more than sequential write metrics from your dd test.