If you spend some time on storage startup websites, no matter whether they are providing Flash storage, converged storage/computing, or VM aware storage, you will find that all of them seem to find VDI as a low hanging fruit. They all have a dedicated description of how they can supply great VDI storage solution.
Hyper-V requires NAS to be SMB 3.0 capable to host Hyper-V VM files. This is reasonable, given that SMB 3.0 provides both the speed and reliability that SMB 2.X cannot.
But while Microsoft Hyper-V 2012 imposes the requirement of the NAS being SMB 3.0 capable, customer requirements often impose an additional requirement of the NAS also being SMB 2.X capable. And some other requirements as well, as we shall shortly see.
This is because many customers often use Hyper-V to run VDI VMs. If these VMs run Microsoft Windows 7, the VMs are only SMB 2 capable. Further, a typical use of VDI VMs is to redirect all logged in user home directories to a NAS share. This is where the Microsoft Excel, Word, and PowerPoint files generated by the VDI VM users are stored.
And the customer will always ask “I just bought a NAS to store my Hyper-V VMs. Why can the same NAS also offer a share for the user home directories?”. And that is where comes in the requirement that not only should the Hyper-V capable SMB 3.0 NAS not only offer SMB 2.X support, but also a richer support in terms of supporting oplocks and byte range locks and other such features used by Microsoft Office, but not by Hyper-V.
This is why a particular company, in which I have an interest www.HvNAS.com has implemented both SMB 2 and SMB 3, and regularly tests that its protocol stack implements the full range of SMB 2 and SMB 3 features, especially so all SMB features regularly exercised by Microsoft Office.
winntfs 