First the current version of SRM does not support a single VC use case so if the customer won't budge on that one then you cannout currently use SRM. there are many downsides in DR terms from using a single VC, hence reason why SRM architecture utilizes two.
When you have two VC's SRM can work active / active and by that i mean you can have two production datacenters each replicating to the other each acting as DR for the other in the event of a site loss. SRM supports this configuration.
In my experience VMotion between sites with the current VC25/ESX35 suite does not ever really give you much in terms of use case since it is only really an option for customers who's DC's are close together and even then all you end up with is a VM running at one site that is accessing its virtual disks at the other site, not that desireable. Other point here is that to make this work means you also have to have SAN zones that allow luns to be accessed across sites and also potentially across security boundaries.
Granted I can see some obsucre use cases for wanting to be able to vmotion a VM across site but nothing that really makes it worthwhile architecting this right now, ok one day you might want to vmotion everything across to the other site whilst you perform some hugh hardware upgrade but there are other ways round this with storage vmotion that still give you no downtime.. Going forward there are other things coming that will make vmotion over distance, tighter integration with storage replication more worthwhile.
Where you are right now i think the most important thing to establish is what does your customer really want, is it simply a solution that lets them run two production DC's so they don't have kit standing idle at one location? if yes then SRM can do this for them now in an active / active setup.I find a lot of customes think they need cross site vmotion without really thinking it through and without thinking about the implications for things like vCenter design, point such as:
VC Inventory / Layout, be careful with the design, as everything is stretched you need to be very consistent and accurate with naming conventions across all inventroy objects the VM's will use
DRS/HA settings, ensure that you know which VM's are important and define the correct settings per VM for recovery. Unless you have N+1 capacity spare at each site you will need to put in place HA/DRS settings that bring online the most important VM's first and dont end up in a failure situation with all your dev/test VM's online and half the production VM's "down" because you did not set correct priorities in HA. In SRM this is something the recovery plan handles and you can control.
Split Brain, if you run the two sites as one big HA/DRS cluster ensure you test out the various failure scenarios, for example if DRS (or manual VMotion) moves a bunch of VM's from site1 to site2 but no failure as occurred at that time you now end up with VM's CPU/Memory/Network contexts running on hosts at Site2 but accessing their VMDK's on site1. This will work but is not always desireable from a latency point of view (might be none-issue if bandwidth sufficient) however what happens next if you now suffer disk outage at Site1, at this point the VM's will not crash immediately at Site2 and it will take HA sometime to realise these VM's have an issue. Try it and see, if you disconnect storage from a VM the VM will cling on to life (assuming IO pattern is normal) for quite sometime before a bluescreen is seen.
Storage Presentation, if your customer wants the zone across the sites to effectively be "open" to all ESX hosts then ensure you understand the implications of the ESX LVM settings with regards snapshot / disk resignature. You potentially will have ESX hosts that could at some point access both a source and target lun at the same time if someone or something altered the LVM defaults. As we discussed earlier, with SRM architectures this is handled by SRM as in the SRM archtiecture you would not have this kind of open zone.
Zoning, if the vsan / zones are truly open or all hosts in same then certain fabric events can be a potential pain. Any rogue events such RSCN will disrupt both sites at the same time if all ESX hosts are on same open fabric so be careful here. Not something that is too common but i have seen it hurt a few customers, usually comes down to bad HBA or cables but can be a real pain to track down.
VC / ESX limits, as you build the design out for campus cluster ensure the design wont have you quickly reaching the limits of what it supported in terms of things like max number of VMs/VC, max number of luns/ESX host, max number paths/lun/ESX host etc.
