Do you need a D drive in a virtualized environment?

I think it is an interesting question…  If I were to build a generic Windows 2003 or Windows 2008 server today (forget SQL or Exchange – think infrastructure [DCs, DHCP, DNS]), would I need a D drive? Let’s assume for the sake of this post that the environment is a pretty standard virtualization environment.  The virtual machines reside on some sort of shared storage that is configured in a uniform RAID configuration and formatted as a VMFS Datastore. If we were to create separate VMDKs, for the C drive and D drive and place them on the same VMFS, what benefits would we get from the additional D drive?  In these types of situations, I have been leaning towards recommending a single logical drive implementation but here is a list of the PROs and CONs as I see them.

PROs to a single C drive server:

1. Easier for the Administrators to manage.  When installing applications and services, everything is installed in the C drive.  All components and data reside on the single drive.  We no longer are annoyed by poorly written application installers that insist on writing parts of their program to the system drive.
2. More efficient space utilization.  With a Single drive implementation, you only need to worry and plan for growth on a single drive.  You do not need to allocate free space for both the boot and data drive.

PROs to having a D drive:

1. VMDK Backups.  You can easily backup or replicate just the data VMDK in this scenario.
2. Performance scalability.  In the event of IO bottlenecks, you still have the option of moving data VMDKs to faster LUNs or changing spindle configurations.
3. Legacy management.  If a large portion of your existing servers already have C & D drives (coming from a physical world), you might have macros, scripts and other automation pieces that you don’t want to rework.
4. UPDATE: For a vSphere environment, check out the PVSCSI Driver!

Non Factors:

1. Performance.  In this simplified environment, there is no noticeable difference in spindle counts or I/O since all VMDKs would reside in the same VMFS on the same LUN.
2. Recoverability.  In the event that the system becomes ‘unbootable’, it is a trivial task to attach the drive to a healthy VM and repair or access the needed data.
3. Host based Agent Backups.  You can easily exclude Windows or System files from the backup routine and just backup the data.
4. Growth.  A system drive is just a easily expanded as a data drive in a virtual environment.
5. Security.  With NTFS on both system drives and data drives, security can be configured appropriately for either environment scenario.