I’m not quite sure what the right way is to respond to posts; If I comment after them, then there’s a chance that the responses might be missed. Anyway I will attempt to go back and check all those comments I’ve not responded to. First, here’s a response to Cedric’s question, on VMware;
What I was referring to was the way in which (a) VMware lays storage out over LUNs, (b) the way storage systems do failover at a LUN level.
For standard arrays which present LUNs, the lowest unit of granularity for TrueCopy/SRDF etc is the LUN. That’s fine for systems that have lots of LUNs and then recombine them at the host level to create volumes. VMware works on a smaller number of larger LUNs (in my experience 50-200GB metas or LUSEs) and then divides this storage across multiple guests. So failover of a LUN could mean failover of a number of hosts. The tradeoff is therefore on how to lay out the storage in order to allow failover to work without affecting multiple hosts and also when additional storage is needed for a host how to present that additional storage.
The issue occurs because SAN storage is presented through the VMware hypervisor. iSCSI LUNs are presented directly to the host and so the original granularity can be retained and iSCSI LUNs can still be replicated. Therefore DR on iSCSI presented LUNs can easily be achieved.
Under the current versions of VMware (and please correct me if I’m wrong) it is possible to boot a guest from an iSCSI LUN and therefore theoretically possible to fail this over to another array. Personally, I’d not do that as I think it would present significant complications to achieve and I’d prefer to just present data LUNs for replication and keep O/S data local.
I hope this clarifies my thinking, feel free to post if you want me to clarify more.