If you don't plan on using the host OS to run anything but Hyper-V, I don't think putting VMs on the same partition as the OS is going to matter much. I'm using Hyper-V on a couple workstations with 10k rpm disks with the OS on one and VMs on both and I don't notice a difference in VM performance between them.
You can eat up disk very rapidly with VMs, so its worth having a big & slower disk for archives & backups (maybe not necessary if you have good network storage and a fast network).
If you are building it yourself and want to stay within a reasonable budget, I'd suggest 4-6x 10 rpm disks in raid 10 (300 GB disks can be had for ~$200 each on NewEgg). Then maybe 2x 1-2TB disks in raid 1 (if you add this, you might as well put the OS on it).
Using dynamically expanding disks and snapshots both adversely affect performance (for virtualizing a workstation it's fine, for a server maybe not). And for any disk intensive service, I'd use direct access to the service's backing store (e.g., database or file-server). If you move the I/O bottleneck off the virtual OS partition, you can probably snapshot the virtual server OS without worrying about performance.
Finally - you may want more than 8GB (Hyper-V can't share unallocated RAM, and the host needs some, too) - but that depends on how intensely they will be used.
I hope this is useful. And if you do some experimentation and benchmarking, I think many people would be interested to see the results. As you've probably noticed, there is a paucity of performance data in this area.
It looks like Microsoft has "officially" announced support of of TMG on Hyper-V - http://www.microsoft.com/forefront/threat-management-gateway/en/us/default.aspx
As Tatas stated. Just because TMG is on the hypervisor, there is no technical requirement for the hypervisor itself to be exposed. The virtual-to-physical NIC assignments under the hypervisor is the only requirements in placing TMG into a functioning configuration. The hyperisor can stay put based on your "normal" deployment for hypervisors per your environment.
As long as there are no rampant hypervisor exploits, then running TMG and similar products are/should be just as "safe" as it would be on physical hardware.
With that said, there may be some operational advantages to having perimeter-type applications on physical hardware when it comes to addressing and/or responding to out-of-band situations (e.g. network utilization spikes, hypervisor issues, etc.).
Best Answer
I am on the Product Marketing team at Data Robotics, so I'm hoping I can shed some light on the questions around the DroboPro, performance, and virtualization.
Regarding DroboPro performance, there are a few independent reviews that have posted performance numbers. One is GeekBrief.tv and the other is the LA Final Cut Pro User Group.
Here is the LAFCPUG review and the Geekbrief one can easily be found at Geekbrief.tv
http://www.lafcpug.org/reviews/review_drobopro.html
Feel free to check out the full reviews. In terms of iSCSI performance, LAFCPUG used a tool called Blackmagic and saw ~80MB/s read and ~70MB/s write. GeekBrief.tv used a tool called AJA and saw ~74MB/s read and ~79MB/s write. Burst speeds will certainly be higher as darthcoder alluded in his post, but 80MB/s is close to the limit in terms of sustained throughput on a single GbE.
One thing to note in the Geekbrief.tv review is that there was no mention of attaching the DroboPro directly to a switch which is very easy to do by simply assigning a fixed IP via the USB management port prior to attaching the switch. The latest version of our Dashboard management software has support for multi-host and up to 16 x 16TB virtual volumes.
Regarding virtualization, Data Robotics is in the process of certifying the DroboPro with VMware ESX which is the top priority due to market share. Having said that, we will be doing similar certifications with Microsoft Hyper-V and Citrix XenServer once the VMware certification is complete. While we have not yet officially performed testing with Hyper-V or Xenserver, we are aware of several customers that are successfully using Drobo and DroboPro with VMware, Hyper-V, and Xen.
In regards to your question of whether or not DroboPro is fast enough to handle a dozen VHDs all running concurrently, it should work just fine, but it really depends on the workload.
Hope that helps clarify things.