The problem with extents is that if you lose one of those lun's then you are going to lose everything in the entire vmfs volume. Picture 2 seperate RAID Groups of RAID 5 and one of the volumes loses 2 drives for whatever reason (offline or dead drives). You lose your ENTIRE environment, not just the VM's on that particular RAId Group.
It also causes rather major problems when you start trying to remove the extent later..you have to delete the entire volume (not just the added extent).
These 2 options right here are where things usually go bad...someone doesn't realize a volume is in use an poof the entire envirement goes bye bye since removing zoning could cause the entire volume to corrupt, whereas 2 seperate vmfs volumes would mean everything goes down on that volume, you re-zone it back and usually powerup your VM's again (/me speaks from experience here btw)
In ESX 4 they have enabled the ability to GROW a vmfs volume so that extents are not a problem anymore, but even with EMC, if you use metaluns and then grow out your VMFS, I've be worried what would happen if you lost one of the metalun groups...probably wouldn't be pretty.
If you have a raid group thats 1TB in size and a 500GB VMFS volume on it, just create another 500GB VMFS volume. In this case its probably better to violate the 1LUN=1VMFS volume best practice then the extent best practice.
Other things to keep in mind is the number of VM's/VMFS volume. You don't want to try and go much beyond 10-15VM's per VMFS volume so even if you grow the 500GB volume to a 1TB VMFS volume you should not be putting more then a combined 10-15 VM;s on that 1TB VMFS volume, whereas you can put 20-30 VM's on 2x500GB (example numbers only). This is due to scsi reservation issues you can encounter during backups or boot storms
