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.
Best Answer
Put the host OS on a partition on the standard HD. Leave some space on the standard HD for VM overflow... even if you can fit all of the VMs on the SSD right now, you need to expect some growth.
Then put as much of the VM's as you can on the SSD. This may mean using multiple VHD's per VM, to separate the VM OS from the application hosted on that OS. If you have some applications that lend themselves to this, begin this process now, even if you can fit the whole VM on the SSD. It will make it easier to move later.