[Patch 2/2] iscsiadm: checking return value of iscsid_req_wait() in iscsid_req_by_rec()

2009-11-11 Thread Yangkook Kim
This patch adds some codes to output logs to reflect the return value
of iscsid_req_wait() for outputting logging.

Please give me a feedback if any.

-- Yangkook Kim


Signed-off-by: Yangkook Kim 

---

--- a/usr/util.c2009-11-12 06:22:10.0 +0900
+++ b/usr/util.c2009-11-12 06:28:45.0 +0900
@@ -121,6 +121,34 @@

 #define MAXSLEEP 128

+void iscsid_handle_error(mgmt_ipc_err_e err)
+{
+   static char *err_msgs[] = {
+   /* 0 */ "",
+   /* 1 */ "unknown error",
+   /* 2 */ "not found",
+   /* 3 */ "no available memory",
+   /* 4 */ "encountered connection failure",
+   /* 5 */ "encountered iSCSI login failure",
+   /* 6 */ "encountered iSCSI database failure",
+   /* 7 */ "invalid parameter",
+   /* 8 */ "connection timed out",
+   /* 9 */ "internal error",
+   /* 10 */ "encountered iSCSI logout failure",
+   /* 11 */ "iSCSI PDU timed out",
+   /* 12 */ "iSCSI driver not found. Please make sure it
is loaded, and retry the operation",
+   /* 13 */ "daemon access denied",
+   /* 14 */ "iSCSI driver does not support requested capability.",
+   /* 15 */ "already exists",
+   /* 16 */ "Unknown request",
+   /* 17 */ "encountered iSNS failure",
+   /* 18 */ "could not communicate to iscsid",
+   /* 19 */ "encountered non-retryable iSCSI login failure",
+   /* 20 */ "could not connect to iscsid",
+   };
+   log_error("initiator reported error (%d - %s)", err, err_msgs[err]);
+}
+
 static mgmt_ipc_err_e iscsid_connect(int *fd)
 {
int nsec;
@@ -231,7 +259,18 @@
err = iscsid_req_by_rec_async(cmd, rec, &fd);
if (err)
return err;
-   return iscsid_req_wait(cmd, fd);
+   err = iscsid_req_wait(cmd, fd);
+   if (err) {
+   log_error("Could not login to [iface: %s, target: %s, "
+ "portal: %s,%d]: ", rec->iface.name,
+  rec->name, rec->conn[0].address,
+  rec->conn[0].port);
+   } else
+   printf("Login to [iface: %s, target: %s, portal: "
+  "%s,%d]: successful\n", rec->iface.name,
+   rec->name, rec->conn[0].address,
+   rec->conn[0].port);
+   return err;
 }

 int iscsid_req_by_sid_async(iscsiadm_cmd_e cmd, int sid, int *fd)
@@ -312,34 +351,6 @@
iface_setup_defaults(&rec->iface);
 }

