Guidelines for working with FlexVol volumes that contain LUNs
When you work with FlexVol volumes that contain LUNs, you must change the default settings for Snapshot copies. You can also optimize the LUN layout to simplify administration.
Snapshot copies are required for many optional features, such as the SnapMirror feature, SyncMirror feature, dump and restore, and ndmpcopy.
When you create a volume, Data ONTAP automatically performs the following:
• Reserves 5 percent of the space for Snapshot copies
• Schedules Snapshot copies
Because the internal scheduling mechanism for taking Snapshot copies within Data ONTAP does not ensure that the data within a LUN is in a consistent state, you should change these Snapshot copy settings by performing the following tasks:
• Turn off the automatic Snapshot copy schedule.
• Delete all existing Snapshot copies.
• Set the percentage of space reserved for Snapshot copies to zero.
You should use the following guidelines to create volumes that contain LUNs:
• Do not create any LUNs in the system’s root volume.
Data ONTAP uses this volume to administer the storage system. The default root volume is /vol/
vol0.
• You should use a SAN volume to contain the LUN.
• You should ensure that no other files or directories exist in the volume that contains the LUN.
If this is not possible and you are storing LUNs and files in the same volume, you should use a separate qtree to contain the LUNs.
• If multiple hosts share the same volume, you should create a qtree on the volume to store all the LUNs for the same host.
This is a best practice that simplifies LUN administration and tracking.
• To simplify management, you should use naming conventions for LUNs and volumes that reflect their ownership or the way that they are used.
See the Clustered Data ONTAP Physical Storage Management Guide for more information.
Related information
Documentation: By Product Library: support.netapp.com/documentation/productsatoz/index.html
LUN size and type
When you create a LUN, you must specify the LUN size and the type for your host operating system.
The LUN Multiprotocol Type, or operating system type, determines the layout of data on the LUN, and the minimum and maximum sizes of the LUN. After the LUN is created, you cannot modify the LUN host operating system type.
Guidelines for using LUN multiprotocol type
The LUN multiprotocol type, or operating system type, specifies the operating system of the host accessing the LUN. It also determines the layout of data on the LUN, and the minimum and maximum size of the LUN.
Note: Not all Data ONTAP versions support all LUN multiprotocol types. To get the most up-to-date information, you should see the Interoperability Matrix.
The following table describes the LUN multiprotocol type values and the guidelines for using each type:
LUN multiprotocol type When to use
AIX If your host operating system is AIX.
HP-UX If your host operating system is HP-UX.
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.
Note: For raw LUNs, you can use the type of child operating system as the LUN multiprotocol type.
Linux If your host operating system is Linux.
NetWare Your host operating system is NetWare.
OpenVMS If your host operating system is OpenVMS.
Solaris If your host operating system is Solaris and you are not using Solaris EFI labels.
LUN multiprotocol type When to use
Solaris EFI If you are using Solaris EFI labels.
Note: Using any other LUN multiprotocol type with Solaris EFI labels might result in LUN misalignment problems.
For more information, see the Solaris Host Utilities documentation and release notes.
VMware If you are using ESX Server and your LUNs will be
configured with VMFS.
Note: If you configure the LUNs with RDM, you can use the guest operating system as the LUN multiprotocol type.
Windows 2003 MBR If your host operating system is Windows Server 2003 using the MBR partitioning method.
Windows 2003 GPT If you want to use the GPT partitioning method and your host is capable of using it. Windows Server 2003, Service Pack 1 and later are capable of using the GPT partitioning method, and all 64-bit versions of Windows support it.
Windows 2008 or later If your host operating system is Windows Server 2008 or later; both MBR and GPT partitioning methods are supported.
Xen If you are using Xen and your LUNs will be configured with
Linux LVM with Dom0.
Note: For raw LUNs, you can use the type of guest operating system as the LUN multiprotocol type.
Related information
Interoperability Matrix: support.netapp.com/NOW/products/interoperability
LUN clones
LUN clones are writable, space-efficient clones of parent LUNs. Creating LUN clones is highly space-efficient and time-efficient because the cloning operation does not involve physically copying any data. Clones aid in space storage utilization of the physical aggregate space.
You can clone a complete LUN without the need of a backing Snapshot copy in a SAN environment.
The cloning operation is instantaneous and clients that are accessing the parent LUN do not experience any disruption or outage. Clients can perform all normal LUN operations on both parent entities and clone entities. Clients have immediate read-write access to both the parent and cloned LUN.
Clones share the data blocks of their parent LUNs and occupy negligible storage space until clients write new data either to the parent LUN, or to the clone. By default, the LUN clone inherits the
space-reserved attribute of the parent LUN. For example, if the parent LUN is thinly provisioned, the LUN clone is also thinly provisioned.
Note: When you clone a LUN, you must ensure that the volume has enough space to contain the LUN clone.
Resizing a LUN
You can resize a LUN to be bigger or smaller than its original size. When you resize a LUN, you have to perform the steps on the host side that are recommended for the host type and the application that is using the LUN.
Initiator hosts
Initiator hosts can access the LUNs mapped to them. When you map a LUN on a storage system to the igroup, you grant all the initiators in that group access to that LUN. If a host is not a member of an igroup that is mapped to a LUN, that host does not have access to the LUN.
Guidelines for mapping LUNs to igroups
There are several important guidelines that you must follow when mapping LUNs to an igroup.
• You can map a LUN only once to an igroup.
• You can map a LUN only once to a specific initiator through the igroup.
• You can add a single initiator to multiple igroups, but the initiator can be mapped to a LUN only once. You cannot map a LUN to multiple igroups that contain the same initiator.
• You cannot use the same LUN ID for two LUNs mapped to the same igroup.
• You should use the same protocol type for igroups and port sets.
VMware RDM
When you perform raw device mapping (RDM) on VMware, the operating system type of the LUN must be the operating system type of the guest operating system.
What igroups are
Initiator groups (igroups) are tables of FC protocol host WWPNs or iSCSI host node names. You can define igroups and map them to LUNs to control which initiators have access to LUNs.
Typically, you want all of the host’s HBAs or software initiators to have access to a LUN. If you are using multipathing software or have clustered hosts, each HBA or software initiator of each clustered host needs redundant paths to the same LUN.
You can create igroups that specify which initiators have access to the LUNs either before or after you create LUNs, but you must create igroups before you can map a LUN to an igroup.
Initiator groups can have multiple initiators, and multiple igroups can have the same initiator.
However, you cannot map a LUN to multiple igroups that have the same initiator.
Note: An initiator cannot be a member of igroups of differing ostypes.
Required information for creating igroups
There are a number of attributes required when creating igroups, including the name of the igroup, type of igroup, ostype, iSCSI node name for iSCSI igroups, and WWPN for FCP igroups.
igroup name
The igroup name is a case-sensitive name that must satisfy several requirements.
The igroup name:
• Contains 1 to 96 characters. Spaces are not allowed.
• Can contain the letters A through Z, a through z, numbers 0 through 9, hyphen (“-”), underscore (“_”), colon (“:”), and period (“.”).
• Must start with a letter or number.
The name you assign to an igroup is independent of the name of the host that is used by the host operating system, host files, or Domain Name Service (DNS). If you name an igroup aix1, for example, it is not mapped to the actual IP host name (DNS name) of the host.
Note: You might find it useful to provide meaningful names for igroups, ones that describe the hosts that can access the LUNs mapped to them.
igroup type
The igroup type can be mixed type, iSCSI, or FC/FCoE.
igroup ostype
The ostype indicates the type of host operating system used by all of the initiators in the igroup. All initiators in an igroup must be of the same ostype. The ostypes of initiators are solaris, windows, hpux, aix, netware, xen, hyper_v, vmware, and linux.
You must select an ostype for the igroup.
How to limit LUN access in a virtualized environment
You can limit access to your LUNs through igroups and port sets. Until you map LUNs to an igroup, you cannot access your LUNs. You use port sets to limit which LIFs an initiator can use to access your LUNs.
A port set is a collection of LIFs. If you do not bind those igroups to a port set, any initiator within an igroup can access any LUN mapped to that igroup through any LIF.
The way an initiator connects to a LUN is through an igroup. In the following example, initiator1 can access LUN1 through LIF1 and LIF2. Without a port set, initiator1 can access LUN1 over any LIF.
initiator1 igroup1 LUN1
LIF1 LIF2 initiator1
You can limit access to a LUN by binding igroups to port sets. In the following example, initiator1 can access LUN1 through LIF1. However, initiator1 cannot access LUN1 through LIF2 because LIF2 is not in portset1.
initiator1 portset1 igroup1 LUN1
LIF1 LIF1
LIF2 initiator1