iscsi boot to netapp

[topspincharlie]

I am testing various ways to load RHEL on servers with no internal hard drives on luns we've created on a netapp using 1) open-iscsi capable nics, 2) ipxe, 3) dracut (RHEL6).

I really want to get ipxe to work since it's not hardware or OS dependent.

After pouring through the documents and threads it looks like iPXE should be straight forward but I am unable to get it to work properly. I believe that my dhcpd.conf file and the netapp set up properly but I am getting the following error on the client:

Could not open SAN device: Input/output error (http://ipxe.org/1d704539)
No more network devices

On the netapp we get a message that says:
ISCSI: New session from initiator iqn.2013-03.com.redhat:test18 at IP addr 10.10.10.2

I have a verified load on lun id 18 within the netapp.

Relevant part dhcpd.conf file:

Code:

allow booting;
allow bootp;
option space ipxe;
option ipxe-encap-opts code 175 = encapsulate ipxe;
option ipxe.priority code 1 = signed integer 8;
option ipxe.keep-san code 8 = unsigned integer 8;
option iscsi-initiator-iqn code 203 = string;
option ipxe.iscsi code 17 = unsigned integer 8;
.
<other ipxe option definitions>

subnet 10.10.10.10 netmask 255.255.255.0 {
}

group pxe {
.
  <subnet/domain/router/etc options>
.
  if exists user-class and option user-class = "iPXE" {
    filename "";
    option root-path "iscsi:10.10.10.1:::18:iqn.1992-08.com.netapp:sn.118061234";
    option iscsi-initiator-iqn "iqn.2013-03.com.redhat:test18";
    option ipxe.keep-san 1;
  } else {
    filename "undionly.kpxe";
  }

We know that the target and OS on the lun is good because we can boot to this lun using the NIC's open-iscli's capabilities.

Any suggestions on what we could do to troubleshoot would be greatly appreciated.

Thanks!
-Charlie

[robinsmidsrod]

Have you actually read what is mentioned on the error URL mentioned to you? It says you should verify ACLs on your iSCSI target. Try to increase debugging on your netapp, so that you can see what ACLs the client is sending, and what the netapp's response is. If you can't do that, the next best option is to do a packet trace and carefully inspect the iSCSI packets to see what is being requested, and what response is coming back. That might actually give you an answer.

If your netapp is set up to use authentication in addition to IQN ACL validation you also need to provide credentials using either the "login" command in an iPXE script, or manually set the username and password variables.

[topspincharlie]

Thank you for responding.

I've read through the URL and several posts of people trying to do similar things (ref http://lists.ipxe.org/pipermail/ipxe-dev...00380.html)

It appears as though everything is set up properly on the netapp and I've transcribed the output of some netapp commands below. We do not use authentication, nor do we use "iscsi interface accesslists".

igroup show
test18 (iSCSI) (ostype: linux):
iqn.2014-03.com.redhat:test18 (not logged in)

lun show
LUN Path Mapped to LUN ID Protocol
/vol/luns/test18_lun test18 18 iSCSI

iscsi nodename
iSCSI target nodename: iqn.1992-08.com.netappn.118061234

What really puzzles me is that it works when booting using the open-iscsi capable nic, which appear to me as having the exact same settings as what I'm using in iPXE.

I'll see if I can get a packet capture to get some more insight as to what's going on, but any additional pointers would be greatly appreciated.

[robinsmidsrod]

The common way to verify if things work is to use an iSCSI client like the Windows Software iSCSI initiator and try to attach your target from it. If you can run that on the same machine that you normally network boot, it's even better. But since you say you don't use any ACLs in your setup, it should work from any computer, as long as it is connected to the same physical network as the iSCSI target server and communication between them is not impaired.

If you test with e.g. the Windows client, you could also try to set the initiator IQN to the one iPXE uses, just to make sure everything is the same (except for the software). If that still doesn't work, and you can't increase debugging on the netapp side, then a packet trace is the only useful option to get some more information on the subject matter.

And just for the record: I'm not at all familiar with NetApp hardware or how they are configured for iSCSI. I'm just responding with knowledge about what I know about iSCSI in general.

[topspincharlie]

After doing a packet capture I saw that iPXE was interpreting the lun ID (The 18 in iscsi:10.10.10.1:::18:iqn.1992-08.com.netapp:sn.118061234) as Hex 0x18. When I changed the value to a 12 (iscsi:10.10.10.1:::12:iqn.1992-08.com.netapp:sn.118061234), I am now able to connect and boot in to the lun.

Thank you for pointing me in the right direction of how to troubleshoot and resolve this issue. After discovering this I went to RFC 4173 and sure enough:

Quote:"iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname>

The "LUN" field is a hexadecimal representation of the LU number. If
the LUN field is blank, then LUN 0 is assumed. If the LUN field is
not blank, the representation MUST be divided into four groups of
four hexadecimal digits, separated by "-". Digits above 9 may be
either lower or upper case. An example of such a representation
would be 4752-3A4F-6b7e-2F99. For the sake of brevity, at most three
leading zero ("0") digits MAY be omitted in any group of hexadecimal
digits. Thus, the "LUN" representation 6734-9-156f-127 is equivalent
to 6734-0009-156f-0127. Furthermore, trailing groups containing only
the "0" digit MAY be omitted along with the preceding "-". So, the
"LUN" representation 4186-9 is equivalent to 4186-0009-0000-0000.
Other concise representations of the LUN field MUST NOT be used.

After reading this I was contemplating making the lun id the mac address, but unfortunately the netapp has a limitation of only being able to use 0-4095.

Thanks again for your assistance.

-Topspin

[robinsmidsrod]

It would be awesome if you added that piece of information to http://ipxe.org/1d704539 so that other people having the error would be able to find it as well. Pointing to this thread would also be acceptable.

[robinsmidsrod]

I actually went ahead and added it to the error page. Feel free to add more detail if you feel it's necessary.

[ArneLovius]

"I was contemplating making the lun id the mac address"

I use the target name for that

[MultimediaMan]

NetApp's OnTap can be frustrating that way. Newer versions of OnTap, I believe do allow "normal" iSCSI LUN names instead of a very long random integer.