There has been a lot of great feedback to my questions and I have a few more questions:
Would you recommend splitting TempDB into multiples files equal to the number of CPUs, for support of one major database? If so, can someone explain the rational behind this? I am just trying to learn as much as possible
Using multiple cores helps to alleviate contention; that is, you don't have multiple processes waiting for one another (as much) because each can write to a different file. A good rule of thumb is one file per CPU; others might suggest one file per core. For example, my main production server has four quad-core processors; we have four tempdb files, and that seems to have worked out well enough that he haven't bothered changing it. It performs well in our case, and it's very manageable.
Depending on your systems, you might find more or less to be appropriate; the nice thing is that it's relatively easy to change the number of files that tempdb uses.
I liked Shawn's explaination for having multiple drives on a VM "When you have multiple drives assigned to a VM, that is multiple paths being used to access the disk at the other end. So when you go to write data the traffic required against both your data and log file can take multiple paths to those disk, instead of down one, logically speaking". I am wondering if anyone else has anything more to add to why multiples drives on a VM are beneficial for a SQL installl on a VM?
I think he sums it up nicely... you're basically allowing SQL to access the drive on multiple logical paths. Ideally you would have your data and logs (and system, installation, and tempdb) on separate physical drives but even if it's one single lump of drives (or even one drive), having those multiple paths is an advantage.
You might even find it beneficial to separate higher-usage databases to their own additional drives; so using Shawn's example:
1 - System OS
2 - App (SQL Server binaries, root instance directory)
3 - Data files
4 - Log files
5 - tempdb (data and logs)
6 - backups (optimal depending on how backups are done)
7 - Data files (high usage)
8 - Log files (high usage)
On our main server, we have six different sets of data/log drives for various systems. In our case, that is to facilitate our disaster recovery functionality; but it has also given us a noticeable performance improvement.