Re: crc32 option detection?
On 28 November 2011 05:58, Mike Christie micha...@cs.wisc.edu wrote: On 11/27/2011 10:56 PM, Mike Christie wrote: On 11/27/2011 05:00 PM, Michal Suchanek wrote: I use open-iscsi form Debian: 2.0.871.3-2squeeze1. There is a package of later version which does not work at all. Apparently iet allows None even when set to CRC32C but istgt only allows the value set in config. Can't help much there. You would have to take that up on the IET and tgt lists. I am not sure how to configure them. Just to make sure I understand you though. You are saying for open-iscsi you need to change the default setting from None (there is nothing I can do for that except change the default value in the code I guess), and you are saying some of the targets might not be doing the right thing, right? Both. open-iscsi should be able to negotiate crc32 when the target insists, and iet should insist on crc32 when specified in the config. Thanks Michal -- 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?hl=en.
crc32 option detection?
Hello, I configured my target with crc32 option and open-iscsi would not connect to it. More specifically, I tried iscsitarget (iet) first which accepted the connection without crc although it was specified in the config but when I replaced it with istgt I could not connect anymore. Shouldn't this be detected automagically? Thanks Michal -- 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?hl=en.
Re: crc32 option detection?
On 27 November 2011 22:14, Mike Christie micha...@cs.wisc.edu wrote: On 11/27/2011 02:28 PM, Michal Suchanek wrote: Hello, I configured my target with crc32 option and open-iscsi would not connect to it. More specifically, I tried iscsitarget (iet) first which accepted the connection without crc although it was specified in the config but when I replaced it with istgt I could not connect anymore. Shouldn't this be detected automagically? It depends on what value you used for the digest option on the target and initiator. For header digests the initiator has the node.conn[0].iscsi.HeaderDigest option. You can set this to: CRC32C or CRC32C,None or None or None,CRC32C On the target you have similar option values. It depends on what you set on the initiator and target to determine the behavior. If you set the target digests values the same then there might be a bug. I set the target to CRC32C and open-iscsi insists on using None unless manually changed. I use open-iscsi form Debian: 2.0.871.3-2squeeze1. There is a package of later version which does not work at all. Apparently iet allows None even when set to CRC32C but istgt only allows the value set in config. Thanks Michal -- 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?hl=en.
Re: Problem diagnosing iscsi failure on the initiator
On 16 June 2010 05:31, Mike Christie micha...@cs.wisc.edu wrote: On 06/14/2010 08:52 AM, Michal Suchanek wrote: On 13 June 2010 21:01, Mike Christiemicha...@cs.wisc.edu wrote: On 06/12/2010 06:31 AM, Michal Suchanek wrote: Hello I tried to get an iscsi setup working so I installed iscsitarget and open-iscsi and tried to export a file as an iSCSI lun. After doing so I could log in with iscsiadm but I would not get any disks on the initiator. Later I discovered that I had a typo in the ietd.conf file and the lun was simply not exported giving a target with no luns available for the initiator. While it is true that the error is logged in kernel logs on the target machine I could not find any way to list the available luns on the iscsiadm -m session -P 3 Thanks, this command does print the luns if there are any. However, it is not obvious from the documentation that it should print these nor is it obvious from the output that there some part missing when no luns are available. In the README I will add more info on how -P X works for session mode. It also does not work when I just add -P 3 to the discovery and node commands which I use to log into the target and there is no obvious reason why it should not. Discovery mode just finds targets and portals. It has nothing to do with LUN discovery normally. And the node mode commands that print out the node db info also just prints the target and portal info, because it is only concerned with the targets. If for discovery and node mode, you are logging into the target (using the --login command) then I can print out the LUNs found if that is what you are asking for. But normally with the discovery and node mode commands that use the -P operator we are just working on the targets and portals and have not logged into the target so we do not know if there are LUNs. The thing is that it is not documented what the -P option actually does. Apparently it slightly changes the output format of discover and node modes when nonzero but prints gobs of information in session mode when nonzero and even more when it is 2 or3. So I would really appreciate a short note in the man page what value of P selects what information in what mode like: When non-zero the output in discovery, node or session mode is printed in tree-like format. In session mode 1 prints interfaces 2 also prints parameters and 3 also prints devices. Thanks Michal -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Re: Problem diagnosing iscsi failure on the initiator
On 13 June 2010 21:01, Mike Christie micha...@cs.wisc.edu wrote: On 06/12/2010 06:31 AM, Michal Suchanek wrote: Hello I tried to get an iscsi setup working so I installed iscsitarget and open-iscsi and tried to export a file as an iSCSI lun. After doing so I could log in with iscsiadm but I would not get any disks on the initiator. Later I discovered that I had a typo in the ietd.conf file and the lun was simply not exported giving a target with no luns available for the initiator. While it is true that the error is logged in kernel logs on the target machine I could not find any way to list the available luns on the iscsiadm -m session -P 3 Thanks, this command does print the luns if there are any. However, it is not obvious from the documentation that it should print these nor is it obvious from the output that there some part missing when no luns are available. It also does not work when I just add -P 3 to the discovery and node commands which I use to log into the target and there is no obvious reason why it should not. Thanks Michal -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Problem diagnosing iscsi failure on the initiator
Hello I tried to get an iscsi setup working so I installed iscsitarget and open-iscsi and tried to export a file as an iSCSI lun. After doing so I could log in with iscsiadm but I would not get any disks on the initiator. Later I discovered that I had a typo in the ietd.conf file and the lun was simply not exported giving a target with no luns available for the initiator. While it is true that the error is logged in kernel logs on the target machine I could not find any way to list the available luns on the initiator. Should the target be hard to access or a piece of dedicated hardware rather than a software service it would be really hard to diagnose. Even when it is possible to look at the target logs it is generally good to have diagnostics on both sides so that any issues are easier to discover. Also it should be possible to verify that the reported state matches on both ends. Thanks Michal -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
