What is the correct iGroup type for Hyper-V 2012 server LUN's?

[#1]

Hello Good People,

Today i started using the new SnapDrive Version 7 on our Hyper-V 2012 server with DataONTAP 8.0 7-mode and while creating a SnapInfo LUN from the SnapDrive GUI, I let SnapDrive automatically create the iGroup for me and notices it created an iGroup type of "windows" but a LUN type of "Hyper-V". I found the below documentation whcih states this could lead to problems with alignment and would now appreciate if anyone could clarify and let me know any problems i would face have a mix for iGroup / LUN types as we have many of these now i check.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ostype (LUN multiprotocol type) guidelines

The ostype (sometimes called LUN multiprotocol type) specifies the OS of the host accessing the LUN. It also determines the layout of data on the LUN, the geometry used to access that data, and the minimum and maximum size of the LUN.

Not all Data ONTAP versions support all LUN multiprotocol types. You should consult the Interoperability Matrix to get the most up-to-date information. The ostype (LUN multiprotocol type) options and when each should be used are listed below:

Note: If you are using SnapDrive for Windows, the LUN multiprotocol type is automatically set.

hyper_v Use if you are using Windows Server 2008 or Windows Server 2012 Hyper-V and your LUNs contain virtual hard disks (VHDs). If you are using hyper_v for your LUN type, you should also use hyper_v for your igroup os type.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here is the source which has more info on the other igroup types also:

https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-7D4DD6E3-DB77-4671-BDA2-E393002E9EB2.html

Any help would be greatly appreciated.

~ Jason

[#2 · Accepted solution]

Hi Jason,

The LUN OS type can impact various attributes such as the LUN disk geometry (sectors, tracks, heads, etc) and if any prefix/suffix should be applied [to compensate for a default misaligned host partition].  In the case of OS types hyper_v and windows_2008 these are identical, so you have no risk of alignment issues.

The igroup OS type can impact the SCSI command support, plug-in integration, error handling, etc.  It basically allows Data ONTAP to optimize communication for a specific host type.  From a Data ONTAP perspective I am not aware of any difference in feature support between windows and hyper_v.  But, if memory serves me, the OnCommand plugin for Microsoft has some cmdlets related to VM management that will fail if the initiator type is not set to hyper_v.  So, since an initiator cannot be in igroups of different types, I would standardize on hyper_v OS type (even if a given LUN is used by the parent) for Hyper-V hosts.

Hope that helps!

Chris Madden
Storage Architect, NetApp EMEA

[#3]

Thanks Chris. This defiantly helps a great deal!

It does however lead me into a new question with SnapDrive 7.0 creating the iGroups for a standalone Hyper-V host versus a clustered Hyper-V host. I basically let SnapDrive GUI automatically create the iGroups for me and found a difference between to two:

Non Clustered Server 2012 Hyper-V    = iGroup type of "Windows"

Clustered Server 2012 Hyper-V           = iGroup type of "Hyper-V"

As we currently have a mismatch of iGroup / LUN types, we are trying to utilize SnapDrive to provide a standard for us going forward as we have had many alignment issues in the past. Ideally we would have all clustered Hyper-V 2012 nodes in the future but for the moment we need to create standalone Hyper-V servers so will need to test the OnCommand plugin for Microsoft cmdlets related to VM management.

Again, thank you very much for the good information.

~ Jason

[#4]

Mystery solved for the iGroup type variance for a Non-Clustered and Clustered Hyper-V Node thanks to a good friend. All our Hyper-V v3 servers boot from SAN and have an exiting iGroup with a type of windows. What my NetApp friend has told me is that

"if a host has a LUN mapped to it and igroup is windows, if we then map another LUN for VHDs we will allow it to be windows as well.  But, if we had no luns mapped and the first one was for VHDs we would set it to be hyper_v."

This is certainly the case in our situation. It was interesting SnapDrive 7.0 was smart enough to realize the difference with a Clustered Hyper-V node but not a non-clustered Hyper-V server and will need to be mindful of this going forward.

~ Jason