Hi Thomas,

this quote, "High Performance. Optimized for virtual machine I/O. Store and access
the entire virtual machine state efficiently from a centralized location with
virtual disk performance close to native SCSI." is taken from this document: http://www.vmware.com/files/pdf/key_features_vsphere.pdf

After having struggled to get more than 5 concurrent users of a data-intensive application on a VMWare server hitting a sql server in another vmware server, the lightbulb lit up.

Now, I've also seen an almost-as-big application run on ESX3.5 against a fiber-channel SAN with 50 users before it slowed down.

It turns out that VSphere wasn't the reason for things working better; but the reason was announced by VMWare with the literature. The reason it works, that it gets "close to native SCSI" performance is that a) it's basically a bare-metal hypervisor, although ESX carries along Linux for management; and the use of VMFS, which against a fast SAN provides the close to native SCSI performance, with the failover benefits of clustering.

Having tested ESX without a fast SAN, I can report that the results were disappointing. Having tested ESX using the regular VMWare file system, I can report to you that the results were terrible.

Hank

>Hank,
>
>>A related story to this is the VMWare admission, in their promo materials for VSphere, that VMWare Server on its own is not appropriate for 'data intensive' applications,
>
>Can you point me to the source ?
>www.vmware.com/files/pdf/key_features_vsphere.pdf
>especially mentions running "even the most data intensive production applications such as databases"
>and
>www.vmware.com/pdf/Perf_Best_Practices_vSphere4.0.pdf
>mentioning "Meta-data-intensive operations can impact virtual machine I/O performance"
>IMHO is speaking of VM-meta data, not db meta data like xCase.
>
>tia
>
>thomas