P.P.S.: This previously unsupported scenario is now fine with Windows Server “8” Beta and SMB 2.2. See http://blogs.technet.com/b/josebda/archive/2012/03/06/windows-server-quot-8-quot-beta-test-cases-for-hyper-v-over-smb.aspx
P.S.: After writing this blog post, I found that the specific scenario of using Hyper-V VHDs files on a file share is not supported by Microsoft in Windows Server 2008. This is documented at http://technet.microsoft.com/en-us/library/dd183729.aspx. Look for a note that says “Network-attached storage (NAS) is not supported for Hyper-V”.
I previously covered the storage options for Hyper-V and described the many choices between directly attached or SAN storage, fibre channel or iSCSI, passthrough or VHD, Virtual SCSI or Virtual IDE, etc.
If you missed that one, check it out at http://blogs.technet.com/josebda/archive/2008/02/14/storage-options-for-windows-server-2008-s-hyper-v.aspx
However, I failed to mention in that post the option to store your VHD files in a CIFS/SMB file server share.
Here’s an updated diagram with all the different Storage options for Hyper-V, including the DAS, SAN and file server options:
Everyone is quick to remind me that this SMB option would be slower than block storage, if all else is the same.
However, with faster IP networks (including 10Gb Ethernet) and the improvements in the SMB v2 protocol, you might be tempted by the added flexibility in your storage management.
How to do it
Storing your Hyper-V files on a file server is pretty straightforward.
There are, however, a few of things that you need to implement this properly with Hyper-V.
First of all, remember to grant access to the computer account of the computer running Hyper-V.
This is the DOMAIN\COMPUTERNAME$ account, which you can use in the same way you would use a regular user account when granting permissions.
The second thing is that you need to do is use a UNC path when pointing to the file server.
This is a path that looks like \\SERVERNAME\SHARENAME.
Using a mapped drive or mount point does not work with the Hyper-V Manager tool.
Last but not least, you need to do this at the computer running Hyper-V (or connected via Remote Desktop to that computer).
If you try to use the Hyper-V Manager tool remotely, you will get an error message saying “Failed to create external configuration store at ‘\\SERVERNAME\SHARENAME\FOLDERNAME’: General access denied error (0x80070005)”.
You can work around this by using constrained delegation to allow a workstation to work on behalf of the computer running Hyper-V.
For details on that option, check http://blogs.technet.com/josebda/archive/2008/06/27/using-constrained-delegation-to-remotely-manage-a-server-running-hyper-v-that-uses-cifs-smb-file-shares.aspx.
Everyone agrees that, all else being the same, it’s faster to use an iSCSI LUN than an SMBv1 file share for your Hyper-V storage.
There are, however, a few things you can do to improve your network performance for Hyper-V.
First, you can use a separate NIC on the server running Hyper-V for the file server traffic.
This will help isolate the network traffic between the file server and the server running Hyper-V from other network traffic.
To make sure there’s no VM traffic going through this NIC, do not connect it to the Virtual Switch.
You can also use a NIC with a TCP Offload Engine.
These TOE NICs will improve your network performance and handle much of the work without additional burden to the CPU.
This NIC could again be dedicated to the file server traffic.
Last but not least, consider upgrading your Windows file server to Windows Server 2008.
The improved TCP/IP stack and the support for the new SMBv2 will significantly improve your file server performance.
These optimizations will actually work for any kind of TCP/IP traffic (except for the part about SMBv2 protocol enhancements, which are specific to a file server workload).
Step by step instructions
Here are a few instructions on how to do this, based on my test configuration.
I implemented this with two servers, one running Windows Server 2008 Hyper-V (called JOSEBDA-HV2) and another running Windows Server 2008 as a file server (called JOSEBDA-MM1).
The first step was to create a folder on JOSEBDA-MM1 and share it, granting rights to the computer running Hyper-V and to the user running the Hyper-V Manager tool.
Here are the command lines used on JOSEBDA-MM1 to accomplish that:
ICACLS C:\VMSTORE /GRANT DOMAIN\ADMINUSER:(OI)(CI)F /GRANT DOMAIN\JOSEBDA-HV2$:(OI)(CI)F
NET SHARE VMSTORE=C:\VMSTORE /GRANT:DOMAIN\ADMINUSER,FULL /GRANT:DOMAIN\JOSEBDA-HV2$,FULL
The second step was to create the Virtual Machine on the JOSEBDA-HV2 computer, using a UNC path to configure the location of the files used.
In this case, the path was \\JOSEBDA-MM1\VMSTORE.
Here are a few screenshots of the New Virtual Machine Wizard using the file server path.
First, here is where we specify the location of the virtual machine as a UNC path:
Second, we use the UNC path again when specifying the location of the VHD file. The wizard already suggests the right location:
I also used an ISO file located on a file share path. Here’s that screen:
The review screen shows the entire configuration:
And it works… As you can see in the properties of the running VM:
So, I hope you enjoy having yet another storage option for your Hyper-V workload.
I was impressed with the increased performance of SMBv2, but I encourage you to try this out for yourself and draw your own conclusions.
Also keep in mind that you can use this for your VHD files, your ISO files or both.