Hello Frans,

I have seen similar problems like this occur in the past, so I'm going to offer up a few suggestions in the hope we can get this taken care of.

1.   Check the current length of the lun names - If they're excessively long, this could be part of your problem.

2.   Make sure you have no stale snapdrive daemons or that the snapdrive ports are not in use

a.) ps -ae | grep snap

b.) ps -an | grep 4094

3.   Attempt enabling low latency to disable delayed ACK from kicking in.

Check with:

sysctl -a| grep net.ipv4.tcp_low_latency

Should report:

net.ipv4.tcp_low_latency = 0

Enable with:

sysctl -w net.ipv4.tcp_low_latency=1

4.   And above all, if your troubleshooting steps up until 3 do not return any significant results, contact support -  888-463-8277 (888-4NETAPP)

Let us know if this helps Frans!

Thanks,

Christopher

Thanks for the update Frans,

I look forward to a speedy resolution to your problem!

Christopher

To add more information here, most of which was included in my ticket to NetApp support:

OS: CentOS 5.2 (Also tried with Fedora 7 with same results)
Filer: FAS 3070
Connection: iSCSI
SnapDrive Version: 4.0, 3.0 and 2.2.1
sanlun version: 3.2.79.2486

Snapdrive v4.0:
All 'snapdrive config *' commands work, nothing else appears to work.  Mainly:
#snapdrive storage list -all
Status call to SDU daemon failed

Snapdrive v.3.0:
Nothing here really appears to work.  The common error I get is:
0001-877 Admin error: HBA assistant not found. Commands involving LUNs should fail.

The most success I have had was with Snapdrive v 2.2.1

Snapdrive v 2.2.1:

'snapdrive config' works

I have had success with 'snapdrive snap create -fs [path_to_mounted_LUN]'

Doing a 'snapdrive snap restore' from the snap does NOT work, however I successfully tested making a FlexClone from the Snap and mounting it.

Snapdrive v2.2.1 does NOT work with multipathing, as I found out just tonight which is a requirement for production use, IMHO.

Neither 'snapdrive storage show -all' or 'snapdrive storage list -all' work.  They seem to be similar commands anywho.

A host entry exists for the filers and works, otherwise simply getting a login to the filer would fail (you should not be able to 'snapdrive config set [filer] root' without this existing).

The meaning of my addition to this post was to prove there is a need and want for snapdrive to work in CentOS and that others are trying to make it work with very little success.

(a) 'sanlun lun show'

This is working correctly.  Results are showing filers, LUNs that are mapped to the igroup the initiator belongs to, lun-pathnames are correct as well as device filenames.

filer:          lun-pathname         device filename  adapter  protocol          lun size         lun state
  fas-001:  /vol/vol_test4/lun_test4  /dev/sde         host1    iSCSI      400.0g (429523992576)   GOOD    
  fas-001:  /vol/vol_test4/lun_test4  /dev/sdc         host2    iSCSI      400.0g (429523992576)   GOOD    
  fas-001:  /vol/vol_test3/lun_test3  /dev/sdd         host1    iSCSI      400.0g (429523992576)   GOOD    
  fas-001:  /vol/vol_test3/lun_test3  /dev/sdb         host2    iSCSI      400.0g (429523992576)   GOOD     

(b) 'sanlun fcp show adapter -v'

Unable to locate /usr/lib/libHBAAPI.so library
Make sure the package installing the library is installed & loaded

I am using iSCSI and I believe the original poster was as well.  Should this still show some sort of result back

I found this KB article: https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb41496

which seems to indicate Linux Host Utils should install that library, but it does not exist on my systems.  Is it installed with iSCSI Host Utils also or just FC Host Utils? 

below obtained from active config, using grep to single out lines:

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

multipathing-type="none"  # Multipathing software to use when more than one multipathing solution is available 

fstype did not exist, I've manually added this in by hand(this did not change anything)

vmtype did not exist also.  We're not using LVM so I have not added this to the config

use-https-to-filer=on  # Communication with filer done via HTTPS instead of HTTP

I have disabled all HTTP transactions on the filer end so I have this enabled.  I can re-enable HTTP mode if you think this will make a difference and re-test.

It should be noted that I am using snapdrive 2.2.1 for these, as that is the version I have had the most sucess with.  Thanks,

Jesse

'snapdrive snap restore -fs [local fs path] -snapname [snap_created]'

I've tried this with both the LUN device mounted and unmounted with the same results.  In my case, the restore command is less of an issue.  I have successfully used a SNAP to create a FlexVol without issues.  It's a slight annoying to have to get on the filer to do this, but not a problem really, especially with the frequency a SNAP is/will be restored.

That is right

in a condensed, psuedo command type fashion:

filer> create lun, map to igroup, etc

server> iscsiadm resync

server> fdisk to create partition on device (following KB article http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb8190 to ensure proper alignment)

server> mke2fs w/ journal

server> mount LUN device partition

server> snapdrive snap creat -fs [LUN device partition] -snapname test

This is due to iSCSI Hardware initiator. SDU currently does not support iSCSI Hardware initiator in Linux (Please refer to NetApp InterOperability Matrix). iSCSI Hardware initiator is supported only on Solaris platform.

Regards,

Senthil

It should work with FCP.   It could be that some settings are not configured properly.  Please make sure you have followed SnapDrive for Unix Installation and Administration Guide properly.  Please contact NetApp support, if you still have issues.

Thanks Michael,

your post made my day. Now I've my proof of concept running, using CentOs 5.1 as a Xen host with VMs (also CentOs 5.1) running a simulator and two Oracle 11g RAC nodes, all controlled by Snapmanager for Oracle.Tested all combinations (NFS, DNFS both directly using the simulators NFS shares as well as ASM on top of NFS shares).

Works great.

Mark

SnapDrive for UNIX v4.1 works with Redhat v5.2.

What was the original value in the /etc/redhat-release file? What were the commands that were failing?

I do not suspect this to be an an issue with the /etc/redhat-release file. We need to analyze the trace logs and system configuration to understand the problem.

Kindly file a ticket with NetApp and provide them with the output of "snapdrive.dc" and linux_info diagnostic scripts.

We have RHEL 5.3 with Emulex HBA, Host Utils 5.0, Snapdrive 4.1 and were running into the same issue as above.  Netapp has released a fix to make this work, but does not work.  This did fix the problem but we need a supportable fix and this is a hack.  I have heard Netapp is working on officially releasing the "broken" fix soon.  We are trying to figure out what is wrong with our environment that the fix does not work, as they have not released the docs yet.  We are supposed to be on the line with the product managers tonight.

Keep you updated.

OK I think I may have found the solution.

After digging through the snapdrive and snapdrived binaries I noticed that the check it does between RHEL4 and RHEL5 are different.

For RHEL4 it does a 'cat /etc/redhat-release' to get the OS version information.

For RHEL5 id does a 'cat /etc/issue' for the OS information.

As to why this changed I have no idea, just modify '/etc/issue' with:

Red Hat Enterprise Linux Server release 5.3 (Tikanga)

Kernel \r on an \m

Don't forget to set '/etc/redhat-release' back to the original for your system. For RHEL5 it is:

Red Hat Enterprise Linux Server release 5.3 (Tikanga)

Restart snapdrived.

I tested with 'snapdrive storage list -all' and it gave me the correct output.

Hope this helps.