2013-06-23 05:51 PM
I upgraded our FAS2240-2 filer on the weekend to Ontap 8.2. Everything went ok. I was hoping to use SMB 3.0 to store our Hyper-V VMs for out Windows 2012 hosts. I can't seem to create any VMs on the new shares that I set up though. I have CIFS connected to my domain and can browse and create files in any new shares I make. I have given all the Hyper-V machine accounts full access to the share. I have tried Unix, NTFS and Mixed permissions on the volumes and shares.
When I just try and make a new VHD on the share I get this error:
New-VHD : Failed to create the virtual hard disk.
The system failed to create '\\obethree\vol_HyperV01\test\test.vhd': The request is not supported. (0x80070032).
'': The filename '\\obethree\vol_HyperV01\test\test.vhd' is reserved for use by Windows. Error: 'The request is not
supported.' (0x80070032). (Virtual Machine ID )
The operation is not supported.
I created a GPO that enabled the HyperV machines to 'Manage auditing and security log' and applied it to the computer accounts for the filer in the domain.
If I try this on a share created on a Windows 2012 server, it works fine.
Interestingly, when I look at 'options' on the filer, I don't see any reference to SMB 3:
obethree> options cifs.smb
cifs.smb2_1.branch_cache.hash_time_out 3600 (value might be overwritten in takeover)
So have I not enable SMB 3.0 just by installing Ontap 8.2 or is this some sort of permissions issue?
Solved! SEE THE SOLUTION
2013-07-25 11:13 PM
Where I can find the document that about SMB 3.0 support only Cluster Ontap 8.2?
Or which document will decribe that?
I need the document to give my customer,
2013-07-25 11:35 PM
Yes, those sources would work.
If you need a nice presentation to show the customer, look for "Windows File Services in Clustered Data ONTAP 8.2-Customer Presentation" on the NetApp Field Portal.
2014-01-27 11:53 AM
What do you suggest for customers who are using 7-mode and want to use SMB 3.0 shares to host Hyper-v VMs? Is it appropriate to create a Windows Server 2012 R2 scale-out file server cluster backed by CSV attached to the filer(s)? Is that going to offer poor performance because of all the I/O stacks it's having to traverse?