Why Does Microsoft Hyper-V Not Support NFS?

I recently wrote an article covering storage for virtualisation and was surprised to find out that Microsoft does not support the use of NFS shares with Hyper-V. At first I thought perhaps I was doing something wrong and that my configuration was in error. But after a lot of lab testing and eventually finding some obscure forum posts, I’ve concluded that NFS cannot be used for storing Hyper-V guests. But why?

Client for NFS

Microsoft has supported an NFS server and client within Windows for some time. In Windows Server 2008, the Client for NFS can be added through the “Services for Network File System” role. This creates a new MMC plugin on the start menu that allows administration of both Client and Server services for NFS. From that point on there’s not much to configure in the GUI and all NFS shares are mapped via the command line, or within WMI for Windows Server 2008 R2 (look for future posts describing NFS installation and configuration).

Hyper-V Fail

Any attempts to create Hyper-V guests fail with the error code shown in the screenshot attached. I’ve tried lots of options; pre-creating the VHD, importing the guest and so on, however all fail to allow a VHD to be created. Where does this leave me? Well, I can fall back to standard block-based Fibre Channel and iSCSI LUNs but this is potentially limiting if I’m looking to be more efficient with my Hyper-V installation. SCVMM 2012 for instance assumes I’m storing VMs on an entire single LUN as it uses LUN snapshots to replicate virtual machines. To make this kind of configuration work best, I’d need a storage system that does LUN level thin provisioning; this escalates my costs somewhat.

The Architect’s View

So the question is, why would Microsoft put in such a restriction? It’s not as if network share-based guests are totally banned as I can use CIFS to store them. Of course I wouldn’t want to do that because CIFS has some severe performance and integrity limitations that make it unsuitable. Perhaps it’s just that Microsoft still don’t “get” storage. After all, the latest recommendations for Exchange 2010 are to use DAS. Redmond needs to embrace the use of storage agnostic connectivity for Hyper-V; it’s these kind of features that keep VMware ahead and for many will make ESXi a preferred option.

Comments are always welcome; please read our Comments Policy first. If you have any related links of interest, please feel free to add them as a comment for consideration.