It's 'doable', we have some clients running that way. As always, disk and RAM are pretty high on the 'get it right' list, CPU also counts but in my mind, a little less usually.
One of the neater features in recent HyperV releases is the ability to specify a physical disk to appear to the virtual machine as a virtual disk - where I can see a huge practical use for this is where everyone calls for separation of activities on spindles (ie disk #1 for tempdb n sql, disk#2 for SQL data file {and possibly > 1 for multiple file group DB's} , disk #3 for SSAS data {and maybe another for temp files}) - normally when you create virtual machine, you create a VHD , which is a file 'on' the physical drive, and you could of course create just one of these, per drive, on the machine and then make them available to the virtual server, but it's still an abstraction layer - my understanding is that making the disks directly available to the virtual removes that layer. One thing we've seen a lot of (and it's usually people in a hurry) is using the same disk/s to house the virtual HD's as well as the Host OS - this can cause issues beause there's still only the one head writing to the underlying single physical disk - so you will likely see lags/contention.