I am in the process of creating a Hyper-V 2012 R2 Cluster. I have 3 physical hosts (128GB RAM , dual Hex-core and 12 NICs each) and a SAN to play with. The SAN is a Virtual Storage system (Datacore), serves its virtual disks through iSCSI and I have the ability to create as many virtual disks (i.e. LUNS) as I require (and that I have capacity for !). We have used the Datacore SAN successfully for several years with an ESX cluster, but we are moving to Hyper-V due to licensing costs and the fact that is now offering features on par with what we currently use with ESX (we have also run a a couple of standalone Hyper-V servers for some years as a backup, so are so familiar with that technology too).

So this question is specifically about mixing clustering roles in 2012 R2

I have already created the Hyper-V cluster which use CSVs ( to store VM files) on several iSCSI LUNs from the SAN that all the hosts can see, but my next step is to configure some Highly available File Servers for general user use. I should point out that I do know the difference between using CSVs which are active-active and principally designed for application use (like Hyper-V) as opposed to shared storage as used by a file server cluster which is active-passive and I don't propose to do anything different from that: however there are a couple of different ways I could implement file servers.

  1. The 1st main way I could do this is create a 'guest cluster' - that is 2 VMs as the cluster file server nodes (on different hosts). Their OS volumes would obviously be separate, however there are 2 ways I could get them to share their file storage volumes (i.e. where the shares reside)

    a. They both share a common VHDX that obviously resides on the Hyper-V CSV

    b. Or they use their iSCSI initiators and directly access a dedicated LUN on the SAN

  2. The 2nd way is to not use Hyper-V at all for the File server nodes, but create a File server ( general Purpose) role (alongside the Hyper-V role) on the same hosts in the cluster : these would then access the shared storage on dedicated (non-CSV) LUNs presented by the SAN.

What are the pitfalls of each ? My feeling is that the second option actually has less overhead ( no Virtual layer and no VM required), but it does mean the hosts in the cluster are providing both a Clustered Hyper-V and a Clustered File Server service at the same time - is that going to be an issue ? I also think I could even leverage in some crude load-balancing, by splitting my File shares across 3 File Server roles on the cluster each set to principally run on one node ( when all is working !), and each using separate LUNS.

I appreciate the answer will rely on just how many VMs and such like that I plan to run, but just assume I will keep an eye on resources ( e.g. making sure the VMs don't take up all the host RAM) and I manage the NIC allocation properly so there are no bandwidth issues.

Is there any technical reason, at all, why I can't do option 2 ? Many thanks !

  • Are you trying to store your VM's on this file server? Or are you trying to create a general purpose file server for user file?
    – longneck
    Feb 24, 2015 at 14:40
  • 3
    IMO, I wouldn't add the File Serer role to the Hyper-V hosts. The Hyper-V hosts should perform only that role. Use VM's for the file servers. As for how, have you considered DFS as an option?
    – joeqwerty
    Feb 24, 2015 at 15:17
  • longneck - as stated the VM files are on dedicated LUNs using CSVs. The file server are for general purpose user shares.
    – Steve
    Feb 24, 2015 at 15:56
  • joequerty - Can you clarify your reasons why not please ? As far as I am aware there are plenty of host resources to do both and in fact I have been running single Hyper-V servers with user file shares for some years without issue - my question pertains to clustering.
    – Steve
    Feb 24, 2015 at 15:59
  • 1
    I agree with joeqwerty re: dedicating VMs served by the cluster to host file shares - generally it is more advisable to keep such services to failover-capable machines, rather than on the VM hosts themselves (which only complicates matters, say if one VM host goes down perhaps for maintenance or something more unplanned).
    – BE77Y
    Feb 24, 2015 at 18:22

2 Answers 2


There is no problem running a File Server role on Hyper-V hosts. In general, mixing other roles with Hyper-V is not a good thing. However, the File Server role has been specifically designed and tested to run alongside Hyper-V. One thing I suggest doing is using Windows 2012 R2's QoS features to carve out network capacity for your Hyper-V role vs. your File Server role.

I would not create multiple VM's just to make a clustered file server. If you need that level of complexity for business reasons, then the business should pay for dedicated hardware to created a clustered file server. Failover times on the File Server role will be faster than running a cluster in a guest.

  • Thanks Longneck, that exactly my thoughts too: creating a clustered VM seemed to me to be introducing an unnecessary layer - but was just wanting the re-assurance that I hadn't missed anything. I know some folk say I shouldn't run both Hyper-V & File Server roles on same server, however the File Server role has to be installed for Hyper-V anyway - and as you say it has been tested to run with it. However I shouldn't have to worry about QoS though - there are 12 NICs and I plan to dedicated a teamed pair purely for file shares
    – Steve
    Feb 25, 2015 at 14:22

Personally, I wouldn't do either. Microsoft best practice is to only have the Hyper-V role installed on the host servers, and I don't fully understand what you are trying to gain by having two VMS pointing to the same share on the SAN.

Your best bet is to put the file server as a VM on the cluster. Having it on the cluster will provide high-availability, but if you want a redundant VM I would then set up a second file-share on the cluster (or ideally on a different cluster) and enable DFS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .