Hey Ravi1987
Wello first off as far as your windows partitioning idea goes its never a bad idea to break out seperate VMDK's for seperate drives in windows for different functions. A good example of this would be a SQL server. I would have a minimum of 3 drives for a SQL server. C:\ Drive(First VMDK) E:\DATA - All Databases reside here(2nd VMDK on a different SCSI controller - Paravirtual for performance) F:\LOGS (3rd VMDK on the same SCSI paravirtual controller for performance) This allows your to grow your database drive or log file at ease whenever you want. With that said as of Window Server 2008+ you can now live extend the C: drive so this limitation has been removed. However like you said if you have 4 partitions on your C: drive you can't extend first 3, you would only be able to extend the last partition so its always a good idea to break partitions out into other VMDK's. So so far so good!
When it comes to your Datastores it comes down to how you want to manage them. This also comes down to the fabric weather its 1GB iSCSI, 10GB iSCSI, or Fibre. If its 1GB iSCSI its usally a good idea to keep around 5-7 Vm's per datastore or at least that used to be the general idea to keep IO storms down on your iSCSI san / paths, however recent optionzations may have changed this. With 10GB iSCSI or Fibre as long as your not destroying your SAN or LUN with to many IO's you can use your descression on how many VM's you want to put on a LUN now. Its not uncommon to see 10+ VM's on a lun with 10GB iSCSI or Fibre now a days as long as those 10 VM's are not SQL,Exchange, Orcale, SAP or aother high IO boxes. The last thing you have to consider is the max LUN number and the MAX paths numbers of ESXi 5.x. Most people never hit these thresholds but in one enviroment I worked on the large number of luns with the large number of paths per lun was reaching the path limits. Which I belive sits at 1024, you can check the documentation on this. If you enviroment is not large you do not have to worry about this, but its something to consider when breaking out MANY datastores down the line.
When it comes down to replication its typical that the SAN will replicate teh Volumes/LUNS which means if you have 5 Vm's in a lun all 5 have to replicated at the same time and or recovered. If you are using SRM as your failover you can create consistancy groups / protection groups for this however all VM's in a LUN do need to be protected. So if you do decide to build fewer datstores and put 5VM's per datastore think logically on how you would like to replicate them and which groups of VM's you want to replicate/restore together. One other thing to warn you about is if you do break out 1 datastore per VM for replication/DR purposes becarful as it becomes a slipperly slop operation wise then as people look at your SRM/DR design as a backup instead of a DR procedure. You don't want to be failing over VM's back and forth all the time becuase people know you can / think its a secondary backup. You typically would probably only want to flip that switch WHEN it is required. Just some food for thought
Typically in most enviroments that I see people isolate dedicated Datastores for thier BIG VM's , Exchange, SQL, ect, then bulk 5-7VM's per Datastore depending on what the datastore can handle. You can also use ESXTOP or vCenter metrics to messure some of your SAN performance metrics if you think a LUN /Datastore is getting over worked. I perfer ESXTOP as it I find it more accurate and easier to read, but to each their own.
I hope this has helped,
