The Chipset, CPU, and LSI2008 controller are all on the HCL

I think in particular the 2MB cluster size weakened it a bit for my small I/O tests, and its iozone results weren’t too out of whack vs the competition. I’m not versed enough in VMFS to talk in detail about its journaling, or barriers, inode tables, or anything else that might impact performance, but I wouldn’t be surprised at all if they’ve tuned their system to work well with SAN and systems with large amounts of cache. After all, they probably don’t have a lot of large customers using local storage.

I’ll have to dig up some other individuals’ tests, really I’m interested more in comparing the visualization technologies to native; seeing the overhead, and in that sense this post isn’t fair because I didn’t test the VMFS volume against the native ESX host (is that even possible?). /proc/sys/vm settings can make a big difference, as well as driver versions, and a host of other things, so it’s probably not right to compare the ESX guest to the Linux host and call that overhead.

Anyway, good to hear from you.

Is the hardware you used on VMware’s HCL? Curious results because of how much VMware touted the improvement of i/o throughput in version 4. Would be curious to see the same comparison running through FC and SAN.

Will it be possible for you to send me the original Blender files?
There are some changes I’d like to make to them for my presentation.

Thank you again for this great page, and your site as a whole. very helpful!!

-Ronny

From what I’ve seen, the best preparation is to create a VM and have a friend break it in several ways. The last part of the book I mentioned has practice exams and gives a few good pointers on this, for example adding a typo to the grub.conf so the system won’t boot.