Using a UNC Network Share to Store Hyper-V Virtual Disk (VHD)

    This post has matured and its content may no longer be relevant beyond historical reference. To see the most current information on a given topic, click on the associated category or tag.

    Performance tips when you must resort to SMB 2.0

    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. This works fine with Hyper-V, although everyone is quick to remind me that this 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 DOMAINCOMPUTERNAME$ 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 SERVERNAMESHARENAME. 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 ‘SERVERNAMESHARENAMEFOLDERNAME’: 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.

    Performance tips

    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…

    Read the rest of the article @> Jose Barreto’s Blog : Storing Windows Server 2008 Hyper-V files on a CIFS/SMB file share Need help storing your Hyper-V files on a file server or managing your environment? Please check us out for your Managed Service or Microsoft Consulting needs.