EMC & HP Storage Pooling & SQL Server - Does anyone have experience with this?

We are looking to implement a new SAN, either an EMC CX400 or an HP EVA 6400. In either case we are considering a storage pool technology. EMC calls it virtual provisioning and I believe HP calls it storage pooling. Essentially you have one or two large pools of drives and from there your SQL Server installations are presented logical chunks of disk. It's even possible to have multiple arrays on the same drives. In HPs proposal we will have a pool of (58) 146GB drives. We can then present them to SQL Server as one drive letter or multiple drive letters.
We are still trying to understand how this technology works. It clashes with the old practice of keeping your logs, data and tempdb on separate arrays in order to minimize seek time.
We would love to hear from people who are using this technology. How well does it work for you? How big is your storage pool and did you carve it up into logical drive letters? Do you still use Perfmon to monitor disk performance? What problems does this present?
Thanks, Dave

I am curious as if to you got any more information regarding this issue. I have a SQL2005 hpEVA install coming up and I have been scouring the internet for information regarding Data,log,tempdb placement in light of the vdisk,diskgroup dynamic that occurs in these virtual arrays. Essentially since I cannot discern the physical drives that are involved in the vdisks, the only way I can see to set this up right now is using a single disk group to maximize spindles avaiable to the vraid and then establishing 2 vdisksvdisk1 for vraid1 - logs,temdb,vdisk2 for vraid5 - data. however as I understand it these will be the only 2 drives exposed to the OS , therefore I am essentially putting the logs and tempdb on say E:, and the data on D: and then of course the binaries to the local C:. As of right now I don't see any inherent reason to create additional vdisks for file partitions for SQL server nor even to create an additional vdisk for tempdb. Not a great deal of documentation out there either as this type of logic flies in the face of traditional hitachi sans.