Resolved: CHAP login with HP mpx100
Hi all, finally I managed to login to a HP mpx100 bridge with CHAP enabled. Turned out that the HP is not using a CHAP username at all, just the password. So we need to tweak open-iscsi to allow empty usernames. Patch to follow. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
building from source fails on custom cloud/xen kernel.
I'm trying to build the open-iscsi module for a xen kernel provided by 3Tera/Applogic (based on CentOS 5.1 I believe). I have the kernel source from the vendor and I'm not sure if I'm doing this right. Here is the command I'm running: # make KSRC=/root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg \ KBUILD_OUTPUT=/root/rpm/BUILD/xen-3.2.2-src/build-linux-2.6.18- xenU_x86_32 make -C utils/fwparam_ibft make[1]: Entering directory `/root/open-iscsi-2.0-870.3/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 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-870.3/utils/ fwparam_ibft' make -C usr make[1]: Entering directory `/root/open-iscsi-2.0-870.3/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:334: 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 iface.o iface.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 sysdeps.o sysdeps.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o sysfs.o sysfs.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 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 mgmt_ipc.c: In function ‘event_loop’: mgmt_ipc.c:645: warning: implicit declaration of function ‘sysfs_cleanup’ 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 iface.o idbm.o sysdeps.o sysfs.o iscsi_sysfs.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 strings.c: In function ‘enlarge_data’: strings.c:83: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 3 has type ‘size_t’ strings.c:83: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 4 has type ‘size_t’ 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 iface.o idbm.o sysdeps.o sysfs.o iscsi_sysfs.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
Re: Cannot build new open-iscsi in Suse 10 SP2
I'm getting the same messages when I try to build on my CentOS VM running a Xen Kernel. On Sep 15, 9:39 pm, Liming guard@gmail.com wrote: I tried to build new open-iscsi(2.0-871) in Suse 10 SP2 but it failed. I got some error message. The kernel version is 2.6.16-60. Do any one know how to fix it?? goddard-suse:/home/guardkuo/open-iscsi-2.0-865 # make KSRC=/usr/src/ linux KBUILD_OUTPUT=/usr/src/linux-obj/i386/smp make -C usr make[1]: Entering directory `/home/guardkuo/open-iscsi-2.0-865/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 io.c:86: warning: ‘get_hwaddress_from_netdev’ defined but not used 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 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 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 queue.o actor.o mgmt_ipc.o isns.o transport.o iscsistart.o statics.o -o iscsistart login.o: In function `resolve_address': /home/guardkuo/open-iscsi-2.0-865/usr/login.c:168: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking make[1]: Leaving directory `/home/guardkuo/open-iscsi-2.0-865/usr' make -C kernel make[1]: Entering directory `/home/guardkuo/open-iscsi-2.0-865/kernel' echo Patching source code for linux-2.6.16-18 ... Patching source code for linux-2.6.16-18 ... if [ -e cur_patched ]; then \ make -C . clean; \ fi patch -p1 2.6.16-18_compat.patch patching file iscsi_2.6.20_compat.h patching file iscsi_tcp.h Hunk #1 succeeded at 52 (offset 3 lines). patching file libiscsi.c Hunk #1 succeeded at 760 (offset 44 lines). Hunk #2 succeeded at 1527 (offset 19 lines). patching file libiscsi.h patching file scsi_transport_iscsi.c patching file scsi_transport_iscsi.h Hunk #1 succeeded at 182 (offset 6 lines). cp 2.6.16-18_compat.patch has_16to18_patch ln -s has_16to18_patch cur_patched make -C /usr/src/linux M=`pwd` KBUILD_OUTPUT=/usr/src/linux-obj/i386/ smp V=0 modules make[2]: Entering directory `/usr/src/linux-2.6.16.60-0.21' CC [M] /home/guardkuo/open-iscsi-2.0-865/kernel/ scsi_transport_iscsi.o CC [M] /home/guardkuo/open-iscsi-2.0-865/kernel/libiscsi.o CC [M] /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_tcp.o In file included from /home/guardkuo/open-iscsi-2.0-865/kernel/ iscsi_tcp.h:55, from /home/guardkuo/open-iscsi-2.0-865/kernel/ iscsi_tcp.c:45: /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:4: error: redefinition of ‘struct hash_desc’ /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:10: error: redefinition of ‘crypto_hash_init’ /usr/src/linux-2.6.16.60-0.21/include/linux/crypto.h:949: error: previous definition of ‘crypto_hash_init’ was here /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h: In function ‘crypto_hash_init’: /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:11: error: implicit declaration of function ‘crypto_digest_init’ /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h: At top level: /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:18: error: redefinition of ‘crypto_hash_digest’ /usr/src/linux-2.6.16.60-0.21/include/linux/crypto.h:968: error: previous definition of ‘crypto_hash_digest’ was here /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h: In function ‘crypto_hash_digest’: /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:19: error: implicit declaration of function ‘crypto_digest_digest’ /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h: At top level: /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:26: error: redefinition of ‘crypto_hash_update’ /usr/src/linux-2.6.16.60-0.21/include/linux/crypto.h:956: error: previous definition of ‘crypto_hash_update’ was here /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h: In
Re: Intel NIC iSCSI acceleration in Linux and open-iscsi
Yes, what details do you require ? On Sat, Sep 26, 2009 at 4:49 AM, Pasi Kärkkäinen pa...@iki.fi wrote: Hello, Is anyone working on Linux/open-iscsi iSCSI offloading/acceleration using Intel gigabit and 10 gigabit NICs? -- Pasi --~--~-~--~~~---~--~~ 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: [PATCH] Allow empty username for CHAP
On 09/29/2009 08:46 AM, Hannes Reinecke wrote: Some iSCSI implementations (eg HP) is using an empty username for CHAP negotiations. So we should be allowing the same. Do we need this support for discovery? There is one other one auth setup function in discovery.c:setup_authentication(). Not sure why we have two almost identical functions there. Probably due to how it is all compiled. Do not worry about the duplication in this patch. We can just fix up discovery.c:setup_authentication(). Can you have a empty incoming username? If so I think we need to modify acl_chap_auth_request like how you did to acl_set_user_name. --~--~-~--~~~---~--~~ 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: SCSI pass through command cause iscsi Conn error
On 09/26/2009 09:20 PM, niko scsi wrote: I followed the howto http://tldp.org/HOWTO/SCSI-Generic-HOWTO/scsi_snd_cmd.html to pass through scsi cmd with data (self defined,target can handle it) to iscsi disk. however,the request was handled six times ,I checked the log ,the reason is shown below. The connection failed and recovered six times ,and I tested many times ,each time ,the same :six times! I'm newbie to scsi program. Any idea that can cause this problem ? error occurred in function iscsi_data_rsp tcp debug infomations show below : ... Sep 27 09:37:01 localhost kernel: tcp: skb dfab65c0 ptr=da5a5a54 avail=60 Sep 27 09:37:01 localhost kernel: tcp: copied 0 0 size 48 recv Sep 27 09:37:01 localhost kernel: tcp: iscsi_tcp_segment_recv copying 48 Sep 27 09:37:01 localhost kernel: tcp: copied 0 48 size 48 recv Sep 27 09:37:01 localhost kernel: tcp: iscsi_tcp_segment_unmap cb76be10 Sep 27 09:37:01 localhost kernel: tcp: total copied 48 total size 48 Sep 27 09:37:01 localhost kernel: tcp: segment done Sep 27 09:37:01 localhost kernel: tcp: opcode 0x25 ahslen 0 datalen 12 Sep 27 09:37:01 localhost kernel: tcp: iscsi_data_rsp: ctask- exp_datasn(1) != rhdr-datasn(0) You might not be doing anything wrong. It might a target or initiator bug. What target are you using? In your setup, did you modify the iscsi target in some way? And what kernel are using? --~--~-~--~~~---~--~~ 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: connection error kills iscsi session
On 09/28/2009 09:39 AM, Drew Morris wrote: Mike, Thanks for your prompt/detailed reply. Vtrak is an iscsi disk array, which unfortunately doesn't seem to be reporting any errors. Is there any sort of debugging I could do to discern what the cause of the problem is? I'm pretty sure it's not a pulled cable, but either the target or the initiator dropping the connection for some reason... What sort of invalid data would cause the initiator to drop the connection? There are no errors about pings or nops. The fragment I sent was the beginning of the problem. Can the verbosity of the iscsi messages be increased? Are you using the kernel modules and tools from open-iscsi.org? If so, each iscsi module has a mod param that can used to turn on different debugging. You can also set it through sysfs like so: echo 1 /sys/module/libiscsi/parameters/debug_libiscsi_conn echo 1 /sys/module/libiscsi/parameters/debug_libiscsi_session echo 1 /sys/module/libiscsi/parameters/debug_libiscsi_eh echo 1 /sys/module/iscsi_tcp/parameters/debug_iscsi_tcp echo 1 /sys/module/libiscsi_tcp/parameters/debug_libiscsi_tcp This turns on all the logging, so if you run IO it will be a lot of info. You probably just want to turn all this on when not doing any reads/writes. That way we will just get what causes the initial conn error. --~--~-~--~~~---~--~~ 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: building from source fails on custom cloud/xen kernel.
On 09/28/2009 03:04 PM, Xenophod wrote: I'm trying to build the open-iscsi module for a xen kernel provided by 3Tera/Applogic (based on CentOS 5.1 I believe). I have the kernel source from the vendor and I'm not sure if I'm doing this right. Here is the command I'm running: # make KSRC=/root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg \ KBUILD_OUTPUT=/root/rpm/BUILD/xen-3.2.2-src/build-linux-2.6.18- xenU_x86_32 make -C /root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg M=`pwd` KBUILD_OUTPUT=/root/rpm/BUILD/xen-3.2.2-src/build-linux-2.6.18- xenU_x86_32 V=0 modules make[2]: Entering directory `/root/rpm/BUILD/xen-3.2.2-src/ linux-2.6.18-xen.hg' CC [M] /root/open-iscsi-2.0-870.3/kernel/scsi_transport_iscsi.o In file included from /root/open-iscsi-2.0-870.3/kernel/ scsi_transport_iscsi.h:34, from /root/open-iscsi-2.0-870.3/kernel/ scsi_transport_iscsi.c:33: /root/open-iscsi-2.0-870.3/kernel/open_iscsi_compat.h:190: error: redefinition of ‘shost_priv’ /root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg/include/scsi/ scsi_host.h:644: error: previous definition of ‘shost_priv’ was here /root/open-iscsi-2.0-870.3/kernel/open_iscsi_compat.h:218: error: redefinition of ‘scsi_set_resid’ /root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg/include/scsi/ scsi_cmnd.h:150: error: previous definition of ‘scsi_set_resid’ was here /root/open-iscsi-2.0-870.3/kernel/open_iscsi_compat.h:223: error: redefinition of ‘scsi_get_resid’ /root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg/include/scsi/ scsi_cmnd.h:155: error: previous definition of ‘scsi_get_resid’ was here /root/open-iscsi-2.0-870.3/kernel/scsi_transport_iscsi.c: In function ‘__iscsi_unblock_session’: /root/open-iscsi-2.0-870.3/kernel/scsi_transport_iscsi.c:551: warning: unused variable ‘ihost’ make[4]: *** [/root/open-iscsi-2.0-870.3/kernel/ scsi_transport_iscsi.o] Error 1 make[3]: *** [_module_/root/open-iscsi-2.0-870.3/kernel] Error 2 make[2]: *** [modules] Error 2 make[2]: Leaving directory `/root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18- xen.hg' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/open-iscsi-2.0-870.3/kernel' make: *** [all] Error 2 I've tried this with both open-iscsi-2.0-870.3 and open-iscsi-2.0-871 sources and I get the same results. Is there something I'm doing wrong? Am I missing some tools that I should get through yum? The open-iscsi kernel build code supports upstream kernels and in some cases where someone modified the core patches to support it some specific red hat kernels. It does not support other vendor kernels well, because we have no idea what is in there, or the build system is not smart enough to figure out what is going on, or because I messed up on the compat code and did not make it generic enough. --~--~-~--~~~---~--~~ 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: Intel NIC iSCSI acceleration in Linux and open-iscsi
On Mon, Sep 28, 2009 at 08:50:57PM -0700, Meenakshi Ramamoorthi wrote: Yes, what details do you require ? Well.. what's the status? Is the code available from somewhere? Can I test it? :) I haven't seen anything on open-iscsi list.. at least I can't remember. Thanks! -- Pasi On Sat, Sep 26, 2009 at 4:49 AM, Pasi Kärkkäinen [1]pa...@iki.fi wrote: Hello, Is anyone working on Linux/open-iscsi iSCSI offloading/acceleration using Intel gigabit and 10 gigabit NICs? -- Pasi References Visible links 1. mailto:pa...@iki.fi --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
SD Driver incrementing on every snapshot.
Group, I'm using linux to backup an ISCSI target. My backup script calls the snapshot function on my iscsi server, then uses open-iscsi to connect to a snapshot target on that server. The target is backed up, then I logoff the target until the next backup. The problem is that the scsi device number in linux keeps incrementing: scsi13 : iSCSI Initiator over TCP/IP scsi14 : iSCSI Initiator over TCP/IP scsi15 : iSCSI Initiator over TCP/IP Is this cause for concern? Will it quit on me at some point? Is there a way to make open-iscsi reuse an old scsi device number? Thanks, schu --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
