Problems creating LUNs with SDU on Solaris 10 -- sg module?

[hernancaputi]

Hi all,

This is Hernan from Argentina. I am having the following problem. I cannot create LUNs or access the storage using SDU on Solaris 10 (I do not know the release...). As I have read the problem might be that the sg drivers are not loaded on the Solaris 10....may be that is a reason of the failure... could you confirm that?

This are the error messages....this is a FC connection on a 3160A:

ERROR #1

----------------

snapdrive storage create -filervol 10.200.1.66:/vol/vol1  -lunsize 50.0m -fs /mnt -fstype UFS -nolvm

Do you want to create storage based on this configuration{y,  n}[y]?: y

Creating storage with the provided configuration. Please  wait...

Could not find physical devices corresponding to LUNs  "10.200.1.66:/vol/vol1/mnt_SdLun" in device list. Make sure storage system WWPN  is added to the HBA driver configuration file.

Do you want to create more storage {y, n}[y]?:

ERROR #2

----------------

bash-3.00# snapdrive storage create -fs /mnt/ -lun  10.200.1.66:/vol/vol1/lun2 -lunsize 2g

        LUN 10.200.1.66:/vol/vol1/lun2 ...  created

        mapping new lun(s) ... done

        discovering new lun(s) ... *failed*

        Cleaning up ...

         - LUN 10.200.1.66:/vol/vol1/lun2 ...  deleted

0001-411 Admin error: Could not find physical devices  corresponding to LUNs "10.200.1.66:/vol/vol1/lun2" in device list. Make sure  storage system WWPN is added to the HBA driver configuration  file.

ERROR #3

----------------

bash-3.00# snapdrive storage show -all

0001-185 Command error: storage show failed: no NETAPP  devices to show or add the host to the trusted hosts (options trusted.hosts) on  the storage system or retry after changing snapdrive.conf to use https for  storage system communication and restarting snapdrive daemon.

bash-3.00#

Any help will be apreciated.

Regards,

Hernan

[jcosta]

first thing you should do is to find out which release you are running, and looking into the interoperability matrix to see if that release is supported.

you also need to take into account, the protocols you are using, multipath and volume manager software installed.

[hernancaputi]

I understand that the compatibility will not be an issue since my presales engineer asures that it was checked... anyway I have asked my customer for the Solaris 10 release just to confirm compatibility.

I will update as soon as I receive customer answer.

Regards,

Hernan Caputi

[hernancaputi]

My presales engineer sent me a note where there was a PVR required and the Netapp answer to the PVR is that we shuld upgrade from SAN Foundation kit from 4.4.11 to 4.4.12. Does anyone know where I can download this software?

Thanks

[aborzenkov]

This request makes no sense. Software that was packaged as SAN Foundation Kit for Solaris 9 and below is now part of base operating system in Solaris 10. So requirement should be either specific driver version or specific Solaris 10 update level.

[libo]

Just wondering whether this problem was resolved?  I have just setup a Solaris syste, with SDU and experiencing the same issue.

[lacerte]

I've installed SDU 4.1.1 on Solaris 10u8 x86 and have the same issue when SDU fails to discover a newly created FC Lun as seen below:

<<<

root@SANBOOT-H6RTP7/kernel/drv # snapdrive storage create -fs /testsnap1 -vgsize 1G -filervol fasc1:/vol/testsnap_vol1

         LUN testsnap1_SdLun ... created

         mapping new lun(s) ... done
         discovering new lun(s) ... *failed*

         Cleaning up ...
          - LUN fasc2:/vol/testsnap_vol1/testsnap1_SdLun ... deleted
0001-411 Admin error: Could not find physical devices corresponding to LUNs "fasc2:/vol/testsnap_vol1/testsnap1_SdLun" in device list. Make sure storage system WWPN is added to the HBA driver configuration file

<<<

I am able to discover manually created LUNS (which I create on the file and map to an igroup) but SDU created luns are not discovered...?

[servicemagic]

Any resolution to this as I am having the same issue.

[njuillerat]

One cause of this error is because the file "snapdrive.conf" has to change this variable.

This....

#default-transport="iscsi"  # Transport type to use for storage provisioning, when a decision is needed

To this...

default-transport="FCP"  # Transport type to use for storage provisioning, when a decision is needed

I hope you have been helpful.

Regards

[ogra]

If there is no support issue and everything is verified then you should have a look at Multipath.

If you are able to create a LUN manually and map it's because there is no pre-check for validating all the paths for a LUN. For snapdrive it is and it will throw up a error if it can't discover the LUN's created.

Best way to resolve this issue is to use NHU, we have a mpio_set script which will setup the mpio parameters for the server and after a reboot it should be okay.

[scottfawcett]

I am having the same issue on SDU on Solaris 9 with SDU 4.1.  The interesting point is that we previously created LUNs on this host to the same filer and had no issues.  We are getting the same error message

mapping new luns(s) ... done

discovering new lun(s) .. *failed*

Cleaning up ...

     - LUN <filer path> ... deleted

0001-411 Admin error: Could not find physcial devices corresponding to LUNs <path> in device list. 

Any thoughts on this one?

-S

[vamshi_krishnad]

still no solution i think i am also facing the same issue if any one come across the solution please update

[peterkain42]

We're you ever able to resolve and if so how?

Thanks,

Pete

[LarsTimmann]

We had exactly your error messages.

In our case it was just a problem in the name mapping.

We had a <filer_IP> with a <filer_name> in the /etc/hosts for the storage and used that <filer_name> for

  snapdrive config set <user> <filer_name>

On the file we had <real_filer_name> what was different to our <filer_name>.

After we corrected the /eth/hosts to:

<filer_IP> <real_filer_name>

And did a

# snapdrive config set <user> <real_filer_name>

and did a

# snapdrive storage create -lun <real_filer_name>:/vol/lunvol/q0/lun1 -lunsize 142m -igroup myigroup

It worked.

Stupid peace of software. It should warn that there is a hostname mismatch between filer and resolving on the host instead of failing to match the LUN while discovering.

Have fun

    Lars