Build problems with 869.2
open-iscsi 869.2 doesn't seem to want to compile for me. I am compiling against linux-2.6.18 with openvz patches applied from http://wiki.openvz.org/Download/kernel/rhel5/028stab057.2 Any ideas? ak1-vz1:~/open-iscsi-2.0-869.2# make make -C utils/fwparam_ibft make[1]: Entering directory `/root/open-iscsi-2.0-869.2/utils/ fwparam_ibft' cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o fwparam_ibft.o fwparam_ibft.c cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o fw_entry.o fw_entry.c fw_entry.c: In function ‘dump_mac’: fw_entry.c:41: warning: unused variable ‘i’ cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o prom_lex.o prom_lex.c stdout:1622: warning: ‘yyunput’ defined but not used cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o prom_parse.tab.o prom_parse.tab.c cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o fwparam_ppc.o fwparam_ppc.c fwparam_ppc.c: In function ‘loop_devs’: fwparam_ppc.c:352: warning: passing argument 4 of ‘qsort’ from incompatible pointer type make[1]: Leaving directory `/root/open-iscsi-2.0-869.2/utils/ fwparam_ibft' make -C usr make[1]: Entering directory `/root/open-iscsi-2.0-869.2/usr' cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o util.o util.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o io.o io.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o auth.o auth.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o login.o login.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o log.o log.c log.c:325: warning: ‘__dump_char’ defined but not used cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o md5.o md5.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o sha1.o sha1.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsi_sysfs.o iscsi_sysfs.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o idbm.o idbm.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o netlink.o netlink.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o initiator.o initiator.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o scsi.o scsi.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o actor.o actor.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o mgmt_ipc.o mgmt_ipc.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o isns.o isns.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o transport.o transport.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsid.o iscsid.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE util.o io.o auth.o login.o log.o md5.o sha1.o iscsi_sysfs.o idbm.o netlink.o initiator.o scsi.o actor.o mgmt_ipc.o isns.o transport.o iscsid.o -o iscsid cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o strings.o strings.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o discovery.o discovery.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsiadm.o iscsiadm.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE util.o io.o auth.o login.o log.o md5.o sha1.o iscsi_sysfs.o idbm.o ../utils/fwparam_ibft/fw_entry.o ../utils/ fwparam_ibft/fwparam_ibft.o ../utils/fwparam_ibft/fwparam_ppc.o ../ utils/fwparam_ibft/prom_lex.o ../utils/fwparam_ibft/prom_parse.tab.o strings.o discovery.o iscsiadm.o -o iscsiadm cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsistart.o iscsistart.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o statics.o statics.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -static netlink.o util.o io.o auth.o login.o log.o md5.o sha1.o iscsi_sysfs.o idbm.o initiator.o scsi.o actor.o mgmt_ipc.o isns.o transport.o ../utils/fwparam_ibft/ fw_entry.o ../utils/fwparam_ibft/fwparam_ibft.o ../utils/fwparam_ibft/ fwparam_ppc.o ../utils/fwparam_ibft/prom_lex.o ../utils/fwparam_ibft/ prom_parse.tab.o iscsistart.o statics.o -o iscsistart login.o: In function `resolve_address': /root/open-iscsi-2.0-869.2/usr/login.c:168: warning: Using
Re: Build problems with 869.2
Just saw the thread about rhel5 symbol problems, which seems to be my issue. Tried to apply the patch from Erez to 869.2 source, but it failed :( On Aug 26, 2:03 am, v42bis [EMAIL PROTECTED] wrote: open-iscsi 869.2 doesn't seem to want to compile for me. I am compiling against linux-2.6.18 with openvz patches applied fromhttp://wiki.openvz.org/Download/kernel/rhel5/028stab057.2 Any ideas? ak1-vz1:~/open-iscsi-2.0-869.2# make make -C utils/fwparam_ibft make[1]: Entering directory `/root/open-iscsi-2.0-869.2/utils/ fwparam_ibft' cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o fwparam_ibft.o fwparam_ibft.c cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o fw_entry.o fw_entry.c fw_entry.c: In function ‘dump_mac’: fw_entry.c:41: warning: unused variable ‘i’ cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o prom_lex.o prom_lex.c stdout:1622: warning: ‘yyunput’ defined but not used cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o prom_parse.tab.o prom_parse.tab.c cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o fwparam_ppc.o fwparam_ppc.c fwparam_ppc.c: In function ‘loop_devs’: fwparam_ppc.c:352: warning: passing argument 4 of ‘qsort’ from incompatible pointer type make[1]: Leaving directory `/root/open-iscsi-2.0-869.2/utils/ fwparam_ibft' make -C usr make[1]: Entering directory `/root/open-iscsi-2.0-869.2/usr' cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o util.o util.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o io.o io.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o auth.o auth.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o login.o login.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o log.o log.c log.c:325: warning: ‘__dump_char’ defined but not used cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o md5.o md5.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o sha1.o sha1.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsi_sysfs.o iscsi_sysfs.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o idbm.o idbm.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o netlink.o netlink.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o initiator.o initiator.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o scsi.o scsi.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o actor.o actor.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o mgmt_ipc.o mgmt_ipc.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o isns.o isns.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o transport.o transport.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsid.o iscsid.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE util.o io.o auth.o login.o log.o md5.o sha1.o iscsi_sysfs.o idbm.o netlink.o initiator.o scsi.o actor.o mgmt_ipc.o isns.o transport.o iscsid.o -o iscsid cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o strings.o strings.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o discovery.o discovery.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsiadm.o iscsiadm.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE util.o io.o auth.o login.o log.o md5.o sha1.o iscsi_sysfs.o idbm.o ../utils/fwparam_ibft/fw_entry.o ../utils/ fwparam_ibft/fwparam_ibft.o ../utils/fwparam_ibft/fwparam_ppc.o ../ utils/fwparam_ibft/prom_lex.o ../utils/fwparam_ibft/prom_parse.tab.o strings.o discovery.o iscsiadm.o -o iscsiadm cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsistart.o iscsistart.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o statics.o statics.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -static netlink.o util.o io.o auth.o login.o log.o md5.o sha1.o iscsi_sysfs.o idbm.o initiator.o scsi.o actor.o mgmt_ipc.o isns.o transport.o ../utils/fwparam_ibft/
SAN
I am thinking of a design to improve performance of SAN. To do this i am thinking of an in band switch based virtualization which recieves an ISCSI request and splits the request into two and simultaneously reads data from two insync disk at remote locations. tell me is this solution feasible !! and i want software based solution with minimum hardware involvement ! tell me how out of band storage virtualization can help me in this ?? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Build problems with 869.2
On Tue, Aug 26, 2008 at 11:20 AM, v42bis [EMAIL PROTECTED] wrote:
Just saw the thread about rhel5 symbol problems, which seems to be my
issue. Tried to apply the patch from Erez to 869.2 source, but it
failed :(
Try the attached patch.
Erez
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
diff --git a/kernel/2.6.14-19_compat.patch b/kernel/2.6.14-19_compat.patch
index 4d66655..4730afa 100644
--- a/kernel/2.6.14-19_compat.patch
+++ b/kernel/2.6.14-19_compat.patch
@@ -1,9 +1,9 @@
diff --git a/iscsi_compat.h b/iscsi_compat.h
new file mode 100644
-index 000..965157a
+index 000..23ba2ea
--- /dev/null
+++ b/iscsi_compat.h
-@@ -0,0 +1,192 @@
+@@ -0,0 +1,216 @@
+#include linux/version.h
+#include linux/kernel.h
+#include scsi/scsi.h
@@ -136,12 +136,21 @@ index 000..965157a
+#endif
+
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
-+
++#ifdef RHEL_RELEASE_VERSION
++#if RHEL_RELEASE_CODE RHEL_RELEASE_VERSION(5,2)
+static inline int is_power_of_2(unsigned long n)
+{
+ return (n != 0 ((n (n - 1)) == 0));
+}
+#endif
++#else
++/* not a redhat kernel */
++static inline int is_power_of_2(unsigned long n)
++{
++ return (n != 0 ((n (n - 1)) == 0));
++}
++#endif
++#endif
+
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,21)
+#define netlink_kernel_create(net, uint, groups, input, cb_mutex, mod) \
@@ -180,6 +189,20 @@ index 000..965157a
+#define scsi_sglist(cmd) ((struct scatterlist *)(cmd)-request_buffer)
+#define scsi_bufflen(cmd) ((cmd)-request_bufflen)
+
++#ifdef RHEL_RELEASE_VERSION
++#if RHEL_RELEASE_CODE RHEL_RELEASE_VERSION(5,2)
++static inline void scsi_set_resid(struct scsi_cmnd *cmd, int resid)
++{
++ cmd-resid = resid;
++}
++
++static inline int scsi_get_resid(struct scsi_cmnd *cmd)
++{
++ return cmd-resid;
++}
++#endif
++#else
++/* not a redhat kernel */
+static inline void scsi_set_resid(struct scsi_cmnd *cmd, int resid)
+{
+ cmd-resid = resid;
@@ -189,6 +212,7 @@ index 000..965157a
+{
+ return cmd-resid;
+}
++#endif
+
+static inline struct nlmsghdr *nlmsg_hdr(const struct sk_buff *skb)
+{
--
1.5.4.3
Re: SAN
varun wrote: I am thinking of a design to improve performance of SAN. To do this i am thinking of an in band switch based virtualization which recieves an ISCSI request and splits the request into two and simultaneously reads data from two insync disk at remote locations. tell me is this solution feasible !! and i want software based solution with minimum It seems feasible. I would ask [EMAIL PROTECTED] or [EMAIL PROTECTED] because their target mode code might be better suited for this already. hardware involvement ! tell me how out of band storage virtualization can help me in this ?? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Odd behaviour during unidirectional CHAP authentication
HI, During unidirectional CHAP configuration on RHEL5.2, I found following odd behaviour. If initiator CHAP is enabled and Target CHAP is _not_ enabled , Authentication Passes. I looked at code, trace and RFC and here is my observation. Here is what initiator and taget passes to each other while iscsi negotiation phase. Assuming CHAP is only enabled on initiator and not on target. 1) Initiator pass CHAP,NONE as Authentication parameter. 2) Target replies with NONE. 3) Both will settle on NONE as Authentication parameter. RFC specifies that, if both (initiator/target) don't agree on same authentication protocol, iscsi login should fail. So in this case, RHEL 5.2 iscsi initiator should ideally pass only CHAP as Authentication parameter to target, so that if target says NONE, negotiation should fail. Can someone please confirm if this is working as per design? configuration : iscsi-initiator-utils-6.2.0.868-0.3 RHEL 5.2 Thank you Nandkumar --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: iscsiadm login issues?
Hah! Sometimes all it takes is another set of eyes. Score one for obvious. Thanks Mike. As far as the automatic login, I did set it in the conf. Then I logged out of the target and restarted the service. It said Logging into targets or something similar and then spit out the no records found message. So I assumed my issues were all related. We know that isn't the case :) You said something about using discovery mode to automatically login? like iscsiadm -m discovery -l? Would that not work regardless of the config setting? Thanks again! Mike Christie wrote: Ben Lake wrote: Hello all, Before I ask anything I'd like to say thank you to all the devs. I appreciate the existence of your project and your hard work! Now I've got a little situation which should hopefully be chalked up to my newb status with open-iscsi. Per the snippet below I can't seem to manually login directly to a single target. Every time I try I get iscsiadm: no records found!. Whether I use the target name, portal, or both. As you can see I have a discovery entry for the portal, and I have a target entry in the node table. The only way I can login to this target is with a blanket node login. It does work. The other interesting bit is when I set the config to auto connect to all targets on startup, that did _not_ work. So apparently the auto connect doesn't use the blanket node login mechanism or some such. Any thoughts or flames are appreciated :P Thanks again! --- snip --- [EMAIL PROTECTED]:~$ sudo iscsiadm -m discovery 10.0.0.11:3260 via sendtargets [EMAIL PROTECTED]:~$ sudo iscsiadm -m node 10.0.0.11:3260,1 ign.2002-07.com.archose:3t.r5.0 Normally the name of the target starts with iqn. A Q instead of a G like above. Below you use a Q, which is probably why it is not working. Sometimes you also drop parts of the name. [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose:3t.r5.0 -p 10.0.0.11:3260 -l If the target has a G in the node db, then you need to pass it a G here. This has a Q in the iqn. iscsiadm: no records found! [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose -p This one will not work because it is misspelled. It is missing the end part :3t.r5.0, and you need to use a G like in the node db. 10.0.0.11:3260 -l iscsiadm: no records found! [EMAIL PROTECTED]:~$ sudo iscsiadm -m discovery -P 1 SENDTARGETS: DiscoveryAddress: 10.0.0.11,3260 Target: ign.2002-07.com.archose:3t.r5.0 Portal: 10.0.0.11:3260,1 Iface Name: default iSNS: No targets found. STATIC: No targets found. [EMAIL PROTECTED]:~$ sudo iscsiadm -m session -P 1 iscsiadm: No active sessions. [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose -l This one is just mispelled. No ending. iscsiadm: no records found! [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -l Login session [iface: default, target: ign.2002-07.com.archose:3t.r5.0, See this has a G. So you need to use a G or fix it on the target so it is spelled like how you want. portal: 10.0.0.11,3260] For the automatic login, how are you settting the automatic login? By setting it in /etc/iscsi/iscsid.conf then running discovery or did you run the iscsiadm in update mode to set the setting? If the latter maybe you had it mispelled so it did not get picked up. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME Cryptographic Signature
Re: iscsiadm login issues?
How is using the discovery command automatic if I still need to specify all the details for each target? Anyway, I'm primarily concerned with why, on startup, it does not login when the conf is set to automatic. It spits out the no records found message as if it spelled things wrong :) Anything I can do to troubleshoot that? Mike Christie wrote: Ben Lake wrote: Hah! Sometimes all it takes is another set of eyes. Score one for obvious. Thanks Mike. As far as the automatic login, I did set it in the conf. Then I logged out of the target and restarted the service. It said Logging into targets or something similar and then spit out the no records found message. So I assumed my issues were all related. We know that isn't the case :) You said something about using discovery mode to automatically login? Not me. like iscsiadm -m discovery -l? Would that not work regardless of the config setting? It should. It is iscsiadm -m discovery -t st -p ip -l Thanks again! Mike Christie wrote: Ben Lake wrote: Hello all, Before I ask anything I'd like to say thank you to all the devs. I appreciate the existence of your project and your hard work! Now I've got a little situation which should hopefully be chalked up to my newb status with open-iscsi. Per the snippet below I can't seem to manually login directly to a single target. Every time I try I get iscsiadm: no records found!. Whether I use the target name, portal, or both. As you can see I have a discovery entry for the portal, and I have a target entry in the node table. The only way I can login to this target is with a blanket node login. It does work. The other interesting bit is when I set the config to auto connect to all targets on startup, that did _not_ work. So apparently the auto connect doesn't use the blanket node login mechanism or some such. Any thoughts or flames are appreciated :P Thanks again! --- snip --- [EMAIL PROTECTED]:~$ sudo iscsiadm -m discovery 10.0.0.11:3260 via sendtargets [EMAIL PROTECTED]:~$ sudo iscsiadm -m node 10.0.0.11:3260,1 ign.2002-07.com.archose:3t.r5.0 Normally the name of the target starts with iqn. A Q instead of a G like above. Below you use a Q, which is probably why it is not working. Sometimes you also drop parts of the name. [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose:3t.r5.0 -p 10.0.0.11:3260 -l If the target has a G in the node db, then you need to pass it a G here. This has a Q in the iqn. iscsiadm: no records found! [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose -p This one will not work because it is misspelled. It is missing the end part :3t.r5.0, and you need to use a G like in the node db. 10.0.0.11:3260 -l iscsiadm: no records found! [EMAIL PROTECTED]:~$ sudo iscsiadm -m discovery -P 1 SENDTARGETS: DiscoveryAddress: 10.0.0.11,3260 Target: ign.2002-07.com.archose:3t.r5.0 Portal: 10.0.0.11:3260,1 Iface Name: default iSNS: No targets found. STATIC: No targets found. [EMAIL PROTECTED]:~$ sudo iscsiadm -m session -P 1 iscsiadm: No active sessions. [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose -l This one is just mispelled. No ending. iscsiadm: no records found! [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -l Login session [iface: default, target: ign.2002-07.com.archose:3t.r5.0, See this has a G. So you need to use a G or fix it on the target so it is spelled like how you want. portal: 10.0.0.11,3260] For the automatic login, how are you settting the automatic login? By setting it in /etc/iscsi/iscsid.conf then running discovery or did you run the iscsiadm in update mode to set the setting? If the latter maybe you had it mispelled so it did not get picked up. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME Cryptographic Signature
Re: iscsiadm login issues?
Ben Lake wrote: How is using the discovery command automatic if I still need to specify all the details for each target? All I said below is that you can run the command without having to set the startup and it will log in. And I meant it will log in when you run the command. Sorry for bad description. With the command below you do not have to run the discovery command and the login command. It is helpful for scrtips that just want to log into whatever is found during discovery instead of doing the node db route. A lot of times you have a discovery address where multiple targets with multiple ports are found, so it is useful to see for that type of case. If you have to do discovery for each target then yeah, there is not much point except saving one command. Anyway, I'm primarily concerned with why, on startup, it does not login when the conf is set to automatic. It spits out the no records found message as if it spelled things wrong :) Anything I can do to troubleshoot that? What distro and init script are you running? Run iscsiadm -m node -L automatic Does that work? If not run it with debugging iscsiadm -m node -L automatic -d 8 and send all the output. Mike Christie wrote: Ben Lake wrote: Hah! Sometimes all it takes is another set of eyes. Score one for obvious. Thanks Mike. As far as the automatic login, I did set it in the conf. Then I logged out of the target and restarted the service. It said Logging into targets or something similar and then spit out the no records found message. So I assumed my issues were all related. We know that isn't the case :) You said something about using discovery mode to automatically login? Not me. like iscsiadm -m discovery -l? Would that not work regardless of the config setting? It should. It is iscsiadm -m discovery -t st -p ip -l Thanks again! Mike Christie wrote: Ben Lake wrote: Hello all, Before I ask anything I'd like to say thank you to all the devs. I appreciate the existence of your project and your hard work! Now I've got a little situation which should hopefully be chalked up to my newb status with open-iscsi. Per the snippet below I can't seem to manually login directly to a single target. Every time I try I get iscsiadm: no records found!. Whether I use the target name, portal, or both. As you can see I have a discovery entry for the portal, and I have a target entry in the node table. The only way I can login to this target is with a blanket node login. It does work. The other interesting bit is when I set the config to auto connect to all targets on startup, that did _not_ work. So apparently the auto connect doesn't use the blanket node login mechanism or some such. Any thoughts or flames are appreciated :P Thanks again! --- snip --- [EMAIL PROTECTED]:~$ sudo iscsiadm -m discovery 10.0.0.11:3260 via sendtargets [EMAIL PROTECTED]:~$ sudo iscsiadm -m node 10.0.0.11:3260,1 ign.2002-07.com.archose:3t.r5.0 Normally the name of the target starts with iqn. A Q instead of a G like above. Below you use a Q, which is probably why it is not working. Sometimes you also drop parts of the name. [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose:3t.r5.0 -p 10.0.0.11:3260 -l If the target has a G in the node db, then you need to pass it a G here. This has a Q in the iqn. iscsiadm: no records found! [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose -p This one will not work because it is misspelled. It is missing the end part :3t.r5.0, and you need to use a G like in the node db. 10.0.0.11:3260 -l iscsiadm: no records found! [EMAIL PROTECTED]:~$ sudo iscsiadm -m discovery -P 1 SENDTARGETS: DiscoveryAddress: 10.0.0.11,3260 Target: ign.2002-07.com.archose:3t.r5.0 Portal: 10.0.0.11:3260,1 Iface Name: default iSNS: No targets found. STATIC: No targets found. [EMAIL PROTECTED]:~$ sudo iscsiadm -m session -P 1 iscsiadm: No active sessions. [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose -l This one is just mispelled. No ending. iscsiadm: no records found! [EMAIL PROTECTED]:~$ sudo iscsiadm -m node -l Login session [iface: default, target: ign.2002-07.com.archose:3t.r5.0, See this has a G. So you need to use a G or fix it on the target so it is spelled like how you want. portal: 10.0.0.11,3260] For the automatic login, how are you settting the automatic login? By setting it in /etc/iscsi/iscsid.conf then running discovery or did you run the iscsiadm in update mode to set the setting? If the latter maybe you had it mispelled so it did not get picked up. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED]
Re: iscsiadm login issues?
Mike Christie wrote: What distro and init script are you running? could you also do whereis iscsiadm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: iscsiadm login issues?
#sudo iscsiadm -m node -L automatic
Login session [iface: default, target: ign.2002-07.com.archose:3t.r5.0,
portal: 10.0.0.11,3260]
Distro: Ubuntu 8.04.01
init snippet
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/iscsid
ADM=/usr/bin/iscsiadm
PIDFILE=/var/run/iscsid.pid
...
start() {
log_daemon_msg Starting iSCSI initiator service iscsid
sanitychecks
modprobe -q iscsi_tcp 2/dev/null || :
modprobe -q ib_iser 2/dev/null || :
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
RETVAL=$?
log_end_msg $RETVAL
starttargets
}
starttargets() {
log_daemon_msg Setting up iSCSI targets
echo
$ADM -m node --loginall=automatic
log_end_msg 0
}
...
end init snippet
#whereis iscsiadm
iscsiadm: /usr/bin/iscsiadm /usr/share/man/man8/iscsiadm.8.gz
Looks like $ADM -m node --loginall=automatic is the line being used to
login to all the targets, perhaps not quite what we want?
Mike Christie wrote:
Ben Lake wrote:
How is using the discovery command automatic if I still need to specify
all the details for each target?
All I said below is that you can run the command without having to set
the startup and it will log in. And I meant it will log in when you run
the command. Sorry for bad description.
With the command below you do not have to run the discovery command and
the login command. It is helpful for scrtips that just want to log into
whatever is found during discovery instead of doing the node db route. A
lot of times you have a discovery address where multiple targets with
multiple ports are found, so it is useful to see for that type of case.
If you have to do discovery for each target then yeah, there is not much
point except saving one command.
Anyway, I'm primarily concerned with why, on startup, it does not login
when the conf is set to automatic. It spits out the no records found
message as if it spelled things wrong :) Anything I can do to
troubleshoot that?
What distro and init script are you running?
Run
iscsiadm -m node -L automatic
Does that work? If not run it with debugging
iscsiadm -m node -L automatic -d 8
and send all the output.
Mike Christie wrote:
Ben Lake wrote:
Hah! Sometimes all it takes is another set of eyes. Score one for
obvious. Thanks Mike.
As far as the automatic login, I did set it in the conf. Then I
logged out of the target and restarted the service. It said Logging
into targets or something similar and then spit out the no records
found message.
So I assumed my issues were all related. We know that isn't the case :)
You said something about using discovery mode to automatically login?
Not me.
like iscsiadm -m discovery -l? Would that not work regardless of the
config setting?
It should. It is
iscsiadm -m discovery -t st -p ip -l
Thanks again!
Mike Christie wrote:
Ben Lake wrote:
Hello all,
Before I ask anything I'd like to say thank you to all the devs. I
appreciate the existence of your project and your hard work!
Now I've got a little situation which should hopefully be chalked
up to my newb status with open-iscsi.
Per the snippet below I can't seem to manually login directly to a
single target. Every time I try I get iscsiadm: no records
found!. Whether I use the target name, portal, or both. As you can
see I have a discovery entry for the portal, and I have a target
entry in the node table. The only way I can login to this target is
with a blanket node login. It does work. The other interesting bit
is when I set the config to auto connect to all targets on startup,
that did _not_ work. So apparently the auto connect doesn't use the
blanket node login mechanism or some such. Any thoughts or flames
are appreciated :P
Thanks again!
--- snip ---
[EMAIL PROTECTED]:~$ sudo iscsiadm -m discovery
10.0.0.11:3260 via sendtargets
[EMAIL PROTECTED]:~$ sudo iscsiadm -m node
10.0.0.11:3260,1 ign.2002-07.com.archose:3t.r5.0
Normally the name of the target starts with iqn. A Q instead of
a G like above. Below you use a Q, which is probably why it is
not working. Sometimes you also drop parts of the name.
[EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T
iqn.2002-07.com.archose:3t.r5.0 -p 10.0.0.11:3260 -l
If the target has a G in the node db, then you need to pass it a
G here. This has a Q in the iqn.
iscsiadm: no records found!
[EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T iqn.2002-07.com.archose -p
This one will not work because it is misspelled. It is missing the
end part :3t.r5.0, and you need to use a G like in the node db.
10.0.0.11:3260 -l
iscsiadm: no records found!
[EMAIL PROTECTED]:~$ sudo iscsiadm -m discovery -P 1
SENDTARGETS:
DiscoveryAddress: 10.0.0.11,3260
Target: ign.2002-07.com.archose:3t.r5.0
Portal: 10.0.0.11:3260,1
Iface Name: default
iSNS:
No targets found.
STATIC:
No targets found.
[EMAIL PROTECTED]:~$ sudo iscsiadm -m session -P 1
Re: iscsiadm login issues?
Ben Lake wrote:
#sudo iscsiadm -m node -L automatic
Login session [iface: default, target: ign.2002-07.com.archose:3t.r5.0,
portal: 10.0.0.11,3260]
Distro: Ubuntu 8.04.01
init snippet
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/iscsid
ADM=/usr/bin/iscsiadm
PIDFILE=/var/run/iscsid.pid
...
start() {
log_daemon_msg Starting iSCSI initiator service iscsid
sanitychecks
modprobe -q iscsi_tcp 2/dev/null || :
modprobe -q ib_iser 2/dev/null || :
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
RETVAL=$?
log_end_msg $RETVAL
starttargets
}
starttargets() {
log_daemon_msg Setting up iSCSI targets
echo
$ADM -m node --loginall=automatic
log_end_msg 0
}
...
end init snippet
#whereis iscsiadm
iscsiadm: /usr/bin/iscsiadm /usr/share/man/man8/iscsiadm.8.gz
Looks like $ADM -m node --loginall=automatic is the line being used to
login to all the targets, perhaps not quite what we want?
This:
$ADM -m node --loginall=automatic
is just short for the command I had you run by hand:
iscsiadm -m node -L automatic
What is the output of
iscsiadm -m node -T ign.2002-07.com.archose:3t.r5.0 | grep node.startup
Mike Christie wrote:
Ben Lake wrote:
How is using the discovery command automatic if I still need to
specify all the details for each target?
All I said below is that you can run the command without having to set
the startup and it will log in. And I meant it will log in when you
run the command. Sorry for bad description.
With the command below you do not have to run the discovery command
and the login command. It is helpful for scrtips that just want to log
into whatever is found during discovery instead of doing the node db
route. A lot of times you have a discovery address where multiple
targets with multiple ports are found, so it is useful to see for that
type of case. If you have to do discovery for each target then yeah,
there is not much point except saving one command.
Anyway, I'm primarily concerned with why, on startup, it does not
login when the conf is set to automatic. It spits out the no records
found message as if it spelled things wrong :) Anything I can do to
troubleshoot that?
What distro and init script are you running?
Run
iscsiadm -m node -L automatic
Does that work? If not run it with debugging
iscsiadm -m node -L automatic -d 8
and send all the output.
Mike Christie wrote:
Ben Lake wrote:
Hah! Sometimes all it takes is another set of eyes. Score one for
obvious. Thanks Mike.
As far as the automatic login, I did set it in the conf. Then I
logged out of the target and restarted the service. It said
Logging into targets or something similar and then spit out the
no records found message.
So I assumed my issues were all related. We know that isn't the
case :)
You said something about using discovery mode to automatically login?
Not me.
like iscsiadm -m discovery -l? Would that not work regardless of
the config setting?
It should. It is
iscsiadm -m discovery -t st -p ip -l
Thanks again!
Mike Christie wrote:
Ben Lake wrote:
Hello all,
Before I ask anything I'd like to say thank you to all the devs.
I appreciate the existence of your project and your hard work!
Now I've got a little situation which should hopefully be chalked
up to my newb status with open-iscsi.
Per the snippet below I can't seem to manually login directly to
a single target. Every time I try I get iscsiadm: no records
found!. Whether I use the target name, portal, or both. As you
can see I have a discovery entry for the portal, and I have a
target entry in the node table. The only way I can login to this
target is with a blanket node login. It does work. The other
interesting bit is when I set the config to auto connect to all
targets on startup, that did _not_ work. So apparently the auto
connect doesn't use the blanket node login mechanism or some
such. Any thoughts or flames are appreciated :P
Thanks again!
--- snip ---
[EMAIL PROTECTED]:~$ sudo iscsiadm -m discovery
10.0.0.11:3260 via sendtargets
[EMAIL PROTECTED]:~$ sudo iscsiadm -m node
10.0.0.11:3260,1 ign.2002-07.com.archose:3t.r5.0
Normally the name of the target starts with iqn. A Q instead
of a G like above. Below you use a Q, which is probably why it
is not working. Sometimes you also drop parts of the name.
[EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T
iqn.2002-07.com.archose:3t.r5.0 -p 10.0.0.11:3260 -l
If the target has a G in the node db, then you need to pass it a
G here. This has a Q in the iqn.
iscsiadm: no records found!
[EMAIL PROTECTED]:~$ sudo iscsiadm -m node -T
iqn.2002-07.com.archose -p
This one will not work because it is misspelled. It is missing the
end part :3t.r5.0, and you need to use a G like in the node db.
10.0.0.11:3260
Re: iscsiadm login issues?
#sudo iscsiadm -m node -T ign.2002-07.com.archose:3t.r5.0 | grep
node.startup
node.startup = automatic
Frak. It worked this time!
#sudo /etc/init.d/open-iscsi stop
* Disconnecting iSCSI targets
...done.
* Stopping iSCSI initiator service
...done.
#sudo /etc/init.d/open-iscsi start
* Starting iSCSI initiator service iscsid
...done.
* Setting up iSCSI targets
Login session [iface: default, target: ign.2002-07.com.archose:3t.r5.0,
portal: 10.0.0.11,3260]
...done.
The only thing I've done since I changed the conf was reboot for some
hardware swapping. For reference, after I change the conf I logged out
of the target(s) and did a stop/start and it didn't fly. Not sure why
the reboot would have effected this, but the service seems to be working
as expected now.
Thanks for the help man, sorry it wasn't more of an actual issue :)
Mike Christie wrote:
Ben Lake wrote:
#sudo iscsiadm -m node -L automatic
Login session [iface: default, target: ign.2002-07.com.archose:3t.r5.0,
portal: 10.0.0.11,3260]
Distro: Ubuntu 8.04.01
init snippet
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/iscsid
ADM=/usr/bin/iscsiadm
PIDFILE=/var/run/iscsid.pid
...
start() {
log_daemon_msg Starting iSCSI initiator service iscsid
sanitychecks
modprobe -q iscsi_tcp 2/dev/null || :
modprobe -q ib_iser 2/dev/null || :
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
RETVAL=$?
log_end_msg $RETVAL
starttargets
}
starttargets() {
log_daemon_msg Setting up iSCSI targets
echo
$ADM -m node --loginall=automatic
log_end_msg 0
}
...
end init snippet
#whereis iscsiadm
iscsiadm: /usr/bin/iscsiadm /usr/share/man/man8/iscsiadm.8.gz
Looks like $ADM -m node --loginall=automatic is the line being used to
login to all the targets, perhaps not quite what we want?
This:
$ADM -m node --loginall=automatic
is just short for the command I had you run by hand:
iscsiadm -m node -L automatic
What is the output of
iscsiadm -m node -T ign.2002-07.com.archose:3t.r5.0 | grep node.startup
Mike Christie wrote:
Ben Lake wrote:
How is using the discovery command automatic if I still need to
specify all the details for each target?
All I said below is that you can run the command without having to set
the startup and it will log in. And I meant it will log in when you
run the command. Sorry for bad description.
With the command below you do not have to run the discovery command
and the login command. It is helpful for scrtips that just want to log
into whatever is found during discovery instead of doing the node db
route. A lot of times you have a discovery address where multiple
targets with multiple ports are found, so it is useful to see for that
type of case. If you have to do discovery for each target then yeah,
there is not much point except saving one command.
Anyway, I'm primarily concerned with why, on startup, it does not
login when the conf is set to automatic. It spits out the no records
found message as if it spelled things wrong :) Anything I can do to
troubleshoot that?
What distro and init script are you running?
Run
iscsiadm -m node -L automatic
Does that work? If not run it with debugging
iscsiadm -m node -L automatic -d 8
and send all the output.
Mike Christie wrote:
Ben Lake wrote:
Hah! Sometimes all it takes is another set of eyes. Score one for
obvious. Thanks Mike.
As far as the automatic login, I did set it in the conf. Then I
logged out of the target and restarted the service. It said
Logging into targets or something similar and then spit out the
no records found message.
So I assumed my issues were all related. We know that isn't the
case :)
You said something about using discovery mode to automatically login?
Not me.
like iscsiadm -m discovery -l? Would that not work regardless of
the config setting?
It should. It is
iscsiadm -m discovery -t st -p ip -l
Thanks again!
Mike Christie wrote:
Ben Lake wrote:
Hello all,
Before I ask anything I'd like to say thank you to all the devs.
I appreciate the existence of your project and your hard work!
Now I've got a little situation which should hopefully be chalked
up to my newb status with open-iscsi.
Per the snippet below I can't seem to manually login directly to
a single target. Every time I try I get iscsiadm: no records
found!. Whether I use the target name, portal, or both. As you
can see I have a discovery entry for the portal, and I have a
target entry in the node table. The only way I can login to this
target is with a blanket node login. It does work. The other
interesting bit is when I set the config to auto connect to all
targets on startup, that did _not_ work. So apparently the auto
connect doesn't use the blanket node login mechanism or some
such. Any thoughts or flames are appreciated :P
Thanks again!
--- snip ---
[EMAIL PROTECTED]:~$
Re: [LIST:open-iscsi] SAN
I have done something similar in a home-rolled SAN, and am fairly pleased with the results. I wasn't sure from your post if you were looking to build the in-band virtualization, or if you you had a switch that was capable of doing that. I could not afford a specialized iscsi-switch, so I used stock ethernet switches and built my own in-band virtualization system. Hopefully my experience can be of some use to you. I use IET (iSCSI Enterprise Target) on boxes with internal disk arrays to make 4 iscsi targets. Then I connect this across bonded interfaces and twp IP fabrics to an in-band virtualizer (two, actually, running in fail-over mode). The job of this virtualizer is similar to what you are looking for, I think. Our virtualizer acts as an iscsi initiator to the 4 iscsi target devices, and joins them into one large raid5 device. I then use LVM to carve out the virtual disks, and present them as iscsi targets to other systems. If you did the same thing with raid1 (mirrored) targets, then an iscsi request would read in a round-robin fashion from the two in-sync targets at your remote locations. The problem that I ran into was in keeping performance high. You end up passing the data through a lot of layers (hardware-iscsi-multipath-software raid-lvm-iscsi-multipath-OS). If you want to ENSURE that your data lands safely on the disk, then you have to turn off the software caching along the way, and this really hurt my performance. I now run with caching enabled in the virtualizer iscsi target, and performance is much better. But if you do that you need to make sure that your virtualizer does not crash, or you will loose the dirty blocks in the cache. I was looking for a generalized solution to hook to many different servers. If you are only dealing with one application then you should be able to get pretty good performance by careful tuning. The good side of going in-band is that it is generally easier and less invasive, since there are no agents to install in every OS to manage the out-of-band controls. But the downside is that all your data must flow through the in-band system and that can slow things down. Now, if you are looking at doing this inside of an iscsi-capable switch, then the same issues apply. An iscsi-capable switch is like my setup, but they have wrapped my virtualizer and my stock ethernet switches into one device (which is far more specialized than my generic devices). You still should look at how they handle caching in the switch, and how well you can tune and protect that. One other thought -- is this necessary? If you are just looking to read off of two iscsi targets that have the same data, then it might be simpler just to connect your server to the two iscsi targets in the SAN and use raid/multipath. That should take the OS system call to read the data, and split that into iscsi commands that pull from each of the targets. This takes some setup on the server, but it would be much simpler! -Ty! varun wrote: I am thinking of a design to improve performance of SAN. To do this i am thinking of an in band switch based virtualization which recieves an ISCSI request and splits the request into two and simultaneously reads data from two insync disk at remote locations. tell me is this solution feasible !! and i want software based solution with minimum hardware involvement ! tell me how out of band storage virtualization can help me in this ?? -- -===- Ty! Boyack NREL Unix Network Manager [EMAIL PROTECTED] (970) 491-1186 -===- --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Build problems with 869.2
On Aug 26, 6:23 am, Erez Zilber [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 11:20 AM, v42bis [EMAIL PROTECTED] wrote: Just saw the thread about rhel5 symbol problems, which seems to be my issue. Tried to apply the patch from Erez to 869.2 source, but it failed :( Try the attached patch. Erez Add-compat-patch-for-RHEL-5.2.patch Thanks, Erez. That patch worked on 869.2. I am getting some warnings on boot/module load: Starting iSCSI initiator service: iscsidLoading iSCSI transport class v2.0-869. iscsi: registered transport (tcp) ib_iser: disagrees about version of symbol iscsi_conn_setup ib_iser: Unknown symbol iscsi_conn_setup ib_iser: disagrees about version of symbol iscsi_verify_itt ib_iser: Unknown symbol iscsi_verify_itt ib_iser: disagrees about version of symbol iscsi_session_recovery_timedout ib_iser: Unknown symbol iscsi_session_recovery_timedout ib_iser: disagrees about version of symbol iscsi_conn_bind ib_iser: Unknown symbol iscsi_conn_bind ib_iser: disagrees about version of symbol class_to_transport_session ib_iser: Unknown symbol class_to_transport_session ib_iser: disagrees about version of symbol iscsi_conn_failure ib_iser: Unknown symbol iscsi_conn_failure ib_iser: disagrees about version of symbol iscsi_complete_pdu ib_iser: Unknown symbol iscsi_complete_pdu ib_iser: disagrees about version of symbol iscsi_register_transport ib_iser: Unknown symbol iscsi_register_transport ib_iser: disagrees about version of symbol iscsi_set_param ib_iser: Unknown symbol iscsi_set_param ib_iser: disagrees about version of symbol iscsi_conn_get_param ib_iser: Unknown symbol iscsi_conn_get_param ib_iser: disagrees about version of symbol iscsi_conn_teardown ib_iser: Unknown symbol iscsi_conn_teardown ib_iser: disagrees about version of symbol iscsi_session_get_param ib_iser: Unknown symbol iscsi_session_get_param ib_iser: disagrees about version of symbol iscsi_conn_send_pdu ib_iser: Unknown symbol iscsi_conn_send_pdu ib_iser: disagrees about version of symbol iscsi_conn_start ib_iser: Unknown symbol iscsi_conn_start ib_iser: disagrees about version of symbol iscsi_prep_unsolicit_data_pdu ib_iser: Unknown symbol iscsi_prep_unsolicit_data_pdu ib_iser: disagrees about version of symbol iscsi_free_mgmt_task ib_iser: Unknown symbol iscsi_free_mgmt_task ib_iser: Unknown symbol iscsi_session_setup2 ib_iser: disagrees about version of symbol iscsi_session_teardown ib_iser: Unknown symbol iscsi_session_teardown ib_iser: disagrees about version of symbol iscsi_unregister_transport ib_iser: Unknown symbol iscsi_unregister_transport ib_iser: disagrees about version of symbol iscsi_conn_stop ib_iser: Unknown symbol iscsi_conn_stop . Setting up iSCSI targets:iscsiadm: No records found! Any idea what might cause this? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
