Mapping LUNs with NetApp FAS throws: “illegal LUN” error

Ran into an interesting error today with a NetApp FAS which I’m sure not a lot of people would but in case someone does, this post serves to show why.

Problem

You’ve created your aggregates, volumes and LUNs and now you would like to configure initiator groups for your ESXi servers so you can map iSCSi targets. However, as soon as you try to map the initiator group to the LUN, you receive the following error:

TruncatedInitiatorGroupName (mapping) : lun map: illegal LUN: “number,number,number”

TruncatedInitiatorGroupName (mapping) : lun map: illegal LUN: “number,number,number”

TruncatedInitiatorGroupName (mapping) : lun map: illegal LUN: “number,number,number”

If you have already noticed, the list of initiator groups looked a little strange at the bottom. So how did this all start? Let’s start from the beginning of how the group was created.

To create the initiator group, I navigating to LUNs –> Initiator Groups –> iSCSI –> Manage and then clicked on Add Initiator Group:

From there on, I created an Initiator Group named: ESXi01,02,03, selected the type to iSCSI, operating system to VMware and added the IQN to the initiators window:

The group successfully gets created:

I continued to the page for managing LUNs and proceed with mapping the initiator group to the LUN:

What’s strange about the following window is that it looks like our initiator group: ESXi01,02,03 appears to be truncated into 3 different groups:

If you continue to add a LUN number and try to map it, you will get the following error message:

TruncatedInitiatorGroupName (mapping) : lun map: illegal LUN: “number,number,number”

TruncatedInitiatorGroupName (mapping) : lun map: illegal LUN: “number,number,number”

TruncatedInitiatorGroupName (mapping) : lun map: illegal LUN: “number,number,number”

If you try to hit apply again, you’ll see the LUN number get repeated:

Solution

The solution here is actually quite simple: Do not use commas in your initiator group’s name. I’m not sure why the FilerView even allowed it so maybe the backend didn’t have anything to catch commas (it catches spaces). Also, if we were to logically think about it, the FilerView actually runs the console commands in the background which would explain why the comma characters threw off the procedures executing the commands.

Re-creating the initiator group with a name that does not have commas fixes the problem:

Definitely a mistake on my part but interesting glitch.