-void iscsid_handle_error(mgmt_ipc_err_e err)
-{
-   static char *err_msgs[] = {
-   /* 0 */ "",
-   /* 1 */ "unknown error",
-   /* 2 */ "not found",
-   /* 3 */ "no available memory",
-   /* 4 */ "encountered connection failure",
-   /* 5 */ "encountered iSCSI login failure",
-   /* 6 */ "encountered iSCSI database failure",
-   /* 7 */ "invalid parameter",
-   /* 8 */ "connection timed out",
-   /* 9 */ "internal error",
-   /* 10 */ "encountered iSCSI logout failure",
-   /* 11 */ "iSCSI PDU timed out",
-   /* 12 */ "iSCSI driver not found. Please make sure it
is loaded, and retry the operation",
-   /* 13 */ "daemon access denied",
-   /* 14 */ "iSCSI driver does not support requested capability.",
-   /* 15 */ "already exists",
-   /* 16 */ "Unknown request",
-   /* 17 */ "encountered iSNS failure",
-   /* 18 */ "could not communicate to iscsid",
-   /* 19 */ "encountered non-retryable iSCSI login failure",
-   /* 20 */ "could not connect to iscsid",
-   };
-   log_error("initiator reported error (%d - %s)", err, err_msgs[err]);
-}
-
 int __iscsi_match_session(node_rec_t *rec, char *targetname,
  char *address, int port, struct iface_rec *iface)
 {

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

--- a/usr/util.c	2009-11-12 06:22:10.0 +0900
+++ b/usr/util.c	2009-11-12 06:28:45.0 +0900
@@ -121,6 +121,34 @@
 
 #define MAXSLEEP 128
 
+void iscsid_handle_error(mgmt_ipc_err_e err)
+{
+	static char *err_msgs[] = {
+		/* 0 */ "",
+		/* 1 */ "unknown error",
+		/* 2 */ "not found",
+		/* 3 */ "no available memory",
+		/* 4 */ "encountered connection failure",
+		/* 5 */ "encountered iSCSI login failure",
+		/* 6 */ "encountered iSCSI database failure",
+		/* 7 */ "invalid paramet

[Patch 1/2] iscsiadm: login_portal() misses outputting logs for iscsid_req_by_rec()

2009-11-11 Thread Yangkook Kim
This patch tries to fix the lack of outputting logs when
iscsid_req_by_rec is used.

When using iscsid_req_by_rec, the current codes does not tell you whether you
are successfully logged in or hitting some errors because you cannot
get into the
loop of list_for_each_entry_safe() in iscsid_login_reqs_wait(). I
modify some codes
so that iscsid_req_by_rec will output logs.

Please give me a feedback if any.

-- Yangkook Kim


Signed-off-by: Yangkook Kim 

---


--- a/usr/iscsiadm.c2009-11-12 06:22:10.0 +0900
+++ b/usr/iscsiadm.c2009-11-12 06:23:01.0 +0900
@@ -597,29 +597,31 @@
INIT_LIST_HEAD(&async_req->list);
}

-   if (async_req)
-   rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
-rec, &fd);
-   else
-   rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
-   /* we raced with another app or instance of iscsiadm */
-   if (rc == MGMT_IPC_ERR_EXISTS) {
-   if (async_req)
-   free(async_req);
-   return 0;
-   } else if (rc) {
-   iscsid_handle_error(rc);
-   if (async_req)
-   free(async_req);
-   return ENOTCONN;
-   }
-
if (async_req) {
+rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
+rec, &fd);
+   if (rc == MGMT_IPC_ERR_EXISTS) {
+   if (async_req)
+   free(async_req);
+   return 0;
+   } else if (rc) {
+   iscsid_handle_error(rc);
+   if (async_req)
+   free(async_req);
+   return ENOTCONN;
+   }
list_add_tail(&async_req->list, list);
async_req->fd = fd;
async_req->data = rec;
+   return 0;
+   } else {
+   rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
+   if (rc) {
+   iscsid_handle_error(rc);
+   return ENOTCONN;
+   } else
+   return rc;
}
-   return 0;
 }

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

--- a/usr/iscsiadm.c	2009-11-12 06:22:10.0 +0900
+++ b/usr/iscsiadm.c	2009-11-12 06:23:01.0 +0900
@@ -597,29 +597,31 @@
 			INIT_LIST_HEAD(&async_req->list);
 	}
 
-	if (async_req)
-		rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
-	 rec, &fd);
-	else
-		rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
-	/* we raced with another app or instance of iscsiadm */
-	if (rc == MGMT_IPC_ERR_EXISTS) {
-		if (async_req)
-			free(async_req);
-		return 0;
-	} else if (rc) {
-		iscsid_handle_error(rc);
-		if (async_req)
-			free(async_req);
-		return ENOTCONN;
-	}
-
 	if (async_req) {
+rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
+	 rec, &fd);
+		if (rc == MGMT_IPC_ERR_EXISTS) {
+			if (async_req)
+free(async_req);
+	 			return 0;
+		} else if (rc) {
+			iscsid_handle_error(rc);
+			if (async_req)
+free(async_req);
+			 	return ENOTCONN;
+		}
 		list_add_tail(&async_req->list, list);
 		async_req->fd = fd;
 		async_req->data = rec;
+		return 0;
+	} else {
+		rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
+		if (rc) {
+			iscsid_handle_error(rc);
+			return ENOTCONN;
+		} else
+			return rc;
 	}
-	return 0;
 }
 
 static int __login_portals(void *data, int *nr_found,


Re: Help: Driver not found Problem

2009-11-11 Thread Mike Christie

bjornnoss wrote:
> Why did it not work the first time, and do have have to issue the
> depmod -a command after every reboot of the system before modprobe
> iscsi_tcp witch is done in the open-iscsi startup script? Any other
> things a have to be awere of befause of this?
> 

Not sure yet. I cannot replicate it here and no one follows up :)

