Ok, so let's get back to your EVA & VMware question and how good they fit.
Like I said and you certainly know: You can easily choose the size of a virtual disk right down to 1 GigaByte granularity. That is not really necessary for a VMFS, because you most likely would keep some free space, e.g. for REDO services, but it is sure handy if you are using RDMs.
It does not matter how large a virtual disk is - the data is always spread over all disks in a disk group. It works the same way for a 100 GByte VMFS, a 1 GByte VMDK or a 1 GByte RDM.
Using a larger VMFS and leaving some free space allows you to roll out new VMDKs rather fast. Sometimes, when reading some threads about problems to recognize a new LUN (not necessarily from an EVA) I really have to shake my head:
do the server and the storage people not work _together_ ?
I think you agree that the EVA is easy to handle through CV-EVA, but you will use it less when you are using large VMFSes. In that case you will more often use VMware ESX server included tools like the MUI or VMKFSTOOLS, no matter what the underlying storage array is.
Interesting, isn't it? This is a bit similar to the argument from vendors of in-band storage virtualization appliances.
Indeed VMware ESX server can move some storage management responsibilities from the "SAN administrator" to the "ESX/server administrator", but both _must_ work together.
There are still some features the EVA has, which are not available in ESX:
- highly redundant storage
-- (not available with local disks)
- CA
- decoupling of the server from "its" storage
-- even better: multiple servers can share the storage
.