In fedora at least, when I run make install I get this:
make[2]: Entering directory `/usr/src/kernels/2.6.27.25-78.2.56.fc9.i686'
   INSTALL 
/home/mnc/kernel/iscsi/open-iscsi/git/open-iscsi/open-iscsi-2.0-871.1/kernel/iscsi_tcp.ko
   INSTALL 
/home/mnc/kernel/iscsi/open-iscsi/git/open-iscsi/open-iscsi-2.0-871.1/kernel/libiscsi.ko
   INSTALL 
/home/mnc/kernel/iscsi/open-iscsi/git/open-iscsi/open-iscsi-2.0-871.1/kernel/libiscsi_tcp.ko
   INSTALL 
/home/mnc/kernel/iscsi/open-iscsi/git/open-iscsi/open-iscsi-2.0-871.1/kernel/scsi_transport_iscsi.ko
   DEPMOD  2.6.27.25-78.2.56.fc9.i686


and the depmod step above will edit 
/lib/modules/$kernel_version/modules.dep
So when I do modprobe iscsi_tcp (or when the init script does it) it 
loads fine.

Maybe it is due to a diff in fedora and debian.

Could you tell me when you run make install or depmod -a does a file in 
/lib/modules/$your_kernel/modules.dep get updated or created? In that 
file do you see some info for libiscsi_tcp? When you reboot your system 
is the file still there?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: open-iscsi possibly causing servers to hang (HP blade, CentOS, MSA2012i)

2009-11-11 Thread Mike Christie

Niels Callesøe wrote:
> Hello group
> 
> I am running a number of HP blade servers in a C7200 enclosure.
> Several of them have access to individual LUN's on an MSA 2012i using
> open-iscsi. Recently, however, I have experienced unexplained hangs of
> the servers in question and the only appearent thing they have in
> common (beside being blade servers) is that they have access to the IP-
> SAN.
> 
> When the servers fail, they do so in a fashion where they will still
> respond to, for example, ping requests. But they refuse to respond to
> higher level access, such as spawning a shell for login. This means
> that when the error occurs, I cannot even log into the machines to
> troubleshoot the problem (regardless of remote or local login), even
> though the console greeting is printed readily.
> 
> My question is primarily whether this sounds like something the iscsi-
> driver could cause and, equally importantly, how one would go about
> troubleshooting the issue. One thing that makes it particularly
> elusive is that I cannot seem to provoke the error state and it does
> not occur very often (at least not while the platform is not yet in
> full production).
> 
> Possibly relevant information follows:
> 
> OS: centos-release-5-3.el5.centos.1
> iscsi version: iscsid version 2.0-868
> MSA: Current Storage Controller Code Version J210P12
> 
> I can, and have started, upgrades to more recent versions of all
> three. However, those were the versions running when the problem was
> caused last -- and since I cannot provoke it, I have no real way of
> knowing if version upgrades will solve the issue (unless someone in
> this group can confirm that it will, of course).
> 

It could be iscsi. Are you using multipath and do you know if there are 
path failures when the system hangs? Is there anything in the log?

If there is nothing in the log at the time of the hang, could you hook 
up a serial line? I am hoping a oops will get spit out at the time of 
the hang.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



open-iscsi possibly causing servers to hang (HP blade, CentOS, MSA2012i)

2009-11-11 Thread Niels Callesøe

Hello group

I am running a number of HP blade servers in a C7200 enclosure.
Several of them have access to individual LUN's on an MSA 2012i using
open-iscsi. Recently, however, I have experienced unexplained hangs of
the servers in question and the only appearent thing they have in
common (beside being blade servers) is that they have access to the IP-
SAN.

When the servers fail, they do so in a fashion where they will still
respond to, for example, ping requests. But they refuse to respond to
higher level access, such as spawning a shell for login. This means
that when the error occurs, I cannot even log into the machines to
troubleshoot the problem (regardless of remote or local login), even
though the console greeting is printed readily.

My question is primarily whether this sounds like something the iscsi-
driver could cause and, equally importantly, how one would go about
troubleshooting the issue. One thing that makes it particularly
elusive is that I cannot seem to provoke the error state and it does
not occur very often (at least not while the platform is not yet in
full production).

Possibly relevant information follows:

OS: centos-release-5-3.el5.centos.1
iscsi version: iscsid version 2.0-868
MSA: Current Storage Controller Code Version J210P12

I can, and have started, upgrades to more recent versions of all
three. However, those were the versions running when the problem was
caused last -- and since I cannot provoke it, I have no real way of
knowing if version upgrades will solve the issue (unless someone in
this group can confirm that it will, of course).

Thank you for any advice you could offer.

--
Niels

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: Help: Driver not found Problem

2009-11-11 Thread bjornnoss



On 29 Okt, 19:01, Mike Christie  wrote:
> Lee Amy wrote:
>
> > It builds well but when I want to load the module it always shows the
> > error messages I pasted.
>
> > Could you tell me how to deal with it?
>
> I am still trying to figure that out :)
>
> If after you do make install if you do a
>
> depmod -a
>
> then try modprobe iscsi_tcp does that load all the modules
> iscsi_tcp
> libiscsi_tcp
> libiscsi
> scsi_transport_iscsi
>
> ?

Hi, I had the exact same problem as Eric and I tried to do: depmod -a;
modprobe iscsi_tcp and it seems to work:
lsmod | grep iscsi_tcp
iscsi_tcp  17036  0
libiscsi_tcp   22148  1 iscsi_tcp
libiscsi   45712  2 iscsi_tcp,libiscsi_tcp
scsi_transport_iscsi36512  3 iscsi_tcp,libiscsi
scsi_mod  161016  10
iscsi_tcp,libiscsi,scsi_transport_iscsi,sg,sr_mod,usb_storage,ses,sd_mod,libata,megaraid_sas

So thank you...

Why did it not work the first time, and do have have to issue the
depmod -a command after every reboot of the system before modprobe
iscsi_tcp witch is done in the open-iscsi startup script? Any other
things a have to be awere of befause of this?

Enviroment: Debian Lenny x64
iSCSI: Dell PowerVault MD3000i

-bjornoss
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: iscsi-iname command is very misleading

2009-11-11 Thread Ulrich Windl

On 10 Nov 2009 at 13:09, Oren Held wrote:

> 
> I see two independent steps which we can take:
> 
> 1. RENAME: IMO that get-iqn can still be interpreted as "get current iqn". In 
> the SSH spirit, I'd choose iscsi-iqn-gen (like ssh-keygen)
> 
> Renaming, of course, might break 3rd party scripts who look for iscsi-iname.
> 
> 2. Print to STDERR "Generating a new IQN...".
> This one is not supposed to affect 3rd party scripts, which probably redirect 
> only the STDOUT.

In the spirit of UNIX, progress messages going to stderr are unusual, except 
the 
process will need significant toime to complete. (MHO)

Ulrich

> 
> 
> On Tuesday 10 November 2009 09:36:48 Ulrich Windl wrote:
> > On 8 Nov 2009 at 15:42, Oren wrote:
> > > Hello,
> > >
> > > I've encountered too many cases of people thinking the iscsi-iname
> > 
> > What about naming it "gen-iqn" instead (in the UNIX tradition of having a
> >  short name preferrable over
> >  "generate-new-iSCSI-qualified-name-for-initiator")?
> > 
> > Ulrich
> > 
> > > command, just like ifconfig, displays the currently configured IQN,
> > > not being aware that, in fact, it generates a new IQN.
> > > The man page (Debian-supplied, not in open-iscsi git) describes it
> > > best, but the --help string is absolutely misleading or even wrong.
> > >
> > > Here's my patch, that changes the wording to something similar to the
> > > Debian's man page:
> > > diff --git a/utils/iscsi-iname.c b/utils/iscsi-iname.c
> > > index 7cf0e7a..80fc1d1 100644
> > > --- a/utils/iscsi-iname.c
> > > +++ b/utils/iscsi-iname.c
> > > @@ -62,7 +62,7 @@ main(int argc, char *argv[])
> > > prefix = argv[1];
> > > if (( strcmp(prefix, "-h") == 0 ) ||
> > > ( strcmp(prefix, "--help") == 0 )) {
> > > -   printf("\nDisplays the iSCSI initiator name
> > > \n");
> > > +   printf("\nGenerates a unique iSCSI node name
> > > on every invocation\n"
> > > exit(0);
> > > } else if ( strcmp(prefix, "-p") == 0 ) {
> > > prefix = argv[2];
> > >
> > >
> > > Best Regards,
> > >
> > > Oren Held
> > > Host-side development
> > > IBM-XIV Storage
> > 
> > > 
> 
> -- 
> Oren Held
> Host-side development
> IBM-XIV
> 
> > 



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---