Re: open-iscsi: iSCSI boot fails when network bonding enabled

[Konrad Rzeszutek Wilk]

On Mon, Jul 10, 2017 at 05:57:57AM -0700, George Kennedy wrote:
> Also, 'iscsid' is runnig prior to the bond interface setup.

If you run it as 'iscsid -d ' do you see any extra output when the
network interface goes down?

Thanks.
> 
> On Friday, July 7, 2017 at 2:33:29 PM UTC-4, George Kennedy wrote:
> >
> > Running RHEL 6.7 with a Xen guest that's an iSCSI target and a second Xen 
> > guest that
> > installs to the iSCSI target, the subsequent iSCSI boot from the iSCSI 
> > target fails
> > if network bonding is configured in the second Xen guest.
> >
> > iSCSI boot works ok if network bonding is not setup in the second Xen 
> > guest.
> >
> > It appears that when the network bonding setup is attempted, the slave 
> > network
> > interface cannot be brought down to be made the bonding slave because the 
> > iSCSI
> > rootfs is accessed through what would be the slave network interface.
> >
> > Has anyone else encountered this issue?
> >
> > Here's console output showing the error:
> >
> > Bringing up loopback interface:  [  OK  ]
> > Bringing up interface bond0:  
> > [   46.467963] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > [   46.484767] bonding: bond0 is being created...
> > [   46.490626] bonding: bond0 already exists
> > [   46.560601] bond0: Setting MII monitoring interval to 250
> > [   46.569844] bond0: Setting use_carrier to 1
> > [   46.574589] bond0: Setting up delay to 500
> > [   46.579601] bond0: Setting down delay to 500
> > [   46.584645] bond0: Setting primary_reselect to failure (2)
> > [   46.728908] bond0: Setting MII monitoring interval to 250
> > [   46.737620] bond0: Note: Updating updelay (to 500) since it is a 
> > multiple of the miimon value
> > [   46.749168] bond0: Note: Updating downdelay (to 500) since it is a 
> > multiple of the miimon value
> > [   46.759837] bond0: Setting use_carrier to 1
> > [   46.764687] bond0: Setting up delay to 500
> > [   46.769476] bond0: Setting down delay to 500
> > [   46.774468] bond0: Setting primary_reselect to failure (2)
> > [   47.090932] bond0: Adding slave eth0
> > [   47.131796] bond0: Enslaving eth0 as a backup interface with a down link
> > [   47.142334] bond0: Setting eth0 as primary slave
> > [   49.115135] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
> > Control: RX
> > [   49.289431] bond0: link status up for interface eth0, enabling it in 0 
> > ms
> > [   49.300463] bond0: link status definitely up for interface eth0, 1000 
> > Mbps full duplex
> > [   49.310302] bond0: making interface eth0 the new active one
> > [   49.331748] bond0: first active interface up!
> > [   56.684137]  connection1:0: ping timeout of 5 secs expired, recv 
> > timeout 5, last rx 4294713972, last ping 4294718976, now 4294723984
> > [   56.685064]  connection1:0: detected conn error (1022)
> > [  176.702085]  session1: session recovery timed out after 120 secs
> > [  176.709606] sd 2:0:0:1: rejecting I/O to offline device
> > [  176.710573] sd 2:0:0:1: [sda] killing request
> > [  176.710573] sd 2:0:0:1: rejecting I/O to offline device
> > [  176.710573] sd 2:0:0:1: rejecting I/O to offline device
> > ...
> >
> > Here's the original ifcfg file (there's only one):
> >
> > ifcfg-eth0:
> > ---
> > HWADDR="00:21:F6:00:08:FC"
> > DEVICE=eth0
> > TYPE=Ethernet
> > ONBOOT=yes
> > NM_CONTROLLED=yes
> > BOOTPROTO=dhcp
> >
> >
> > Here are the ifcfg files used for bonding (again only one network 
> > interface):
> >
> > ifcfg-eth0:
> > ---
> > DEVICE="eth0"
> > BOOTPROTO="none"
> > HWADDR="00:21:F6:00:08:FC"
> > MASTER="bond0"
> > SLAVE="yes"
> > NM_CONTROLLED="no"
> > ONBOOT="yes"
> >
> > ifcfg-bond0
> > ---
> > DEVICE=bond0
> > BONDING_OPTS="mode=1 miimon=250 use_carrier=1 updelay=500 downdelay=500 
> > primary_reselect=2 primary=eth0"
> > BOOTPROTO="dhcp"
> > ONBOOT=yes
> >
> >

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

[Konrad Rzeszutek Wilk]

On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote:
> 
> 
> On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote:
> > Interesting that you didn't CC any of the maintainers. Could you 
> > do that in the future please?
> 
> Please read the cover letter. The distribution list for the patchset
> would have been way too large to cc every maintainer (even as limited as
> it was, I had mailing lists yelling at me). My plan was to get buy in

I am not sure if you know, but you can add on each patch the respective
maintainer via 'CC'. That way you can have certain maintainers CCed only
on the subsystems they cover. You put it after (or before) your SoB and
git send-email happilly picks it up.

It does mean that for every patch you have to run something like this:

$ more add_cc 
#!/bin/bash

git diff HEAD^.. > /tmp/a
echo "---"
scripts/get_maintainer.pl --no-l /tmp/a | while read file
do
echo "Cc: $file"
done

Or such.


> for the first patch, get it merged and resend the rest independently to
> their respective maintainers. Of course, though, I'd be open to other
> suggestions.
> 
> >>>
> >>> Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
> >>> ---
> >>>  drivers/block/xen-blkfront.c | 33 +++--
> >>>  1 file changed, 27 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >>> index 5067a0a..7dcf41d 100644
> >>> --- a/drivers/block/xen-blkfront.c
> >>> +++ b/drivers/block/xen-blkfront.c
> >>> @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req, 
> >>> struct blkfront_ring_info *ri
> >>>   BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> >>>
> >>>   if (setup.need_copy) {
> >>> - setup.bvec_off = sg->offset;
> >>> - setup.bvec_data = kmap_atomic(sg_page(sg));
> >>> + setup.bvec_off = 0;
> >>> + setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
> >>> + if (IS_ERR(setup.bvec_data)) {
> >>> + /*
> >>> +  * This should really never happen unless
> >>> +  * the code is changed to use memory that is
> >>> +  * not mappable in the sg. Seeing there is a
> >>> +  * questionable error path out of here,
> >>> +  * we WARN.
> >>> +  */
> >>> + WARN(1, "Non-mappable memory used in sg!");
> >>> + return 1;
> >>> + }
> >> ...
> >>
> >> Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
> >> inside sg_map().
> 
> Thanks, that's a good suggestion. I'll make the change for v2.
> 
> Logan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

[Konrad Rzeszutek Wilk]

On Tue, Apr 18, 2017 at 02:13:59PM +, David Laight wrote:
> From: Logan Gunthorpe
> > Sent: 13 April 2017 23:05
> > Straightforward conversion to the new helper, except due to
> > the lack of error path, we have to warn if unmapable memory
> > is ever present in the sgl.

Interesting that you didn't CC any of the maintainers. Could you 
do that in the future please?

> > 
> > Signed-off-by: Logan Gunthorpe 
> > ---
> >  drivers/block/xen-blkfront.c | 33 +++--
> >  1 file changed, 27 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 5067a0a..7dcf41d 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req, 
> > struct blkfront_ring_info *ri
> > BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> > 
> > if (setup.need_copy) {
> > -   setup.bvec_off = sg->offset;
> > -   setup.bvec_data = kmap_atomic(sg_page(sg));
> > +   setup.bvec_off = 0;
> > +   setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
> > +   if (IS_ERR(setup.bvec_data)) {
> > +   /*
> > +* This should really never happen unless
> > +* the code is changed to use memory that is
> > +* not mappable in the sg. Seeing there is a
> > +* questionable error path out of here,
> > +* we WARN.
> > +*/
> > +   WARN(1, "Non-mappable memory used in sg!");
> > +   return 1;
> > +   }
> ...
> 
> Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
> inside sg_map().
> 
>   David
> 
> 
> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] iscsi_ibft,iscsi_boot: remove CAP_SYS_ADMIN restriction for reading entries

[Konrad Rzeszutek Wilk]

On Oct 4, 2016 12:11 PM, "Dan Williams"  wrote:
>
> On Tue, 2016-10-04 at 12:08 -0400, Peter Jones wrote:
> > On Tue, Oct 04, 2016 at 11:03:05AM -0500, Dan Williams wrote:
> > >
> > > All the iSCSI boot entries are read-only anyway; it's unclear why
> > > the
> > > CAP_SYS_ADMIN restriction is in place since this information isn't
> > > particularly sensitive and cannot be changed.  Userspace
> > > applications
> > > may want to read this without requiring CAP_SYS_ADMIN for their
> > > entire process just for iBFT info.
> > >
> > > Signed-off-by: Dan Williams 
> >
> > Uh, because there are login credentials to the target in there.
>
> Fair enough.  So can we just check CAP_SYS_ADMIN for the login
> credentials, and not check it for all the IP details and such?

The only consumer is iscsiadm - which runs as root. So why expose this
information to non root ?

>
> Dan
>
> > >
> > > ---
> > >  drivers/scsi/iscsi_boot_sysfs.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > >
> > > diff --git a/drivers/scsi/iscsi_boot_sysfs.c
> > > b/drivers/scsi/iscsi_boot_sysfs.c
> > > index d453667..4e9c324 100644
> > > --- a/drivers/scsi/iscsi_boot_sysfs.c
> > > +++ b/drivers/scsi/iscsi_boot_sysfs.c
> > > @@ -47,9 +47,6 @@ static ssize_t iscsi_boot_show_attribute(struct
> > > kobject *kobj,
> > > ssize_t ret = -EIO;
> > > char *str = buf;
> > >
> > > -   if (!capable(CAP_SYS_ADMIN))
> > > -   return -EACCES;
> > > -
> > > if (boot_kobj->show)
> > > ret = boot_kobj->show(boot_kobj->data, boot_attr-
> > > >type, str);
> > > return ret;
> > > --
> > > 2.7.4
> >

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 2/2] RFC: iscsi ibft: convert iscsi_ibft module to iscsi boot lib

[Konrad Rzeszutek Wilk]

On Monday 12 April 2010 14:06:18 you wrote:
 From: Mike Christie micha...@cs.wisc.edu

 This patch just converts the iscsi_ibft module to the
 iscsi boot sysfs lib module.

 This patch was made over the ibft-2.6 tree's ibft-1.03 branch:
 http://git.kernel.org/?p=linux/kernel/git/konrad/ibft-2.6.git;a=shortlog;h=
refs/heads/ibft-1.03

 Signed-off-by: Mike Christie micha...@cs.wisc.edu

I've only two comments:

.. snip..
  /*
 + * Helper routiners to check to determine if the entry is valid
 + * in the proper iBFT structure.
 + */
 +static mode_t ibft_check_nic_for(void *data, int type)
 +{
 + struct ibft_kobject *entry = data;
 + struct ibft_nic *nic = entry-nic;
 + mode_t rc = 0;
 +
 + switch (type) {
 + case ISCSI_BOOT_ETH_INDEX:
 + case ISCSI_BOOT_ETH_FLAGS:
 + rc = 1;

Did you mean for that value?
 + break;
 + case ISCSI_BOOT_ETH_IP_ADDR:
 + if (memcmp(nic-ip_addr, nulls, sizeof(nic-ip_addr)))
 + rc = S_IRUGO;
 + break;
 + case ISCSI_BOOT_ETH_SUBNET_MASK:
 + if (nic-subnet_mask_prefix)
 + rc = S_IRUGO;
 + break;
 + case ISCSI_BOOT_ETH_ORIGIN:
 + rc = 1;

and this one as well?

-- 
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: [PATCH 1/2] RFC: iscsi ibft: separate ibft parsing from sysfs interface

[Konrad Rzeszutek Wilk]

On Monday 12 April 2010 14:06:17 micha...@cs.wisc.edu wrote:
 From: Mike Christie micha...@cs.wisc.edu

 Not all iscsi drivers support ibft. For drivers like be2iscsi
 that do not but are bootable through a vendor firmware specific
 format/process this patch moves the sysfs interface from the ibft code
 to a lib module. This then allows userspace tools to search for iscsi boot
 info in a common place and in a common format.

 ibft iscsi boot info is exported in the same place as it was
 before: /sys/firmware/ibft.

 vendor/fw boot info gets export in /sys/firmware/iscsi_bootX, where X is
 the scsi host number of the HBA. Underneath these parent dirs, the
 target, ethernet, and initiator dirs are the same as they were before.

 This patch was made over the ibft-2.6 tree's ibft-1.03 branch:
 http://git.kernel.org/?p=linux/kernel/git/konrad/ibft-2.6.git;a=shortlog;h=
refs/heads/ibft-1.03


 Signed-off-by: Mike Christie micha...@cs.wisc.edu
 ---
Looks good to my eyes.

Let me run it tomorrow through my regression bucket before I stick on the git 
tree.

-- 
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: [PATCH 2/2] RFC: iscsi ibft: convert iscsi_ibft module to iscsi boot lib

[Konrad Rzeszutek Wilk]

On Monday 12 April 2010 22:32:33 Mike Christie wrote:
 On 04/12/2010 09:21 PM, Konrad Rzeszutek Wilk wrote:
  + * Helper routiners to check to determine if the entry is valid
  + * in the proper iBFT structure.
  + */
  +static mode_t ibft_check_nic_for(void *data, int type)
  +{
  +  struct ibft_kobject *entry = data;
  +  struct ibft_nic *nic = entry-nic;
  +  mode_t rc = 0;
  +
  +  switch (type) {
  +  case ISCSI_BOOT_ETH_INDEX:
  +  case ISCSI_BOOT_ETH_FLAGS:
  +  rc = 1;
 
  Did you mean for that value?
 
  +  break;
  +  case ISCSI_BOOT_ETH_IP_ADDR:
  +  if (memcmp(nic-ip_addr, nulls, sizeof(nic-ip_addr)))
  +  rc = S_IRUGO;
  +  break;
  +  case ISCSI_BOOT_ETH_SUBNET_MASK:
  +  if (nic-subnet_mask_prefix)
  +  rc = S_IRUGO;
  +  break;
  +  case ISCSI_BOOT_ETH_ORIGIN:
  +  rc = 1;
 
  and this one as well?

 I did not. They should be S_IRUGO. Do you want me to resubmit the
 patches or are you just going to edit those two lines if you merge them?

No need to resend them (unless Peter eyes found something I missed).

-- 
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: How does readahead(2) affects a iscsi device

[Konrad Rzeszutek]

On Fri, Jul 03, 2009 at 04:10:19PM +0200, Maddin wrote:
 
 Hi folks,
 
 Sorry but not so firm in kernel hacking and structures, but if I've
 understood this correctly it should perform normally?!
 The problem is that I do a readahead (the tool) on a iscsi device with
 infortrend iscsi san as backend to warm up caches and my connection died,
 correctly the whole controller died and have to be reseted.

Whoa! Have you filled a ticket with them?
 
 Has anyone an idea?

Sounds like a big bug in their product.
 
 Cheers
 Maddin
 
 
 
 
 
 

--~--~-~--~~~---~--~~
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: do we need a new list for kernel patches

[Konrad Rzeszutek]

  see what features are making progress?
  Does splitting the mailing list to userpace and kernel have merit?
  Thoughts ...
 
  
  
  Was this mail stuck in moderation?
  
 
 Yeah, not sure what happened, because you were using your dell account. 
 I just saw it today in the list of mail that needed review.

By my reckon of the e-mails about this, most people thought it best to
keep it as is. Meaning one reflector for userspace+kernel
issues/patches/etc.


--~--~-~--~~~---~--~~
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: RFC: do we need a new list for kernel patches

[Konrad Rzeszutek]

  I agree that having just one mailing list is the most convenient for
  kernel developers. But not everyone who is subscribed to open-iscsi is
  a kernel developer. Wouldn't it be more convenient for iSCSI users to
  have two lists -- one intended for iSCSI users, and one for iSCSI
  developers, such that the users can subscribe to the former only ?
  Just my two cents.
  
  Bart.
  
 
 From my experience this makes users loos on the Kernel guys.
 Kernel guys are busy, and mind their own business, but
 if a question comes up, which they know the answer they would
 occasionally participate. Splitting will loos that.

I think Bart is talking about two camps of users: developers (both
kernel and user-land), and those seeking help.
 
 I think iscsi mailing-list is not that big and still easy
 to monitor. Just set your mailer to view by thread, and
 it's easy to jump over threads that are not interesting.

I have to agree, Ctrl-D in mutt is wonderfull thing.
 
 My $0.017
 Boaz
 
 

--~--~-~--~~~---~--~~
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 and discover newly created LUN

[Konrad Rzeszutek]

On Mon, Jun 15, 2009 at 10:48:49PM +0530, shyam_i...@dell.com wrote:
 
  -Original Message-
  From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
  On Behalf Of Konrad Rzeszutek
  Sent: Monday, June 15, 2009 8:39 PM
  To: open-iscsi@googlegroups.com
  Subject: Re: open-iscsi and discover newly created LUN
  
  
   
On RHEL 5.3 and newer, upstream and probably ubuntu (not sure what
version is in there), you can do
   
iscsiadm -m session -r $SID --rescan
   
  
   Mike -
  
   The target can initiates a UNIT ATTENTION with additional sense as
   Report LUN data changed, I don't see that currently being handled
  by
   the SCSI-ML.
  
  You get that in dmesg? Or is that something the aray can do, but you
  have to configure it?
 
 It is usually programmed into the array firmware. 
 
  
   A rescan may not be necessary if this information is received by the
   open-iscsi.
  
  Huh? Why not? I mean if the LUN changed (it changed size for example),
  don't you want to rescan the LUN to pick up the changes?
 
 Not anymore.. Rescanning is a parallel scsi thingie ..see
 http://www.t10.org/ftp/t10/document.06/06-411r0.pdf

I think the majority of storages that are in usage right now (at least for the 
SMB
market) don't employ this standard. Hence to support those storage, you
would still need to do the old way (ie, find out what changed, do an
SCSI INQ see if the Peripheral Qualifier changed, or if device type has
changed from 1fh to 00h, etc).

--~--~-~--~~~---~--~~
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: RFC: do we need a new list for kernel patches

[Konrad Rzeszutek]

On Thu, Jun 11, 2009 at 12:41:17PM -0500, Mike Christie wrote:
 
 Hey,
 
 It seems like we have a lot of members on the list that are not kernel 
 developers, but we now have 5 iscsi drivers (qla4xxx, bnx2i, cxgb3i, 
 iscsi_tcp and ib_iser) with another being written. So it seems like we 
 are going to have lots of patches. I would also like to start sending my 
 kernel patches out in a way that everyone can see them. Previously to 
 avoid noise on this list, I have been pinging you guys privately which 
 just does not work so well now when we have so many people.
 
 What do you people think?

Send it here. That way the converstations are also archived for
future references.

 
 Do other people on the list prefer to see everything here, so you can 
 see what features are making progress?

Yes.

--~--~-~--~~~---~--~~
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 does not detect logical volume

[Konrad Rzeszutek]

On Thu, Apr 30, 2009 at 12:16:16PM -0400, sundar mahadevan wrote:
 
 Hi,
 I have iscsitarget(0.4.15-89.10) installed on system 1(opensuse 11.1)
 with firewall allowing port 3260 and open-iscsi(2.0.870-21.1)
 installed on system 2(opensuse 11.1).
 
 Here is my command from client:
 sunny1:/etc/iscsi/ifaces # iscsiadm -m node -T
 iqn.2009-09.com.ezhome:ocfs -p 10.1.1.1 -l
 Logging in to [iface: default, target: iqn.2009-09.com.ezhome:ocfs,
 portal: 10.1.1.1,3260]
 Login to [iface: default, target: iqn.2009-09.com.ezhome:ocfs, portal:
 10.1.1.1,3260]: successful
 
 But i don't see the logical volume detected when i issue fdisk -l

You won't see it that way. The LVM metadata is not in the MBR, but
in the first 384 sectors, in its own format. You need to do 'pvscan' to see 
your logical
volumes. And after as well do 'vgchange -a ly' after the scan.

 Also there are no error messages in /var/log/messages
 cat /var/log/messages | tail -n 20
 ...
 ...
 Apr 30 12:13:23 sunny1 kernel: scsi4 : iSCSI Initiator over TCP/IP
 Apr 30 12:13:24 sunny1 iscsid: connection3:0 is operational now
 
 Newbie. Please help. Thanks in advance.
 
 

--~--~-~--~~~---~--~~
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: strange behavior on kernel update

[Konrad Rzeszutek]

On Tue, Apr 28, 2009 at 04:00:08AM +0200, Maddin wrote:
 
 Hi,
 
 i'm using centos with dm-multipath and iscsi as a database system. All
 packages are normal centos packages from their mirrors.
 
 This night I was updating centos to the current release (5.3, previous
 version was 5.2). So the first thing I have done was stopping the multipathd
 and iscsi. After this I was doing the normal update stuff (yum
 check-updates, yum clean all, yum update glibc\*, yum update). During the
 last yum update the new kernel was installed (2.6.18-128.1.6.el5, previous
 was 2.6.18-92.1.22.el5).
 
 During the installation process of the kernel, the yum process hangs.
 Looking with ps for the hanging processes, I see that the kernel package was
 building the initrd. After killing this process and repeating the yum update
 process (this time only the kernel-package) about 5 times, the same strange
 failure occurs (process hangs on building initrd). The sixth time I was
 stracing the whole update process and see that the mkinitrd process does a
 wait-syscall for sth.. After killing this process again I went down to the
 server room to reboot the system and try another update process. I reboot
 the systems, stops multipathd and iscsi and starting the update process. On
 this update I could see that during the mkinitrd process, a kernel message
 device-mapper: failed path x:x:x:x occurs. Hmm this is strange I thought,
 because I've stopped multipathd and iscsi, so why means the kernel that a
 path is failed? Once again killing the mkinitrd process and then starting

The device mapper (a kernel component) still has your multipath entries even 
thought you have
killed multipathd and iscsi. It doesn't delete them, unless you
specifically instructs the daemon (multipathd) to do so.

From the standpoint of the kernel, the underlaying block devices got
yanked out and the brain (multipathd) terminated. And any I/O that
touches that multipath device (such as 'pvscan', 'lvscan' which mkinitrd
uses to figure out the boot device) would cause the kernel to notice
that the I/O's aren't going anywhere and mark them as failed.


 multipathd and iscsi I've tried another update process. And, yeha, it
 works???

.. and depending on your multipath.conf file, the I/O can be queued forever
(queue_if_no_path), or up to a certain time-limit ('no_path_retry'). Or
error out immediately (if you don't have any of those options set). From
your experiment it seems that those flags are set and the mkinitrd
process is in the D state, waiting for the kernel to return a value
after a read/write system call.

If you had deleted the device mapper entries before terminating
multipathd and iscsi this shouldn't have happend. Or if you had set the
multipath configuration to error out immediately you wouldn't hit this.

 
 I could reproduce this behavior on 2 machines, both centos with standard
 packages.

Correclty so.
 
 So can anybody comprehend this failure or any ideas?

 
 Cheers
 Maddin
 
 
 
 
 

--~--~-~--~~~---~--~~
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: Tuning iscsi read performance with multipath Redhat 5.3 / SLES 10 SP2 / Oracle Linux / Equallogic

[Konrad Rzeszutek]

On Fri, Apr 24, 2009 at 02:14:43PM -0400, Donald Williams wrote:
 Have you tried increasing the disk readahead value?
 #blockdev --setra X /dev/multipath device
 
  The default is 256.Use --getra to see current setting.
 
  Setting it too high will probably hurt your database performance.  Since
 databases tend to be random, not sequential.

I would think that the databases would open the disks with O_DIRECT
bypassing the block cache (And hence the disk readahead value isn't used
at all).

--~--~-~--~~~---~--~~
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: equallogic - load balancing and xfs

[Konrad Rzeszutek]

 
 I am not sure how to config the EQL box to not load balance or load 

At the array CLI prompt type:

grpparams conn-balancing disable

--~--~-~--~~~---~--~~
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: Q: /proc/scsi

[Konrad Rzeszutek]

On Wed, Apr 08, 2009 at 11:48:45AM +0200, Ulrich Windl wrote:
 
 Hi,
 
 when using open-iscsi (an older version), there are no entries in /proc/scsi. 
 I'd 
 expect something like a virtual HBA entry for iSCSI there, but could find 
 none. 
 Is there such a thing elsewhere (outside /proc/scsi)?

/proc/scsi is obsolete.
 
 Or do I have to collect things using paths like 
 /sys/devices/platform/host3/session0/target3:0:0/3:0:0:0/queue_depth ?

Yes.

 
 Regards,
 Ulrich
 
 
 

--~--~-~--~~~---~--~~
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: Kernel / iscsi problem under high load

[Konrad Rzeszutek]

On Fri, Apr 03, 2009 at 10:42:31AM +0100, Gonçalo Borges wrote:
 
 
 
  Sure.. but the normal rdac handler (that comes with the kernel) doesn't
  spit those errors. It looks as a proprietary module.
 
  If this is the proprietary module, what happens when you use the one that
  comes with
  the RHEL5U2 kernel?
 
 
 
 This RDAC handler is suggested in
 http://publib.boulder.ibm.com/infocenter/systems/topic/liaai/rdac/BPMultipathRDAC.pdf,
 and I had to download it from
 http://www.lsi.com/rdac/rdac-LINUX-09.02.C5.16-source.tar.gz, and compile
 it. I haven't tested the RDAC from the Kernel... Do you have any info on how
 to do it?

Move the module it created to some old place (those would be the mpp*.ko files)
and make sure that there is a dm-rdac.ko is in your /lib/modules/`uname -r`/ 
directory.

Boot a normal initrd, not the one the LSI package created.

The multipath.conf that you posted will work. You can check that by running
lsmod | grep rdac

and you should see dm_rdac loaded.

 
 What I have done previously was to test the DM-multipath with the
 path_checker readsector0 in /etc/multipath. I got the same problems in

Yikes. You don't want that.

 this Raid 10 configuration for the DS3300. However, dividing the same DS3300
 in 6 R1, I had no problems either with the present RDAC or with readsector0,

6 R1 ?

 but I got better I/O performance with the RDAC.

--~--~-~--~~~---~--~~
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: Kernel / iscsi problem under high load

[Konrad Rzeszutek]

 Apr  1 11:44:13 core26 kernel: 122 [RAIDarray.mpp]iscsi06:1:0:1
 Controller IO time expired. Delta 43701 secs
 Apr  1 11:44:13 core26 kernel: 497 [RAIDarray.mpp]iscsi06:1:0:1 Failed
 controller to 0. retry. vcmnd SN 458970 pdev H6:C0:T0:L1
 0x00/0x00/0x00 0x0002 mpp_status:2

What is the RAIDArray.mpp  program? Is that something the IBM docs
mentioned needs to be installed? Is that a version of Open-iSCSI
module .. or maybe the rdac handler??


--~--~-~--~~~---~--~~
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: Q: multipathd: queue_if_no_path

[Konrad Rzeszutek]

On Wed, Apr 01, 2009 at 01:05:30PM +0200, Ulrich Windl wrote:
 
 Hi,
 
 this is a bit off-topic, but esential: After experiencing a network failure 
 for 
 about four minutes, I was watching the syslog (the system had no problems so 
 far):
 
 Mar 30 15:24:33 testhost multipathd: sdc: tur checker reports path is up
 Mar 30 15:24:33 testhost multipathd: 8:32: reinstated
 Mar 30 15:24:33 testhost multipathd: L112_09: queue_if_no_path enabled
 Mar 30 15:24:33 testhost multipathd: L112_09: Recovered to normal mode
 Mar 30 15:24:33 testhost multipathd: L112_09: remaining active paths: 1
 Mar 30 15:24:33 testhost multipathd: L112_09: switch to path group #2
 Mar 30 15:24:33 testhost multipathd: L112_09: switch to path group #2
 
 I'm surprised: I thought queue_if_no_path would be enabled if the device 
 fails, 
 not if the device recovered!

It should be enabled all the time - I think you are seeing the code path that
figures out that queue_if_nopath is set and it prints an informational message
about it (the queue of I/O only happens when access to the disk is offline)

--~--~-~--~~~---~--~~
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: Can connection from iscsistart be stopped?

[Konrad Rzeszutek]

On Wed, Mar 25, 2009 at 08:26:46AM +0100, Ulrich Windl wrote:
 
 On 24 Mar 2009 at 19:47, agspoon wrote:
 
  
  We have an occasional problem where one LUN of a target (LUN-0) does
  not appear in a connection started by iscsistart.  This is in an iscsi-
  root scenario where iscsistart is called from within the initrd
  ramdisk image.  I don't why this happens, but I can detect when it
  does.  However, I don't know how to stop the connection and try
  again.  If I just re-run iscsistart, it complains that there is
  already a connection.  I tried just pulling out all the iscsi related
  modules and re-loading them, but they are in use.
 
 Hi!
 
 I think that's not very iSCSI related, so my guess would be to keep the 
 connection 
 and try a rescan SCSI bus on the SCSI host/connection that you already 
 have. 
 Also, do you really need LUN 0? Disks are usually assigned to a LUN != 0.

They are with some iSCSI targets (MD3000i, DS3300, AX150, CX300, Compelant, 
DataCore,
and some other ones).

Do you have any other LUNs on the target except LUN-0? Do they show up?

If not, you can do 'echo - - -  /sys/class/scsi_host/hostX/scan to
retrigger the scan. That should make the LUN-0 and others show up.

You will have to figure out the hostX relation to 
/sys/class/iscsi_session/sessionY
yourself.

--~--~-~--~~~---~--~~
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: Crash tgtd and tgtadm with more than 112 volumes.

[Konrad Rzeszutek]

On Tue, Mar 10, 2009 at 02:52:41PM -0700, Ben Greear wrote:
 I wrote a script to create lots of iscsi volumes on loop devices.
 
 Seems to run fine up to 111, and then tgtd crashes and tgtadm
 gets a buffer overflow.
 
 The script I used to create the problem and a capture of the
 crash is attached.
 
 I'm using standard RPMs on Fedora 10, kernel
 Linux iSCSi-test 2.6.27.15-170.2.24.fc10.x86_64 #1 SMP Wed Feb 11 23:14:31 
 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
 
 Let me know if I can provide any additional info.

You are on the wrong mailing list. This is for the Open-iSCSI _initiator_. The 
mailing
list you want is for the Open-iSCSI _target_, which is: 
iscsitarget-de...@lists.sourceforge.net.

--~--~-~--~~~---~--~~
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: Null pointer dereference during iSCSI login

[Konrad Rzeszutek]

On Mon, Mar 02, 2009 at 10:53:19AM +0100, Ulrich Windl wrote:
 
 Hello,
 
 with SLES10 SP1 on x86_64 (open-iscsi-2.0.707-0.32) I'm seeing a problem 
 during 
 login using iscsiadm -m node -L automatic. After a few logins, login 
 suddenly 

What happens if you use the latest version of Open-iSCSI kernel modules and 
Open-iSCSI utils?
(You will need to patch the kernel directory with the kernel/2.6.16-suse.patch 
for them to compile).

I see the 'kprobes' symbol in there - do you have any of them loaded?

--~--~-~--~~~---~--~~
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: How to expand a Linux Ext volume.

[Konrad Rzeszutek]

On Wed, Feb 25, 2009 at 08:14:47AM +0100, Ulrich Windl wrote:
 
 Hi,
 
 I have a related question: Some of the modern SAN disk systems allow a LUN 
 resize. 
 Does open-iscsi support resized disks in any way? I mean: Will the kernel 
 detect 
 that the disk has a new size?

That depends on the iSCSI targets. Some send an SCSI Asynchronous Event and the
iscsi daemon asks the kernel to execute READ CAPACITY which then can then find
the new size and register it. So once you re-sized the disk, your 
iscsi-initiator
would automatically get notified (within seconds) and your disk would show 
bigger
disk size.

If the iSCSI target does not send that (AEN), it is up to you to initiate this. 
You can
do either 'iscsiadm -node -R' or 'echo 1  /sys/block/sdX/device/rescan'. One 
way
to figure out if the kernel is out of sync with the real world is do:

SysFS_size=`cat /sys/block/sda/size`
SG_size=`sg_readcap /dev/sda | grep Number |sed s'/.*blocks=//'`

if [ $SysFS_size != $SG_size ]; then
echo 1  /sys/block/sda/device/rescan
fi

Keep in mind that if you have multipath stacked on top of your block device
you also need to tell multipath that your device has grown. This can be done
by doing:

multipathd -k'resize wwid'

(Thought only RHEL5 and SLES11 have this support).

--~--~-~--~~~---~--~~
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: Q: - PDU header Digest fetaure

[Konrad Rzeszutek]

On Wed, Feb 25, 2009 at 11:39:42AM +0100, Ulrich Windl wrote:
 
 Hello,
 
 when browsing the open-iscsi feature list, I found:
 - PDU header Digest;
 
 Does this mean that data digests are not supported? A bugzilla at readhat 
 near mid 

I am quite sure it is supported.

 of 2007 seems to confirm this.

Could you be more specific about the bugzilla number? Is the bugzilla in 
question
accessible to you?
 
 I see the performance impact, but is there another reason against 
 implementing it? 

None. It should be implemented.

 Can I safely activate it on the target, or will it cause problems?

You can activate it on the target. If you see problems, please do report it.

--~--~-~--~~~---~--~~
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 boot without ibft but using ibft sysfs code

[Konrad Rzeszutek]

On Wed, Feb 25, 2009 at 12:25:44PM -0600, Mike Christie wrote:
 Hey Konrad and other boot guys,

 If we have a driver that does not support ibft, but we need to somehow 
 export the iscsi info used for boot to userspace how do you think we should 
 go about this?

 I was thinking that
 1. We could libify some of the ibft sysfs code, so drivers could call some 
 helper to export its boot info in a common place. The driver would 
 basically talk to its firmware to get the boot info, then call something 
 like iscsi_boot_sysfs_add_target_info() which would expose it in sysfs in a 
 common place.

I like this one, but with a twist - the subsystem would have to be more generic
instead of being called 'ibft'.

And it means reworking the ibft driver so that it registers under
this sysfs class and provides the boot data the same way these other
drivers would do. This would also allow multiple iBFT structures
to be exported in case you have multiple NICs - which is something that on the
gPXE mailing list was thrown around.

I think 'iscsi_boot' as a name sounds appealing. Perhaps retain the same
directory structure (that ibft has now) and have the drivers (ibft + other 
drivers) call
such '*_add_target_info', '*_add_nic_info', etc?


 This is nice because the tools only have to look in one place, but I am not 
 sure if this type of stuff can also go under the /sys/firmware dir.

True. Would have to change the parent tree. Maybe to to /sys/boot' (or 
/sys/iscsi_boot?)

--~--~-~--~~~---~--~~
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: How to negotiate block size between target initiator

[Konrad Rzeszutek]

On Mon, Feb 23, 2009 at 03:12:43PM -0800, StorageSolutionGroup wrote:
 
 Hi,
 
 Windows does not support disks that have been formatted to anything
 other than  a 512byte block size. Block size refers to the low level
 formatting of the disk and not the cluster or allocation size used by
 NTFS. Be aware that using a disk with a block size larger than 512

What does Microsoft Windows have to do with the open-iscsi-initiator?

Or when you say Windows you mean Windows Storage Server?

--~--~-~--~~~---~--~~
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: [RFC]-Sysfs attributes of /sys/firmware/ibft files

[Konrad Rzeszutek]

On Mon, Feb 23, 2009 at 06:16:04PM +0530, shyam_i...@dell.com wrote:
 
 Does anyone know the reason for file attributes of the files created in
 /sys/firmware/ibft//files being readonly?

Yes. The spec does not allow you to write to the iBFT - only read.

The BIOS (or the firmware on the NIC, or your PXE boot loader - gPXE) generates
these structures during boot.

 
 Can't dynamically changing parameters like target ip-addreseses, iqns
 and others etc. be configurable through userspace via sysfs?

Can't do. Well if you are using the IBM blades, they do have
a Java tool (Blade Configuration something) that allows you to set those
entries and on bootup the BIOS would generate them. The mechanism it uses
to write that data is completly vendor-specific however.

 
 I think we do have precedence of firmware parameters being modified
 using sysfs.

Yes. Unfortunatly iBFT is not of those firmware structures.
 
 Thanks,
 Shyam Iyer
 
  

--~--~-~--~~~---~--~~
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: [RFC]-Sysfs attributes of /sys/firmware/ibft files

[Konrad Rzeszutek]

On Mon, Feb 23, 2009 at 09:27:08PM +0530, shyam_i...@dell.com wrote:
 
 Konrad wrote:
 On Mon, Feb 23, 2009 at 06:16:04PM +0530, shyam_i...@dell.com wrote:
  
  Does anyone know the reason for file attributes of the files created 
  in /sys/firmware/ibft//files being readonly?
 
 Yes. The spec does not allow you to write to the iBFT - only read. 
 
 Thanks Konrad. I guess I should have read the spec before commenting (:.

The spec is completly silent about this. Just talks about data values and
leaves the 'write'/generate part to vendors.

 
  
  Can't dynamically changing parameters like target ip-addreseses, iqns
 
  and others etc. be configurable through userspace via sysfs?
 
 Can't do. Well if you are using the IBM blades, they do have a Java
 tool (Blade Configuration something) that allows you to set those
 entries and on 
 
 bootup the BIOS would generate them. The mechanism it uses to write
 that data is completly vendor-specific however.
 
 You mean the content generated by the Java tool is stored somewhere and
 the BIOS reuses the content to genereate them as the spec mandates only
 the BIOS to generate the iBFT.

Exactly.

(Thought to be exact, the word BIOS should be used loosly, as the NIC firmware
could be constructing the iBFT, and not neccesarily the BIOS).

--~--~-~--~~~---~--~~
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: question regarding offlined device

[Konrad Rzeszutek]

 Maybe that's related: With SLES10 SP1 (x86_64) I have two iSCSI LUNs that are 
 reachable over 16 paths each, and the networ connections use two dedicated 
 separate VLANs. As it's a test at the moment, there's only one initiator and 
 two 
 iSCSCI gateways connected to that switch. And there is no traffic (the 
 filesystem 
 is a RAID1 that is not mounted). Still I'm seeing message like this:
 
 Feb 19 01:39:50 rkdvmso1 iscsid: connection198:0 is operational after 
 recovery (
 1 attempts)
 Feb 19 07:49:30 rkdvmso1 iscsid: connection215:0 is operational after 
 recovery (
 1 attempts)
 Feb 19 08:53:15 rkdvmso1 iscsid: connection208:0 is operational after 
 recovery (
 1 attempts)
 Feb 19 14:09:40 rkdvmso1 iscsid: connection211:0 is operational after 
 recovery (
 1 attempts)
 Feb 19 19:33:42 rkdvmso1 iscsid: connection220:0 is operational after 
 recovery (
 1 attempts)
 Feb 20 01:43:56 rkdvmso1 iscsid: connection210:0 is operational after 
 recovery (
 1 attempts)

It looks as if each path gets bumped. Is there anything related in the target 
around those times? Did you see a pattern over a long time of which path and 
what
time they are being bumped?

Also, are there any backup being done over that time-frame that would saturate
the switches?

--~--~-~--~~~---~--~~
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: question regarding offlined device

[Konrad Rzeszutek]

On Fri, Feb 20, 2009 at 05:07:49PM +0100, Ulrich Windl wrote:
 
 On 20 Feb 2009 at 10:19, Konrad Rzeszutek wrote:
 
  
   Maybe that's related: With SLES10 SP1 (x86_64) I have two iSCSI LUNs that 
   are 
   reachable over 16 paths each, and the networ connections use two 
   dedicated 
   separate VLANs. As it's a test at the moment, there's only one initiator 
   and two 
   iSCSCI gateways connected to that switch. And there is no traffic (the 
   filesystem 
   is a RAID1 that is not mounted). Still I'm seeing message like this:
   
   Feb 19 01:39:50 rkdvmso1 iscsid: connection198:0 is operational after 
   recovery (
   1 attempts)
   Feb 19 07:49:30 rkdvmso1 iscsid: connection215:0 is operational after 
   recovery (
   1 attempts)
   Feb 19 08:53:15 rkdvmso1 iscsid: connection208:0 is operational after 
   recovery (
   1 attempts)
   Feb 19 14:09:40 rkdvmso1 iscsid: connection211:0 is operational after 
   recovery (
   1 attempts)
   Feb 19 19:33:42 rkdvmso1 iscsid: connection220:0 is operational after 
   recovery (
   1 attempts)
   Feb 20 01:43:56 rkdvmso1 iscsid: connection210:0 is operational after 
   recovery (
   1 attempts)
  
  It looks as if each path gets bumped. Is there anything related in the 
  target 
  around those times? Did you see a pattern over a long time of which path 
  and what
  time they are being bumped?
  
  Also, are there any backup being done over that time-frame that would 
  saturate
  the switches?
 
 Hi!
 
 I'll have to investigate a bit deeper. If it's not the network, it could be 
 FC or 
 the target hardware itself. There are some backups actually running, some of 
 those 

Those are iSCSI errors. How does FC figure in this? Is FC used for backups? If 
so, then
that shouldn't be an issue as the FC and network fabric are seperate.

 I'm responsible for, and others I'm not responsible for, but they use the 
 same 
 infrastructure, and even others that only use the FC ISL (Inter-Switch-Links) 
 for 
 data transport. However we were believing that FC guarantees maximum delays 
 and no 
 packet drops, so I dobt that it's the FC, but who knows? I'll have a deeper 
 look, 

You will get errors when the FC packets get dropped and can't be re-sent.

 comparing it to the backup times I know...
 
 Regards,
 Ulrich
 
 
 
  
   
 
 
 
 

--~--~-~--~~~---~--~~
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: iscsid: connection198:0 is operational after recovery

[Konrad Rzeszutek]

On Fri, Feb 20, 2009 at 05:11:24PM +0100, Ulrich Windl wrote:
 
 Hello,
 
 I noticed that I see messages like
 
 Feb 19 01:39:50 rkdvmso1 iscsid: connection198:0 is operational after 
 recovery (1 
 attempts)
 
 but no messages telling me that the connection is down (timed out/not 
 responding). 
 So it's hard to guess when the problem actually occurred. Not knowing the 
 sources, 
 could it be that the message priority for the failure message (if there is 
 any) is 
 set too low?

Try to set 'loglevel=8' on the bootup argument. Also edit /etc/sysconfig/init 
and
set the LOG to 8 (if you are using a Red Hat variant of OS).

--~--~-~--~~~---~--~~
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: Disable aggregation of requests

[Konrad Rzeszutek]

On Thu, Feb 19, 2009 at 09:13:10PM +0200, Boaz Harrosh wrote:
 
 Or Gerlitz wrote:
  Boaz Harrosh wrote:
  You can select the no-op I/O elevator and you can also use direct IO
  like with sg_dd from the sg_utils package

  Does anyone know why noop is not the default I/O scheduler?
.. snip..
 It is a very bad idea in case of using a filesystem which is usually
 the point.

Could you elaborate a bit more please?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)

[Konrad Rzeszutek]

In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we 
would
logout, and then retry logging back in:

- 28Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for 
connection^M
- 28Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2 
attempts)^M

And we would have a short hiccup (5 seconds) of the connection being gone.

This as my understanding was a mechanism for the EqualLogic box to move 
(re-establishing
allegiance) a session to a different port, hence allowing a load-balancing 
mechanism.

In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed this
behavior so that we now actually logout and delete the session. No more retries.

2.0-865:
static int iscsi_xmit_mtask(struct iscsi_conn *conn)
{
struct iscsi_hdr *hdr = conn-mtask-hdr;
int rc, was_logout = 0;

spin_unlock_bh(conn-session-lock);
if ((hdr-opcode  ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT) {
conn-session-state = ISCSI_STATE_IN_RECOVERY;
iscsi_block_session(session_to_cls(conn-session));

...
2.0-869:
static int iscsi_xmit_mtask(struct iscsi_conn *conn)
{
struct iscsi_hdr *hdr = conn-mtask-hdr;
int rc;

if ((hdr-opcode  ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT)
conn-session-state = ISCSI_STATE_LOGGING_OUT;
spin_unlock_bh(conn-session-lock);

.. and..
if (conn-session-state == ISCSI_STATE_LOGGING_OUT) {
iscsi_free_mgmt_task(conn, conn-mtask);
conn-mtask = NULL;
continue;
}

This comes down to 2.0-869 terminating the session without trying to re-login.

With the EqualLogic boxes that means we never reconnect back.

So.. my question is : was this change intentional?

If so, does Equallogic know this and have they changed their firmware to
send ISCSI_ASYNC_MSG_DROPPING_CONNECTION (0x02) instead back?

--~--~-~--~~~---~--~~
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: EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)

[Konrad Rzeszutek]

On Wed, Feb 04, 2009 at 04:33:13PM -0500, Konrad Rzeszutek wrote:
 
 In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we 
 would
 logout, and then retry logging back in:
 
 - 28Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for 
 connection^M
 - 28Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2 
 attempts)^M
 
 And we would have a short hiccup (5 seconds) of the connection being gone.
 
 This as my understanding was a mechanism for the EqualLogic box to move 
 (re-establishing
 allegiance) a session to a different port, hence allowing a load-balancing 
 mechanism.
 
 In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed 
 this

The right git commit was:

commit b3a7ea8d50f6028964b468d13a095dfb2508b2fb
Author: Mike Christie micha...@cs.wisc.edu
Date:   Thu Dec 13 12:43:26 2007 -0600

[SCSI] libiscsi: do not block session during logout

There is not need to block the session during logout. Since
we are going to fail the commands that were blocked just fail them
immediately instead.


--~--~-~--~~~---~--~~
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: Issues with intel firmware initiator, ibft and 2-way chap

[Konrad Rzeszutek]

On Tue, Feb 03, 2009 at 12:53:32AM +, Michael Brown wrote:
 On Monday 02 February 2009 19:12:25 Konrad Rzeszutek wrote:
  A year ago that was the problem - you got something like this:
 
  konrad@/data/git/ibft$ hexdump intel_nic.bin
  000 4269 5446 029c  0001 4e49 4554 004c
  010        
  *
  030        
  *
  290      
  29c
 
  Where the iBFT NIC and target structure are filled
  with 0xFF.
 
 The checksum of that table is non-zero, so anything scanning for it should 
 ignore it anyway.  If the ibft module treats it as a valid table, then it's a 
 bug.

It does not:

 if (csum) {
printk(KERN_ERR iBFT has incorrect checksum (0x%x)!\n, csum);
return -ENOENT;
}   

Wheew.. 

--~--~-~--~~~---~--~~
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: Issues with intel firmware initiator, ibft and 2-way chap

[Konrad Rzeszutek]

On Tue, Feb 03, 2009 at 10:30:13AM +0100, Hans de Goede wrote:
 
 
 
 Mike Christie wrote:
  Konrad Rzeszutek wrote:
  On Mon, Feb 02, 2009 at 11:39:18AM +0100, Hans de Goede wrote:
  Hi,
 
  When using 2-way chap and booting from an intel network card with intel 
  firmware initiator, their is no way to specify the username in the 
  firmware 
  initiator for the reverse chap, nor does it care what username the target 
  provides.
 
  However under sysfs (ibft) there is a reverse username attribute 
  (containing 
  garbage) and as this garbage is not provided by the target open-iscsi 
  does not 
  want to talk to the target.
  That is b/c the ibft module parses the iBFT structure and this is the 
  offset where
  the reverse username attribute is at. You can insert a bunch of printks in 
  the 
  module and see data.
 
  Better yet, try this attached tool. I wrote it up some time with a 
  different purpose
  in mind and just now converted it over to read from /dev/mem. Try it and 
  see if the
  data comes out looking valid.
 
  (Last time I used it on an Intel NICs, they would insert 0xFF everywhere 
  in the 
  IBFT).
 
  So how do we work around this?
  Try to use the IBM HS-20 (ibm-hs20-iscsi.lab.redhat.com, I think)
 
  
  Hey, so this is a problem with only intel nics? If so let's talk to the 
  intel guys to see if they are going to fix it, or is already fixed by 
  just updating the firmware.
  
 
 Yes, this seems to be a problem with the ibft of the intel nic firmware. I do 
 not have the all FF FF problem, everything is correct, except for the 
 reverseusername, which is not surprising as the firmware BIOS setup interface 
 does not allow one to specify a reverseusername. But then I would expect the 
 reverse username sysfs attribute to be empty which it is not (which undoubtly 
 is a firmware bug).

OK. Can you send me the binary blob? Maybe there is something that can
be done in the iscsi_ibft to detect this and do the right thing (ie, not
fill reverse username with garbage).


--~--~-~--~~~---~--~~
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: Issues with intel firmware initiator, ibft and 2-way chap

[Konrad Rzeszutek]

 
 Sure, if you can tell me how to get the blob?

gcc find_ibft.c -o find_ibft
sudo ./find_ibft blob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

#include stdio.h
#include errno.h
#include sys/mman.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
#include fcntl.h
#include ctype.h
#include stdint.h

const char *filename = /dev/mem;
int main(int argc, char *argv[])
{

int fd = 0;
unsigned char *fbuf;
unsigned char *p;
struct stat buf;
int i,len;
unsigned int len_p;

fd = open(filename, O_RDONLY);
if (fd = 0) {
printf(Could not open; err: %d(%s)\n, errno, strerror(errno));
return errno;
}
if (stat(filename, buf) != 0) {
printf(Could not open; err: %d(%s)\n, errno, strerror(errno));
return errno;
}

len = 0x10; // Up to 1MB.
fbuf = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, 0);
if (fbuf == MAP_FAILED) {
printf(Could not map: error: %d(%s)\n, errno,
   strerror(errno));
return errno;
}
len_p = 0;
for (p = fbuf; p  fbuf + 0x10; p += 4)
{
if (memcmp(p, iBFT, 4) == 0) {
len_p = *(unsigned int *)(p + 4);
printf(iBFT detected. (%d)\n, len_p);
break;
}
}
if (len_p)
{
if (argc  1) {
int outfd;
outfd = open(argv[1], O_RDWR|O_CREAT, 0644);
if (outfd != -1) {
write(outfd, p, len_p);
close(outfd);
}
}
printf((%lx): DATA:\n, p);

for (i = 0; i  len_p; i++) {
if ((i % 70) == 0)
printf(\n%.3x: , i);
if (isgraph(p[i]))
printf(%c, p[i]);
else
printf(_);
//  putchar(fbuf[i]);
}
printf(\n);
}
else
{
printf(Bummer. No iBFT found.\n);
}
if (munmap(fbuf, len)) {
printf(Could not unmap: %d(%s)\n, errno, strerror(errno));
return errno;
}
close(fd);
return 0;
}

Re: Issues with intel firmware initiator, ibft and 2-way chap

[Konrad Rzeszutek]

On Mon, Feb 02, 2009 at 11:39:18AM +0100, Hans de Goede wrote:
 
 Hi,
 
 When using 2-way chap and booting from an intel network card with intel 
 firmware initiator, their is no way to specify the username in the firmware 
 initiator for the reverse chap, nor does it care what username the target 
 provides.
 
 However under sysfs (ibft) there is a reverse username attribute (containing 
 garbage) and as this garbage is not provided by the target open-iscsi does 
 not 
 want to talk to the target.

That is b/c the ibft module parses the iBFT structure and this is the offset 
where
the reverse username attribute is at. You can insert a bunch of printks in the 
module and see data.

Better yet, try this attached tool. I wrote it up some time with a different 
purpose
in mind and just now converted it over to read from /dev/mem. Try it and see if 
the
data comes out looking valid.

(Last time I used it on an Intel NICs, they would insert 0xFF everywhere in the 
IBFT).

 
 So how do we work around this?

Try to use the IBM HS-20 (ibm-hs20-iscsi.lab.redhat.com, I think)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

#include stdio.h
#include errno.h
#include sys/mman.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
#include fcntl.h
#include ctype.h
#include stdint.h

const char *filename = /dev/mem;
int main(int argc, char *argv[])
{

int fd = 0;
unsigned char *fbuf;
unsigned char *p;
struct stat buf;
int i,len;
unsigned int len_p;

fd = open(filename, O_RDONLY);
if (fd = 0) {
printf(Could not open; err: %d(%s)\n, errno, strerror(errno));
return errno;
}
if (stat(filename, buf) != 0) {
printf(Could not open; err: %d(%s)\n, errno, strerror(errno));
return errno;
}

len = 0x10; // Up to 1MB.
fbuf = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, 0);
if (fbuf == MAP_FAILED) {
printf(Could not map: error: %d(%s)\n, errno,
   strerror(errno));
return errno;
}
len_p = 0;
for (p = fbuf; p  fbuf + 0x10; p += 4)
{
if (memcmp(p, iBFT, 4) == 0) {
len_p = 0xfff;
printf(iBFT detected.\n);
break;
}
}
if (len_p)
{
if (argc  1) {
int outfd;
outfd = open(argv[1], O_RDWR|O_CREAT, 0644);
if (outfd != -1) {
write(outfd, p, len_p);
close(outfd);
}
}
printf((%lx): DATA:\n, p);

for (i = 0; i  len_p; i++) {
if ((i % 70) == 0)
printf(\n%.3x: , i);
if (isgraph(p[i]))
printf(%c, p[i]);
else
printf(_);
//  putchar(fbuf[i]);
}
printf(\n);
}
if (munmap(fbuf, len)) {
printf(Could not unmap: %d(%s)\n, errno, strerror(errno));
return errno;
}
close(fd);
return 0;
}

Re: Issues with intel firmware initiator, ibft and 2-way chap

[Konrad Rzeszutek]

On Mon, Feb 02, 2009 at 12:06:05PM -0600, Mike Christie wrote:
 
 Konrad Rzeszutek wrote:
  On Mon, Feb 02, 2009 at 11:39:18AM +0100, Hans de Goede wrote:
  Hi,
 
  When using 2-way chap and booting from an intel network card with intel 
  firmware initiator, their is no way to specify the username in the 
  firmware 
  initiator for the reverse chap, nor does it care what username the target 
  provides.
 
  However under sysfs (ibft) there is a reverse username attribute 
  (containing 
  garbage) and as this garbage is not provided by the target open-iscsi does 
  not 
  want to talk to the target.
  
  That is b/c the ibft module parses the iBFT structure and this is the 
  offset where
  the reverse username attribute is at. You can insert a bunch of printks in 
  the 
  module and see data.
  
  Better yet, try this attached tool. I wrote it up some time with a 
  different purpose
  in mind and just now converted it over to read from /dev/mem. Try it and 
  see if the
  data comes out looking valid.
  
  (Last time I used it on an Intel NICs, they would insert 0xFF everywhere in 
  the 
  IBFT).
  
  So how do we work around this?
  
  Try to use the IBM HS-20 (ibm-hs20-iscsi.lab.redhat.com, I think)
  
 
 Hey, so this is a problem with only intel nics? If so let's talk to the 

A year ago that was the problem - you got something like this:

konrad@/data/git/ibft$ hexdump intel_nic.bin 
000 4269 5446 029c  0001 4e49 4554 004c
010        
*
030        
*
290        
29c

Where the iBFT NIC and target structure are filled
with 0xFF. 

Compared to the IBM HS-20:

konrad@/data/git/ibft$ hexdump hs20.bin 
000 4269 5446 017d  a101 4249 004d 
010 4269 2046 2e31 0030    
020        
030 0101 0012   0048 0098 0100 
040     0102 004a 0300 
050        
*
080        0020
090 0136    0103 0066 0700 
0a0      a8c0 294d 0016
0b0       a8c0 fe4f
0c0        
*
0f0  1100 9d25 018b 0509   
100 0104 0036 0300     
110  a8c0 744f 0cbc    
120  0025 0157     
130    7169 2e6e 3032 3730 302d
140 2e37 6f63 3a6d 6f6b 726e 6461 692e 696e
150 6974 7461 726f 6900 6e71 322e 3030 2e37
160 6f63 2e6d 6e69 6574 2d6c 6273 3478 3a34
170 7473 726f 6761 2d65 3031 6267  
17d

(I can attach the binary blobs if that would make it easier.)

 intel guys to see if they are going to fix it, or is already fixed by 
 just updating the firmware.

I think due dillegence first - see if that little piece of C code I attached
extracts a valid looking iBFT instead of garbage filled iBFT.

If it is valid, it could be that the ibft module is doing
something wrong.


--~--~-~--~~~---~--~~
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: make open-iscsi userspace tools functionality available as a library

[Konrad Rzeszutek]

On Wed, Jan 21, 2009 at 11:48:41AM +0100, Ulrich Windl wrote:
 
 On 20 Jan 2009 at 9:23, Konrad Rzeszutek wrote:
 
  I would recommend that you provide as the first variable in all of the 
  structs
  an unsigned int called 'version'. This way if the structs are extended they
  would be backwards compatible and there is an easy way to identify which
  version of structs they are.
 
 Hi!
 
 When doing an initial version, why not try to do it right at the beginning? 
 Addind 
 a version number to a poor design is terrible, because for compatibility 
 you'll 
 always have to support old versions then. If you do not, why the version 
 number?

Because we are humans and we make mistakes. It is one of the mechanism to fix
something later on when an Application Binary Interface (ABI) is holy and
cannot be changed.

--~--~-~--~~~---~--~~
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: make open-iscsi userspace tools functionality available as a library

[Konrad Rzeszutek]

NACK.

I presume you have run this program (and the test-code) through
valgrind with no memory leaks?

Please see my comments below.

 diff -urN open-iscsi-2.0-870.1.orig/libiscsi/libiscsi.c 
 open-iscsi-2.0-870.1/libiscsi/libiscsi.c
 --- open-iscsi-2.0-870.1.orig/libiscsi/libiscsi.c 1970-01-01 
 01:00:00.0 +0100
 +++ open-iscsi-2.0-870.1/libiscsi/libiscsi.c  2009-01-19 12:28:08.0 
 +0100
 @@ -0,0 +1,354 @@
 +#include stdio.h
 +#include stdlib.h
 +#include string.h
 +#include errno.h
 +#include unistd.h
 +#include libiscsi.h


 +#include idbm.h
 +#include iscsiadm.h
 +#include log.h
 +#include sysfs.h
 +#include iscsi_sysfs.h
 +#include util.h
 +#include sysdeps.h
 +#include iface.h

Do these guys need to be in quotes? In the Makefile you did specify the header
directory so I would think that would work.

Also it might make sense to order these guys in alphabetical order.

 +
 +#define CHECK(a) { rc = a; if (rc) goto leave; }
 +
 +struct libiscsi_context {
 + char libiscsi_error_string[256];

Use a #define for the size.

 +};
 +
 +struct libiscsi_context *libiscsi_init(void)
 +{
 + struct libiscsi_context *context;
 +
 + context = calloc(sizeof *context, 1);

Swap the arguments around. First argument is the number of elements, while the 
second
is the size of the element.

 + if (!context)
 + return NULL;
 +
 + /* enable stdout logging */
 + log_daemon = 0;
 + log_init(libiscsi, 1024);
 + sysfs_init();
 + increase_max_files();
 + if (idbm_init(NULL)) {
 + free(context);

No sysfs_cleanup() call? Or log_close()?

 + return NULL;
 + }
 +
 + iface_setup_host_bindings();
 +
 + return context;
 +}
 +

... snip..
 +int libiscsi_discover_sendtargets(struct libiscsi_context *context,
 +const char *address, int port, const struct libiscsi_auth_info 
 *auth_info,
 +struct libiscsi_node **found_nodes)
.. snip ..
 + if (!auth_info-chap.username[0])

Would it make sense to add logging here as well? Like 
'log_warning(Non-existent CHAP username!)' or such?

 + return -EINVAL;
 + if (!auth_info-chap.password[0])
 + return -EINVAL;

Is against the CHAP to have an empty password? Ah n/m. The 
http://www.ietf.org/rfc/rfc1994.txt says: The CHAP algorithm requires
that the length of the secret MUST be at least 1 octet. Maybe
put a check for that?

BTW, I am not sure if the PPP CHAP RFC == iSCSI CHAP, so I 
might be spewing non-sense here.


 + if (auth_info-chap.reverse_username[0] 
 + !auth_info-chap.reverse_password[0])
 + return -EINVAL;
 +
 + drec.u.sendtargets.auth.authmethod = AUTH_METHOD_CHAP;
 + strlcpy(drec.u.sendtargets.auth.username,
 + auth_info-chap.username, AUTH_STR_MAX_LEN);
 + strlcpy((char *)drec.u.sendtargets.auth.password,
 + auth_info-chap.password, AUTH_STR_MAX_LEN);
 + drec.u.sendtargets.auth.password_length =
 + strlen((char *)drec.u.sendtargets.auth.password);

This doesn't guard against passwords that are of AUTH_STR_MAX_LEN length. Which
means that there might not be an \0 at then end and your password_length
computation ends up looking at the next structure fields. Or worst (shudder)
Unlikely, but it could happen - and the check is easy enough: 

drec.u.sendtargets.auth.password_length = 
drec.u.sendtargets.auth.password_length   AUTH_STR_MAX_LEN ? AUTH_STR_MAX_LEN 
: drec.u.sendtargets.auth.password_length;

Maybe even do that before any 'strlcpy' is done and use this newly
computed length instead of the defines?

 + strlcpy(drec.u.sendtargets.auth.username_in,
 + auth_info-chap.reverse_username, AUTH_STR_MAX_LEN);
 + strlcpy((char *)drec.u.sendtargets.auth.password_in,
 + auth_info-chap.reverse_password, AUTH_STR_MAX_LEN);
 + drec.u.sendtargets.auth.password_in_length =
 + strlen((char *)drec.u.sendtargets.auth.password_in);

And the same check here..

 + break;
 + default:
 + return -EINVAL;
 + }   
 +
 + CHECK(discovery_sendtargets(drec, new_rec_list))
 + CHECK(idbm_add_discovery(drec, 1))

Make the 1 a #define? Without me looking at the code I had
no idea that 1 stands for 'over-write'. Thought at first it
was the count of records - which looked weird.

 +
 + /* bind ifaces to node recs so we know what we have */
 + list_for_each_entry(rec, new_rec_list, list)
 + CHECK(idbm_bind_ifaces_to_node(rec, NULL, bound_rec_list))
 +
 + /* now add/update records */
 + list_for_each_entry(rec, bound_rec_list, list) {
 + CHECK(idbm_add_node(rec, drec, 1))

Ditto.

 + found++;
 + }
 +
 + if (found_nodes  found) {
 + *found_nodes = calloc(found, sizeof 

Re: PATCH: make open-iscsi userspace tools functionality available as a library

[Konrad Rzeszutek]

  I would recommend that you provide as the first variable in all of the 
  structs
  an unsigned int called 'version'. This way if the structs are extended they
  would be backwards compatible and there is an easy way to identify which
  version of structs they are.
  
 
 Erm, given the amount of programs which will probably end up using this (not 
 all that much) a distro should be able to easily rebuild all those in case of 
 an ABI change and thus a soname bump. I understand what you are trying to say 
 here, but IMHO the added complexity and ugliness is not worth it.

I disagree. The ABI in a distro is a holy thing. When a Linux distro releases 
their
libraries (look for example at libvirt), they can't modify it for the next 7 
years
(sure they can do it underneath the covers, but look at the Red Hat kernel with
those #ifdef __GENKSYSM__ to work-around this).

I am curious to understand what is complex and ugly about it? Could you be
more specific please.

--~--~-~--~~~---~--~~
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: make open-iscsi userspace tools functionality available as a library

[Konrad Rzeszutek]

On Tue, Jan 20, 2009 at 07:40:08PM +0100, Bart Van Assche wrote:
 On Tue, Jan 20, 2009 at 7:20 PM, Konrad Rzeszutek
 kon...@virtualiron.com wrote:
 
   I would recommend that you provide as the first variable in all of the 
   structs
   an unsigned int called 'version'. This way if the structs are extended 
   they
   would be backwards compatible and there is an easy way to identify which
   version of structs they are.
  
 
  Erm, given the amount of programs which will probably end up using this 
  (not
  all that much) a distro should be able to easily rebuild all those in case 
  of
  an ABI change and thus a soname bump. I understand what you are trying to 
  say
  here, but IMHO the added complexity and ugliness is not worth it.
 
  I disagree. The ABI in a distro is a holy thing. When a Linux distro 
  releases their
  libraries (look for example at libvirt), they can't modify it for the next 
  7 years
  (sure they can do it underneath the covers, but look at the Red Hat kernel 
  with
  those #ifdef __GENKSYSM__ to work-around this).
 
  I am curious to understand what is complex and ugly about it? Could you be
  more specific please.
 
 I agree that having a stable binary interface is very important for a
 shared library. But if glibc doesn't have versioned structs, why would
 these be needed in an iscsi library ? Please keep in mind that it is
 possible to define a new version of a shared library in case the ABI
 changes.

Yeah. I just thought about that when I sent the e-mail about libvirt. I think
that is a good compromise - however we still need the ground-work in place
so that this library is built as libiscsi.so.1.0.0 and that the linker saves
the version information.

I guess this implies that the .spec file needs to be changed to include this
file as well.

--~--~-~--~~~---~--~~
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: make open-iscsi userspace tools functionality available as a library

[Konrad Rzeszutek]

On Tue, Jan 20, 2009 at 07:58:07PM +0100, Hans de Goede wrote:
 
 Hi,
 
 Konrad Rzeszutek wrote:
 
 Thanks for the review!
 
   I presume you have run this program (and the test-code) through
   valgrind with no memory leaks?
  
 
 Erm, no, has iscsiadm been run through valgrind? If not I'm not going to be 
 running libiscsi through it either (sorry) libiscsi builds on top of many 

I meant the test-cases. 

 open-iscsi userspace code internals, and those are not always pretty (many 
 global variables for example).

I believe valgrind marks those as 'possible memory-leaks'


.. snip ..

 +#include iface.h
  
   Do these guys need to be in quotes? In the Makefile you did specify the
   header
   directory so I would think that would work.
  
 
 Using  might work too, but this way it is clear this are open-iscsi 
 headers, 
 and not system headers.

Sounds fair.

.. snip ..
 +CHECK(discovery_sendtargets(drec, new_rec_list))
 +CHECK(idbm_add_discovery(drec, 1))
  
   Make the 1 a #define? Without me looking at the code I had
   no idea that 1 stands for 'over-write'. Thought at first it
   was the count of records - which looked weird.
  
 
 Internal open-iscsi API, when it becomes a define there I'll happily use it.

How about a comment instead then.

 
 +
 +/* bind ifaces to node recs so we know what we have */
 +list_for_each_entry(rec, new_rec_list, list)
 +CHECK(idbm_bind_ifaces_to_node(rec, NULL, bound_rec_list))
 +
 +/* now add/update records */
 +list_for_each_entry(rec, bound_rec_list, list) {
 +CHECK(idbm_add_node(rec, drec, 1))
  
   Ditto.
  
 
 Ditto.

Ditto :-)

 
 +found++;
 +}
 +
 +if (found_nodes  found) {
 +*found_nodes = calloc(found, sizeof **found_nodes);
  
   Please swap the arguments.
  
 
 Erm, no, this time I got it right the first time.

Right. 

.. snip ..
 +int login_helper(void *data, node_rec_t *rec)
 +{
 +int rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
 +if (rc) {
 +iscsid_handle_error(rc);
 +rc = ENOTCONN;
  
   Should that have a - in front of it? Hmm.. I thought Mike wanted
   all of the return codes to be a positive number. Which means all
   the other functions you have should _NOT_ have the '-'?
  
   Looking at the 'idbm_*' all of its return codes are positive. Perhaps
   a global search and replace for the -E to E?
  
 
 The only functions returning negative codes are the discovery functions, as 

I think having the same mechanism and behavior to return error codes will
save folks from trouble down the line. Having all functions return a positive
error codes.


 they return the number of nodes found on success. If people dislike this I 
 can 
 return the number of found nodes through a pointer instead.


 
 +}
 +return rc;
 +}
 +
 +int libiscsi_node_login(struct libiscsi_context *context,
 +const struct libiscsi_node *node)
 +{
 +int nr_found = 0, rc;
 +
 +CHECK(idbm_for_each_iface(nr_found, NULL, login_helper,
 +(char *)node-name, node-tpgt,
 +(char *)node-address, node-port))
 +if (nr_found == 0)
 +rc = ENODEV;
 +leave:
 +return rc;
 +}
 +
 +static int logout_helper(void *data, struct session_info *info)
 +{
 +int rc;
 +struct node_rec *rec = data;
 +
 +if (!iscsi_match_session(rec, info))
 +return -1; /* Not a match */
  
   Oh boy. Can you put a comment of why you are mixing standard error
   codes with negative numbers? At first I thought this was an error
   until I looked in 'iscsi_sysfs_for_each_session' and found:
   if less than zero it means it was not a match
  
   Can you just say that 'iscsi_sysfs_for_each_session' requires this
   type of return code for not a match please?
  
 
 You mean make the comment more verbose, sure if that makes you happy :) This 

Please do.

 are those infamous open-iscsi internals again, which I'm trying really hard 
 to 
 hide from the outside (iow when only looking at libiscsi.h) once you start 
 looking at libiscsi.c, well ...
 
 
   .. snip ..
  
 +static int get_parameter_helper(void *data, node_rec_t *rec)
 +{
 +struct db_set_param *param = data;
 +recinfo_t *info;
 +int i;
 +
 +info = idbm_recinfo_alloc(MAX_KEYS);
 +if (!info)
 +return ENOMEM;
 +
 +idbm_recinfo_node(rec, info);
 +
 +for (i = 0; i  MAX_KEYS; i++) {
 +if (!info[i].visible)
 +continue;
 +
 +if (strcmp(param-name, info[i].name))
  
   How about 'strncmp' ?
  
 
 Why?

Knee-jerk reaction. In this case I can see you don't do anything
else beside 'continue' so it doesn't matter.

 
 +continue;
 +
 +strlcpy(param-value, info[i].value

Re: How can I list logged in nodes?

[Konrad Rzeszutek]

On Thu, Jan 08, 2009 at 10:00:31AM -0800, chris1.nore...@googlemail.com wrote:
 
 Hi, is there a way using iscsiadm to list only nodes which are
 currently logged in? I find that running iscsiadm -m node always
 lists discovered nodes, but can't find a way to list only those which
 are logged in and therefore available.

iscsiadm -m session

Will do it.

 
 

--~--~-~--~~~---~--~~
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: [dm-devel] multipathd: sdc: readsector0 checker reports path is down

[Konrad Rzeszutek]

On Thu, Jan 08, 2009 at 11:31:38AM -0800, Ray Van Dolson wrote:
 I'm still getting the hang of iSCSI and multipath, so bear with me if
 this is a FAQ that I've missed...
 
 I have a host attaching to an MD3000i via iSCSI/dm-multipath that is
 working but showing a lot of the following errors in syslog:
 
   multipathd: sdc: readsector0 checker reports path is down

You are using the wrong path checker, wrong path priority program,
and no hardware path checker :-(

Here is what you need in your multipath.conf file:

 #   
# DELL :D3000i :: Active-Passive RDAC
# Note: The same as the IBM DS3300
#   
device {
vendor  DELL
product MD3000i
product_blacklist   Universal Xport
features1 queue_if_no_path
path_grouping_policygroup_by_prio
hardware_handler1 rdac
path_checkerrdac
priordac
failbackimmediate
}   


Thought you might need to replace the 'prio rdac' with
'prio_callout   /sbin/mpath_prio_rdac as I think RHEL5/CentOS5 uses
the old calling convention.

This should get rid of your down errors and show your passive/active path
properly.

--~--~-~--~~~---~--~~
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 and Sun Amber Road anomalies

[Konrad Rzeszutek]

On Fri, Dec 26, 2008 at 01:05:53AM -0800, Albert Pauw wrote:
 
 Hi Mike,
 
 thought you might be interested in this. I am using the Sun amber road
 vmware demo and set it to export an iscsi target.
 
 The fun part starts at discovery. I have defined two interfaces on it,
 one for administration, the other for the actual target. When I send a
 target discovery request to the data interface the target responds
 with its name (iqn.blabla) and the two interface IP numbers, which
 open-iscsi happily puts in its database (that is, the same name and
 two different IP numbers, so two entries), like this.
 
 [r...@orange ~]# iscsiadm -m node
 192.168.1.125:3260,1 iqn.1986-03.com.sun:02:8e72afff-eb91-e5e0-de5a-
 bce6de1eb109
 192.168.1.126:3260,1 iqn.1986-03.com.sun:02:8e72afff-eb91-e5e0-de5a-
 bce6de1eb109
 
 Using the delete option removes them both, as the name is the same.
 Needles to say that if you login, you login to both, creating in my
 case a /dev/sdb and /dev/sdc device, effectively being the same
 target. I can see multipathing here, but not as we know it ;-)

What do you mean? Multipath doesn't work with that iSCSI target?

 
 Any ideas? E.g. marking the node as a multipathing device, as the iqn
 name is the same?

Marking? From an iSCSI standpoint having two (or even more) of the same IQN
is OK.

 
 And yes, happy holidays!!

You too!

--~--~-~--~~~---~--~~
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: Need help

[Konrad Rzeszutek]

On Mon, Jan 05, 2009 at 12:15:11AM -0800, Prachi Bodke wrote:
 
 Hi all,
 I am new to this iSCSI..
 I want to study the iSCSI interface with Linux.

Take a look at RFC 3720, then at RFC 3720.

It might also be useful to get acquainted with the SCSI specs hosted
by the T10 consortium (http://www.t10.org/scsi-3.htm)

 Can any1 help me out in this..??
 From where to start?? using that interface, i want to develop one
 small application..

It might be also useful for you to take a look at iSCSI Target product
and their source code. That should give you some ideas on how
to implement an iSCSI target (if that is also what you are looking for).

--~--~-~--~~~---~--~~
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: How to install open-iscsi only by moving files

[Konrad Rzeszutek]

On Thu, Dec 04, 2008 at 04:01:37AM -0800, [EMAIL PROTECTED] wrote:
 
 
 I also copied the /etc/init.d/open-iscsi
 
 but when I input the command
 ./open-iscsi start
 
 it reports errors:
 
 ;line 11: can't open /etc/init.d/functions

It looks as you are moving between distros - which is not a good
idea. Better would be to just install the version
of Open-iSCSI your other Linux distro comes with. Or you can
build from scratch the version on http://www.open-iscsi.org/

--~--~-~--~~~---~--~~
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: ifaces and assigning portals

[Konrad Rzeszutek]

On Fri, Oct 17, 2008 at 04:53:11AM -0500, Mark Chaney wrote:
 
 Id really appreciate it if someone could help me out with the above issue.
 Its driving me crazy and I have been spending hours trying to resolve the
 issue. Cant seem to find anything in the documentation that actually works
 to resolve it.
 
 Thanks,
 Mark
 
 -Original Message-
 From: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] On
 Behalf Of Mark Chaney
 Sent: Thursday, October 16, 2008 4:17 PM
 To: open-iscsi@googlegroups.com
 Subject: ifaces and assigning portals
 
 
 I have a dell md3000i with only a single controller in it, but it has two
 iscsi ports. Each one of my servers has two iscsi nics as well. I setup two
 ifaces per server and have iface0 and iface1 setup to each use their own
 switch. Each switch is connected to an individual iscsi port on the md3000i
 controller. Each network is on its own subnet.
 
 I am trying for the life of me to connect a single iface to a single portal,
 but I keep getting errors that no records are found. When I try to do any

I've had the same issue. The issue was that the OS routing would thwart my 
attempt
and connect to the other target over the ifaces.

 type of discovery methods, it keeps adding both interfaces to both ifaces,
 also seems to throw in ipv6 even though Im not using it on my network and
 don't want to (how can disable ipv6). 

The IPv6 is from the MD3000i. You need to go to iSCSI Port settings and
uncheck the IPv6 button.

 
 When I run iscsiadm -m discovery -t sendtargets -p 10.0.0.1, I get the
 following:
 
 
 
 [EMAIL PROTECTED] iscsi]# iscsiadm -m discovery -t sendtargets -p 10.0.0.1
 10.0.0.1:3260,1
 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4
 10.0.0.1:3260,1
 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4
 10.0.1.1:3260,1
 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4
 10.0.1.1:3260,1
 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4
 [fe80::::021e:4fff:fe3b:58fa]:3260,1
 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4
 [fe80::::021e:4fff:fe3b:58fa]:3260,1
 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4
 [fe80::::021e:4fff:fe3b:58fc]:3260,1
 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4
 [fe80::::021e:4fff:fe3b:58fc]:3260,1
 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4
 
 ###
 
 Even though I should only be getting 1 portal for each iface and definitely
 no ipv6.
 
 What should I be doing to accomplish the task of assigning only one portal
 to one iface and no ipv6 results showing in discoveries?

The IPV6 is easy. Turn it off in your storage.

For the one portal per one iface  do this

route add -host 10.0.1.1 dev iface0
route add -host 10.0.0.1 dev iface1

And so on. You can also make each of the target portals have its unique IP.
So instead of two 10.0.1.1 you can do 10.0.1.1 and 10.0.1.2 and be
more selective with the network routing.

 
 Looking for final results of two ifaces, 1 portal each, 1 active session
 each.

For that wouldn't you need four NICs? Since you have four IPv4 portals?
 
 Thanks,
 Mark
 
 
 
 
 
 
 
 
 
 
 
 

--~--~-~--~~~---~--~~
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: iscsi udev problem

[Konrad Rzeszutek]

On Tue, Oct 14, 2008 at 11:53:25AM +0200, Mega Mailingliste wrote:
 
 Hi dudes,
 
 i've got a problem with iscsid (2.0-868) under centos (5.2) and a infortrend
 iscsi san (s12e-r1132-4).
 
 After mapping some partitions of a logical volume to our server, I can login
 via iscsiadm to this luns. The problem is that udev (or anything else, but I
 think it's udev) won't make a mapping from /dev/sgx to /dev/sdx, thus I

The sg devices are very different from the sd ones. Or when you say mappings are
you referring to the /sys/block/sdX/device/generic link? (and vice-versa)? That 
is
the kernel constructing those.

 can't mount that device. I have no idea why :/

You can't mount the /dev/sdX device? Or is it that the /dev/sdX don't exist but
only the /dev/sgX show up? Can you provide the 'lsscsi -v' output?

 
 Some strange behavior before was, that I've got the same problem on another
 test server, but after some reboots the block-device /dev/sdx exists.
 
 Cheers
 Martin
 
 
 
 

--~--~-~--~~~---~--~~
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: Specify SCSI ID

[Konrad Rzeszutek]

On Sun, Sep 28, 2008 at 06:58:36AM -0700, Nick wrote:
 
 I'm trying to use open-iscsi to connect to an iSCSI-based tape
 library.  The library has two drives, so there are three IDs.
 Unfortunately, the library is picky about having the same SCSI IDs as
 are configured directly on the library, which means on the iSCSI
 client end I need to make sure that the devices show up with those
 same IDs.  This presents two problems:
 1) Each of the devices is presented as a separate iSCSI target.  This
 means that when open-iscsi connects to these three targets, they each
 get put on a different SCSI bus.  Any way to force all three targets
 onto the same bus?

Nope. Each of the connection is considered as a new HBA.

 2) open-iscsi starts ID numbering at 0.  Is there any way to configure
 an iSCSI target to show up at a certain ID?  So, my tape library is
 SCSI ID 8, my first drive is 9, and my second drive is 10.  Is there
 any way to configure these targets to show up at IDs 8, 9, and 10?

When you say ID, do you mean LUN?  What does 'lsscsi' show? 
Is your first drive the second target? If that is the case, it should
show up as so (with a different vendor/product name of course):

[0:0:0:8]tape   blah  blah  /dev/st0
[1:0:0:9]diskATA  WDC WD1600JD-75H 08.0  /dev/sda
[2:0:0:10]   diskATA  ST3160812AS  3.AD  /dev/sdb

But the last digit ought to be the same as your SCSI ID, unless the 
target decided to flatten this an opt to present them as 1-to-1 mapping
(one target == one LUN).

--~--~-~--~~~---~--~~
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: open-iscsi, Debian Etch and network disconnections

[Konrad Rzeszutek]

On Fri, Sep 26, 2008 at 07:40:36AM -0700, Vide wrote:
 
 Hi
 
 I'm trying to setup a Debian server as a front-end to an Infortrend
 SAN, but I'm experiencing problem when putting the remote storage on
 load with tiobench.
 Basically, the network interface loose link, all the time.
 
 This is an extract from the dmesg ouput when running tiobench. I'm
 using multipath-tools for HA and when one path fails, it switches
 automatically to the second path (though a second ethernet port) and
 then it fails as well.

Do you have the 'queue_if_no_path' option enabled in your multipath.conf
for that storage?

--~--~-~--~~~---~--~~
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: Extremely slow read performance, but write speeds are near-perfect!

[Konrad Rzeszutek]

 When we copy a file from the local disk array to the iSCSI target, the
 write performance is amazing: we max out the gigabit link immediately
 (100MB/sec writes easily). When we copy a file from the iSCSI target
 to the local disk array however, performance is absolutely *dreadful*:

Can you try to copy the file from the iSCSI target to /dev/null?

This will narrow down whether the problem is with the iSCSI target (or the
read mechanism in the iSCSI layer) or with your local disk.

Is the 'local disk array' a software RAID ?

--~--~-~--~~~---~--~~
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: Input/output error and strange problem ?

[Konrad Rzeszutek]

On Fri, Aug 29, 2008 at 11:12:34AM +0800, Chuanwen Wu wrote:
 
 Hi, Konrad!
 Thanks for you advice!
 
  Are you mounting that filesystem across many nodes (ie, through my 
  iscsi-initators)?
 
 Yes, that's exactly what I had done. I  want to use iscsi to transmit
 data in my distributed filesystem.

That will definitly fail.
 
  If so, then this is expected. ext3 is not clustered-aware filesystem and 
  won't
  behave properly. You would need to use GFS or GFS2 to do this.
 GFS2 or GFS seems have some problem in Genoo across to bugzilla.
 So you just think GFS/GFS2 is good enough ? Or is there any other
 recommended clustered-aware filesystem?

Those are the ones I know about. The GFS2 is an open-source project so
I would think it would be part of Gentoo?

--~--~-~--~~~---~--~~
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: Input/output error and strange problem ?

[Konrad Rzeszutek]

On Thu, Aug 28, 2008 at 11:21:19PM +0800, Chuanwen Wu wrote:
 
 Hi,
 
 I use open-iscsi-2.0.869.2 and iscsitarget-0.4.15-r1, and in my test,
 some strange errors occur.
 
 In all my iscsi-target, I have a ext3 fs. And I mount these fs in the
 iscsi-initator.

Are you mounting that filesystem across many nodes (ie, through my 
iscsi-initators)?

If so, then this is expected. ext3 is not clustered-aware filesystem and won't
behave properly. You would need to use GFS or GFS2 to do 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: open-iscsi ideal filesystem?

[Konrad Rzeszutek]

On Tue, Aug 26, 2008 at 11:37:46PM -0700, An Oneironaut wrote:
 
 Hey all,
 
 I was wondering if anyone out there had tested open-iscsi with a
 variety of Linux filesystems to see what works best.  Currently I am
 using the ext3 fs and for months now have been suffering problems.
 Anytime the iSCSI connection is dropped a variety of bad things can
 happen.  The fs will get corrupted, I/O errors will occur when doing
 shell operations on the volume, kernel oopses will occur, and so on.
 Most of this is probably related to the state of the iSCSI device.
 However tools like e2fsck take forever to fix a volume if it is 500
 Gigs and up.
 Are there any suggestions out there for alternatives?  Or are

Use multipath and make your iSCSI target use the 'queue_if_no_path' 
configuration.
Then you can use any filesystem on top of multipath and it won't matter
that the underlaying connection is disconnected - the machine will
just block the I/Os until it the iSCSI target is reconnected.

 there better ext3 tools that can fix the fs quicker?  How are the rest
 of you dealing with loss of connection and data corruption?

multipath.

--~--~-~--~~~---~--~~
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: Reducing amount of logmessages openiscsi/multipath

[Konrad Rzeszutek]

 So my questions:
 - Is there a way to suppress those messages, either in the iscsi programs or
 in multipath?

Yes. Add this in your multipath.conf file:

#
device {
vendor  DELL
product MD3000i
product_blacklist   Universal Xport
features1 queue_if_no_path
path_grouping_policygroup_by_prio
hardware_handler1 rdac
path_checkerrdac
priordac
failbackimmediate
}

If you are using a SLES10 SP2 version or the mainline one. I don't know
if the Red Hat version in RHEL5 has been updated to have the 'rdac' path 
checker.

 - If that fails, is it possible to tweak multipath in such a way that it
 doesn't check the two failed paths, unless there is no other path available?
 These two paths should become available only if the main controller dies.

The above configuration file does that.
 
 Thanks in advance,
 Kees Hoekzema
 
 
 

--~--~-~--~~~---~--~~
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: Reducing amount of logmessages openiscsi/multipath [with md3000i]

[Konrad Rzeszutek]

On Tue, Aug 19, 2008 at 12:20:05PM -0500, Mike Christie wrote:
 
 Kees Hoekzema wrote:
  Hello List,
 
 I am adding the dm-devel list.
 
 I think you want different settings in your multipath conf. For example 
 it looks like you are using directio to test paths and you want TUR or 
 the md3000i specific one which does not cause IO errors to passive paths.

He wants the RDAC hw handler and its path checker (rdac). The MD3000i is an
LSI re-branded box and is the same as the IBM DS3300.

 
 You also want to make sure that you are using the md3000i hw handler or 
 scsh_dh_module if you are not already. The dm-devel guys can help you out.

Here is the multipath.conf he should be using for MD3000i (or for the DS3300
but will need to modify the vendor/model entry)

# Note: The same as the IBM DS3300
#
device {
vendor  DELL
product MD3000i
product_blacklist   Universal Xport
features1 queue_if_no_path
path_grouping_policygroup_by_prio
hardware_handler1 rdac
path_checkerrdac
priordac
failbackimmediate
}


--~--~-~--~~~---~--~~
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: Multi-Path Connecitons

[Konrad Rzeszutek]

On Sat, Jul 19, 2008 at 11:36:55AM -0700, Mail Man wrote:
 
 I've been looking through the documentation and can find no reference
 for multi-path. Is this feature available under a different name?

The functionality of that is in package that is called 'multipath'.

--~--~-~--~~~---~--~~
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: Unmount at Logout

[Konrad Rzeszutek]

On Tue, Jul 15, 2008 at 01:37:52AM -0700, HIMANSHU wrote:
 
 Does iscsiadm having any option to check whether disks are in
 use(mounted)?

No.

--~--~-~--~~~---~--~~
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: IMPORTANT....initiator sensing target daemon restart + Header and Data Digest

[Konrad Rzeszutek]

On Wed, Jul 02, 2008 at 02:55:15AM -0700, HIMANSHU wrote:
 
 Hello,
 
 First of all,Thanks Mike for your continuous help.
 
 You are really making this list active.
 ---
 Consider the scenario,
 
 Open-iSCSI initiator connected to one IET target from target
 machine.
 
 Presently 2 LUN's were attached to it.
 
 Target machine adds 3rd LUN to the same target which is exposed to
 increase storage.
 
 Target machine daemon(iscsi-target) is restarted to make the changes
 reflect the initiator side.
 
 Initiator may/may not be undergoing I/O on the 2 exposed LUN's at that
 instance.
 
 on firing iscsiadm -m session -P 3,it will show status as Blocked
 for 1-2 seconds indicating that target configuration is changed.
 
 Then initiator has to perform iscsiadm -m session --rescan to add
 the 3rd LUN to target already exposed.
 
 My question is,
 
 1. Which signal initiator receives from target so that it can know
 target daemon is restarted??

Aren't the latest set of iscsi-target allowing you add a LUN without having
to restart the target daemon?
 
 I want initiator to have access of 3rd LUN after target added
 it.i.e. on which event,I should run  iscsiadm -m session --rescan??
 

I don't think the iscsi-target sends SCSI Asynchronous Events, so you probabally
want to do something like this:

sg_luns /dev/sdone of the block devices.. doesn't matter which one)  /tmp/old
while (true)
do
 sleep 60
 sg_luns /dev/sd.  /tmp/new
 diff /tmp/old /tmp/diff | grep -q 
 if [ $? == 0 ]; then
   iscsiadm -m node -R
 fi
done


 2. One way could be on initiator side,I should write a daemon/program
 to run iscsiadm -m session -P 3 continuously to sense if Disk state
 is blocked and iSCSI state is REOPEN.At that instance, I can run

 iscsiadm -m session --rescan to make changes reflect.
 
 But it will unnecessarily overload CPU a bit.
 
 My previous problem that initiator cannot recover the connection after
 target daemon restart/target machine reboot was solved.
 
 It was a really a silly mistake.
 
 Initiator side Header,Data digest configuration was not set according
 to target side.
 
 I set both to None.Then it can recover the connection.Though target
 side settings can be anything out of the 4 options.But it is not still
 working correctly with CRC32C instead of None.
 
 What is actually the need of Header and Data Digest???
 
 Does it have something to do with Discovery/Node level authentication??

It is set up during that phase. I would think it would go back to that
phase after you killed the iscsi-target thought..

 Or it just checks Header/Data integrity using checksum on both sides
 to ensure packets are not tampered.

Correct. Thought its primary purpose isn't to check if somebody altered the
packet. There are many ways to do that..
 
 I am using version 865.Version 868 doesn't make use of Data Digest
 at all.
 
 

--~--~-~--~~~---~--~~
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: Fedora iscsi

[Konrad Rzeszutek]

  Well, the QLA4xxx works OK, but you need to use the QLogic tools which are
  woefully out of date. Once you have it setup it works nicely.
 
  

 Thank´s Konrad...
 
 I have been studing the PCI Express for higher volume information 
 throughput. And the iscsi Qlogic´s HBA model
 is the QLE4xxx, instead of QLA4xxx. Do you have any expirience about it 

It is the same chipset. Just a different form-factor.

 ? Would this work as well as the QLA4xxx for Fedora environment ?

Yes. The qla4xxx driver supports both form-factors and both port-options (dual 
or single port).


--~--~-~--~~~---~--~~
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: Fedora iscsi

[Konrad Rzeszutek]

 OK!
 
 So, do you think that I´m in the right direction, when I say that I´m 
 going to create my own
 repository with some proprietary hardware and free software? Or it could 
 be a bad trip...

What is it that you are intending to do? If you are just looking to use iSCSI
I would recommend you first play with the Open-ISCSI initator (I presume you
already have an iSCSI target?). If you want no CPU load when doing iSCSI, then
the hardware HBA's are the choice.


--~--~-~--~~~---~--~~
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: How can I synchronize among different computers?

[Konrad Rzeszutek]

On Wed, Jul 02, 2008 at 12:13:16AM +0800, Kun Niu wrote:
 Thank you for your fast reply.
 Then will nfs will be a good choice?

Well, your Linux server would export the NFS directory - which would
be based on a filesystem. So you would be back to the same problem (still
mounting ext3 from two machines). Unless the MD3000i can export an NFS 
filesystem
which I don't think it can.


 Any other cluster filesystem suggestion?

http://en.wikipedia.org/wiki/Global_File_System

--~--~-~--~~~---~--~~
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: Open/iSCSI + Logout Response Timeout + replacement_timeout firing

[Konrad Rzeszutek]

 Ah if your disk are using write back cache then you are going to hit 
 some problems. So if you see this in /var/log/messages when you loging:
 
 kernel: sd 9:0:0:1: [sdb] Write cache: enabled,
 
 then later when you run iscsiadm to log out you see:
 
 kernel: sd 9:0:0:1: [sdb] Synchronizing SCSI cache
 
 Then you are going to hit problems due to the scsi sysfs interface 
 changing on us. iscsiadm is going to hang. IO is going to hang. You 
 basically have to reboot the box by hand.

Mike,

Are you sure about this? When the sysfs entries are deleted (during the 
iscsiadm logout phase), the SCSI ml finishes all of the I/Os and the last
operation is sending the SCSI Cache command. Wouldn't that quiesce I/O ? Granted
this means doing these steps which are outside the normal iscsiadm:
 1). flush dirty pages (call 'sync')
 2). delete the sysfs entries (echo 1  /sys/block/sdX/device/delete)
 3). wait until /sys/class/scsi_host/hostZ/host_busy reaches zero
 4). iscsiadm -m logout


--~--~-~--~~~---~--~~
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: Fileio Vs. Blockio

[Konrad Rzeszutek]

On Mon, Jun 23, 2008 at 05:22:00AM -0700, HIMANSHU wrote:
 
 If lun is having LV(i.e.Virtual Block device) in it,then it should be
 exposed as Blockio.
 If it is exposing Regular file,then it should use Fileio.
 Is it right?
 Regular file is exposed as a disk.What is difference between 'Blockio
 and Fileio in iSCSI.

You are asking these questions on the wrong mailing list.
The one you should be asking on is:

http://sourceforge.net/mailarchive/forum.php?forum_name=iscsitarget-devel

--~--~-~--~~~---~--~~
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: Disconnected iSCSI and umount problems

[Konrad Rzeszutek]

 If you guys have any advice or insight I'd appreciate the help.  I

Use multipath. Install the package and your iSCSI disk will be 
/dev/mapper/some-really-long-name

And you can tweak your settings in /etc/multipath.conf to queue the I/O
for long time while you re-login in the iSCSI.


--~--~-~--~~~---~--~~
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: Few iSCSI questions

[Konrad Rzeszutek]

On Tue, Jun 17, 2008 at 05:10:10AM -0700, HIMANSHU wrote:
 
 1.
 You say that performance figures are this..
 
 single iSCSI session:
 
 * 450MB/s Read and 450 MB/s Write for 64KB block
 * 510 MB/s Read and 550 MB/s Write for 256KB block
 * 65,000 IOPS - 1K, 58,000 IOPS - 2K, 50,000 IOPS with 4KB Read
 
 two iSCSI sessions:
 
 * 550 MB/s Read and 810 MB/s Write for 256KB block
 * 75,000 IOPS for 1K block
 
 How can we measure figures on our machine?
 Iometer , disktest are few tools available for that.
 Can u suggest any good one?

I've used 'iozone' but you can also just do variations of 'dd' with different
block sizes. And play around with changing the MTU.

  
 ---
 2.
 When Initiator can get access to disk from target,What all
 applications user can have?Means besides Storage,what is the use of
 this Disk?

None. It is just as a normal disk.

 
 3.
 If one initiator is logged in to target iqn.
 2008-06.com.companyname:BLOCKIO_TARGET which is 1 GB.
 
 It thus have access to it,it partitions it using fdisk.Creates file
 system using mkfs.mounts it and writes 300 MB data on it.
 
 If second initiator machine logs in to the same target,it can view all
 the 300 MB data written by 1st initiator if 2nd initiator doesn't
 format that disk after login. 2nd initiator only mounts the logged in
 disk and thus had access to all the 300 MB data. Is it ethical?

You can do it but without using a proper filesystem that can deal with
multiple writers/readers it will be hosed. Look in using 'gfs2' filesystem
(or GFS from Red Hat, or GPFS from IBM) along with the cluster componenents
to synchronize the disk usage.

You might be tempted in thinking that you can mount from one initiator
the disk as read-only with 'ext3' or 'ext3' - but from what I've heard
that still leads to errors.

 
 Should we allow same target to be shared by multiple initiators at the
 same time?

If you want to use Xen and transition between nodes then yes you want
to use it.

Also for clustering software this can be used - where there is a shared
storage.

 
 What will be the pros and cons?

Look up on Google 'cluster software pros' to find that out.

 
 I think,we need to handle synchronization issues there.Data written by
 1st initiator shouldn't be deleted by others and all..
 
 Or Data from 1st initiator should not be visible/accessible to others.
 
 What approach looks more ethical and practical?

Use cluster software. 

 ---
 
 

--~--~-~--~~~---~--~~
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: Syntax for logging in to regular file

[Konrad Rzeszutek]

On Tue, Jun 10, 2008 at 10:27:00PM -0700, HIMANSHU wrote:
 
 Currently iSCSI targets contains LV's.
 
 --
 Target iqn.2008-06.com.qualexsystems:Tar3
 Alias Tar3
 #instead of adding LV here,regular file should be added.
 Lun 0 Path=/dev/Vg1/lvISCSI3,Type=fileio
 - /tmp/some_file

Wherein your /tmp/some_file is maybe an ISO copy of your favorite distro
or what-not.


--~--~-~--~~~---~--~~
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: Turning off NOP's

[Konrad Rzeszutek]

On Wed, Jun 11, 2008 at 03:21:53PM -0400, Eddy Quicksall wrote:
 
 How can I turn off NOP-out's in the initiator?

In your iscsid.conf set:
node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

Thought I don't think you need to set the timeout...

--~--~-~--~~~---~--~~
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: Feature: Support sysfs/firmware/ibft parsing.

[Konrad Rzeszutek]

 
 Konrad, could you convert this to the sysfs api in the open-iscsi git tree?

Sure. But it will take a bit of time (a bit of other things on my plate right 
now).

--~--~-~--~~~---~--~~
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: Install XEN on CentOS iscsi Root

[Konrad Rzeszutek]

On Fri, May 30, 2008 at 05:12:03PM -0700, a s p a s i a wrote:
 
 Hey Konrad 
 
 my iscsiroot image did not boot ... i'm wondering if i had a corrupt
 installation ...
 
 it goes through the pxelinux config stage and then stops and says
 corrupt boot image, and the boot: prompt appears ...
 
 i will ponder further on this if you have any thoughts would be
 greatly appreciated 

Try running 'mkintrd -v /boot/initrd-2.6.18-53.1.21.el5xen.img 
2.6.18-53.1.21.el5xen`
and see if it generates it without any failures. You should see:
Found iscsi component


--~--~-~--~~~---~--~~
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: Design Questions

[Konrad Rzeszutek]

On Mon, Jun 02, 2008 at 01:32:15PM -0300, Arturo 'Buanzo' Busleiman wrote:
 
 On May 30, 10:29 am, Konrad Rzeszutek [EMAIL PROTECTED] wrote:
   If you run iSCSI on each guests you end up with overhead.
 
 I decided the same. So I'm running iscsi on the host, and via 
 /dev/disk/by-path/whatever provide the guests with SAN storage.
 
 Bad thing there, for each virtual disk of the san, I get two /dev 
 entries, so I'm wondering how to setup the multipath over those two 
 /dev/disk/by-path entries (one over each controller).
 
 I also noticed the IPv^ thing, so I ended up specifying the IP by hand, 
 and using to iscsiadm commands for each discovery / session initiation. 

That works. Bit of a hack. Why not just use the IPv4 on both interfaces?

 Also, as you said, link aggregation makes no sense over crossover and 
 two different interfaces.

Well, you could use load balancing or play with ifaces with your two NICs
and take advantage of the two Ethernet cables from your target. 

What this means is that you can setup the /dev/sdc to go over
one of your NICs, and the /dev/sdf over the other. For that look in
the README file and read up about ifaces. This is the poor man fine-grained
NIC configuration.

Or you can use load balancing where you bond both interfaces in one, but
for that you need a switch..  And the same for link aggregation or
link failure.

But as said before, you are doing cross-over so go with ifaces to
take advantage of setting up two sessions on both NICs.

 
 What I'm NOT doing, is LVM. I wanted to go one layer at a time, and 
 adding LVM was too much for my limited time in here.
 
 So, currently, I have two remaining issues:
 
 1) setup multipath

That is pretty easy. Just install the package and the two block devices
(or four if you are using a dual-controller) will be /dev/mapper/some really
long UUID on which you can use LVM.

 2) **URGENT**: I've added a second virtual disk and mapped it to my host 
 (SAN is an MD3000i, host is ubuntu server with 2.6.24-17, i'm waiting 
 for 2.6.25 which fixes the skb broadcast bug it seems).

Huh? What skb broadcast bug?

 If I use hwinfo, I can see the virtual disk (over /dev/sdc and the 2nd 
 entry, /dev/sdf). Over fdisk, I get NOTHING.

fdisk -l doesn't give you data?

 
 Here's the dmesg output, hwinfo output, and fdisk output:
 
 HWINFO
 ==
 40: SCSI 300.1: 10600 Disk
   [Created at block.222]
   Unique ID: uBVf.EABbh0DH0_1
   SysFS ID: /block/sdc
   SysFS BusID: 3:0:0:1
   SysFS Device Link: /devices/platform/host3/session1/target3:0:0/3:0:0:1
   Hardware Class: disk
   Model: DELL MD3000i
   Vendor: DELL
   Device: MD3000i
   Revision: 0670
   Serial ID: 84L000I
   Driver: sd
   Device File: /dev/sdc (/dev/sg4)
   Device Files: /dev/sdc, 
 /dev/disk/by-id/scsi-36001e4f00043a3da04dc4843982f, 
 /dev/disk/by-path/ip-192.168.131.101:3260-iscsi-iqn.1984-05.com.dell:powervault.6001e4f0004326c1482127e3-lun-1
   Device Number: block 8:32-8:47 (char 21:4)
   Geometry (Logical): CHS 102400/64/32
   Size: 209715200 sectors a 512 bytes
   Drive status: no medium
   Config Status: cfg=new, avail=yes, need=no, active=unknown
 
 That drive status: no medium drives me crazy. For comparison, this is 

Uh.. don't go crazy. Just install multipath and make sure you have this
configuration entry in mulitpath.conf file:

 device {
vendor  DELL
product MD3000i
product_blacklist   Universal Xport
features1 queue_if_no_path
path_checkerrdac
hardware_handler1 rdac
path_grouping_policygroup_by_prio
priordac
failbackimmediate
}   

Keep in mind that depending on what version of multipath you install
you might not have the 'rdac' path checker or that the path priority
program is called differently. Get the latest one and see what config
options you need.

(The above works with SLES10 SP2).

 the output for the first virtual disk I created, the one I can access:
 
 41: SCSI 300.0: 10600 Disk
   [Created at block.222]
   Unique ID: R0Fb.EABbh0DH0_1
   SysFS ID: /block/sdb
   SysFS BusID: 3:0:0:0
   SysFS Device Link: /devices/platform/host3/session1/target3:0:0/3:0:0:0
   Hardware Class: disk
   Model: DELL MD3000i
   Vendor: DELL
   Device: MD3000i
   Revision: 0670
   Serial ID: 84L000I
   Driver: sd
   Device File: /dev/sdb (/dev/sg3)
   Device Files: /dev/sdb, 
 /dev/disk/by-id/scsi-36001e4f0004326c105b3483e9c7a, 
 /dev/disk/by-path/ip-192.168.131.101:3260-iscsi-iqn.1984-05.com.dell:powervault.6001e4f0004326c1482127e3-lun-0
   Device Number: block 8:16-8:31 (char 21:3)
   Geometry (Logical): CHS 261/255/63
   Size: 4194304 sectors a 512 bytes
   Config Status: cfg=new, avail=yes, need=no, active=unknown
 

That looks wrong. How many controllers do you have?  I wonder if this is 
related to
the other session that didn't login. Have you set the LUN1 disk to have
a preferred controller which is the one using IPv6

Re: Problems accessing virtual disks on MD3000i, was: RE: Design Questions

[Konrad Rzeszutek]

 Apparently, no changes, except that there are no partitions sde through sdg.
 hwinfo and fdisk still report the same.
 
 Btw, I also removed the Access DellUtility partition. No difference 
 either, except that /dev/sdd disappeared :)
 
 Any other ideas?

multipath-tools? Did you install it?

--~--~-~--~~~---~--~~
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: Install XEN on CentOS iscsi Root

[Konrad Rzeszutek]

On Thu, May 29, 2008 at 02:35:31PM -0700, aspasia wrote:
 
 Hello all,
 
 So I wanted to also provide the option of my diskless server users to
 boot CentOS51 Xen kernel via iSCSI root ... Instead of building the
 image with an installation on hard drive, I thought I'd boot on an
 existing copy of an iscsiRoot golden image and upgrade CentOS51 to xen
 kernel from there.  I did the following:
 
 1.  yum install kernel-xen xen
 
 2.  I was going to manipulate the Xen initrd but when I ls'ed into
 the /boot directory - the installation did not include providing a Xen-
 specific initrd.

That is weird. Try running 'new-kernel-pkg --mkinitrd --depmod --install 
2.6.18-53.1.21.el5xen'
as root and seeing if that generates the initrd images.

--~--~-~--~~~---~--~~
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: Design Questions

[Konrad Rzeszutek]

On Thu, May 29, 2008 at 02:35:28PM -0300, Arturo 'Buanzo' Busleiman wrote:
 
 On May 28, 2:45 pm, Konrad Rzeszutek [EMAIL PROTECTED] wrote:
   I am not sure how you are partitioning your space. Does each guest
   have an iSCSI target (or LUN) assigned to it? Or is it one big
   drive that they run from? Also are you envisioning using this
   with LiveMigration (or whatever it is called with your virtualization
   system)?
 
 I'm using Vmware-Server (not ESX, just the free one).
 
 The guests themselves (the disk where the OS is installed) are stored as 
 vmdk's on a local folder.
 
 I want to provide application storage for each virtual machine, no 
 shared storage. I have 1.6TB total capacity, and plan on giving each 
 guest as much raid-5 storage space as they need.
 
 The iscsiadm discovery on my Host reports all available targets, over 
 both interfaces (broadcom and intel).
 
 So, basicly, I have these doubts / options:
 
 1) Login to each target on the host, and add raw disk access to the 
 guests to those host-devices.
 2) Don't use open-iscsi on the host, but use it on each guest to connect 
 to the targets.
 

If you run iSCSI on each guests you end up with overhead. Each guests will
have to do its own iSCSI packet assembling/disassembling, along with doing
socket operations (TCP, IP assembling) and your target will X-Guests
connections. Each guest would need to run the multipath suite which puts
I/O on the connection every 40 seconds (or less if a failure has occurred).

If on the other hand you make the connection on your host, setup
multipath there, create LVMs and assign them to each your guests you have:
 - less overhead (one OS doing the iSCSI packet assembling/disassembling),
   TCP/IP assembling.
 - one connection to the target. You can even purchase extra two NICs and
   create your own subnet for them and the target so that there is no
   traffic there (except iSCSI).
 - one machine running multipath and you can make it queue I/O from
   place if the network goes down. This will block the guests (you might
   need to change the SCSI timeout in the guests - no idea what registry
   key you need to change for this in Windows).
 - One place to zone out your huge capacity and you can resize them
   as you see fit from one place (using LVMs for guests and you can
   re-size them).

 And the main doubt: how does link aggregation / dualpath fit into those 
 options?

I can't give you an opinion about link aggregation as I don't have that
much experience in this field.

But in regards to multipath you are better of doing it on your host
than on the guest.
  
 Also, i find this error:
 
 [EMAIL PROTECTED]:~# iscsiadm -m node -L all
 Login session [iface: default, target: 
 iqn.1984-05.com.dell:powervault.6001e4f0004326c1482127e3, 
 portal: 192.168.130.102,3260]
 Login session [iface: default, target: 
 iqn.1984-05.com.dell:powervault.6001e4f0004326c1482127e3, 
 portal: fe80::::021e:4fff:fe43:26c3,3260]
 iscsiadm: initiator reported error (4 - encountered connection failure)
 iscsiadm: Could not log into all portals. Err 107.

Did you configure your ethX to use IPV6? The second target IP 
is in IPv6 format.

 
 I'm using crossover cables.

No switch? Then link-aggregation wouldn't matter I would think (since
the ARP requests aren't going to a switch).
 
 
  

--~--~-~--~~~---~--~~
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: Install XEN on CentOS iscsi Root

[Konrad Rzeszutek]

 [EMAIL PROTECTED] /]# new-kernel-pkg --mkinitrd --depmod --install
 2.6.18-53.1.21.el5xen
 grubby fatal error: unable to find a suitable template
 [EMAIL PROTECTED] /]#

Hmm.. When you installed the kernel-xen did it update your mkinitrd as well?
No idea what this means. You can try to prefix the program with 'sh -x' as

[EMAIL PROTECTED] /]# sh -x new-kernel-pkg --mkinitrd --depmod --install
2.6.18-53.1.21.el5xen

to see what arguments it passes to grubby. Could be that some of
them are no good.

--~--~-~--~~~---~--~~
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: Install XEN on CentOS iscsi Root

[Konrad Rzeszutek]

On Fri, May 30, 2008 at 10:47:38AM -0700, a s p a s i a wrote:
 
 ok .. will check wiith the sh -x
 
 Just to be clear:
 
 I tried to run the command below using my current - non-xen kernel -
 that is ok to do so?

Should be if there were no errors returned. Thought it might be prudent
to backup the original just in case the regenerated is funked.

--~--~-~--~~~---~--~~
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: A few newbie questions

[Konrad Rzeszutek]

On Wed, May 28, 2008 at 05:32:03AM -0700, jergendutch wrote:
 
 Hello,
 
 I have iscsi setup on some boxes. They can all mount a central target
 in succession but not at the same time. This is fine, I have installed
 GFS to make this work.
 
 I read somewhere (and this is where I need the help) that open-iscsi
 limits the number of connections per lun to one, and I need to
 increase this to the number of hosts. Can anyone tell me where this
 is, I cannot find it any more.

Not sure where you read it, but that is false. The default LUN max is
512.

 
 My second question is about startup.
 At the moment I start iscsi, then I run the discovery command, then
 restart iscsi to see the disk.
 
 This seems wrong. Is there a better way?

When you run the discovery command the results are cached. When you
log-in the session is also cached. So you init script should
take advantage of that and automaticly log-in to those targets.

You did log-in to those targets after the discovery, right?

--~--~-~--~~~---~--~~
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: open-iscsi with Promise M500i dropping session / Nop-out timedout

[Konrad Rzeszutek]

On Wed, May 28, 2008 at 03:34:37PM +0300, Pasi Kärkkäinen wrote:
 
 Hello list!
 
 Unfortunately I had to upgrade a server running CentOS 4.6 (sfnet initiator) 
 to CentOS 5.1 (open-iscsi initiator) and now I have some problems with it
 (then again I was expecting it.. I hate this Promise array).
 
 /var/log/messages:
 
 May 28 15:14:16 server1 multipathd: path checkers start up
 May 28 15:15:39 server1 iscsid: Nop-out timedout after 10 seconds on 
 connection 14:0 state (3). Dropping session.
 May 28 15:15:42 server1 iscsid: connection14:0 is operational after recovery 
 (2 attempts)
 May 28 15:19:21 server1 kernel: sd 16:0:0:0: SCSI error: return code = 
 0x0002
 May 28 15:19:21 server1 kernel: end_request: I/O error, dev sdd, sector 
 190057296
 May 28 15:19:21 server1 kernel: device-mapper: multipath: Failing path 8:48.
 May 28 15:19:21 server1 kernel: sd 16:0:0:0: SCSI error: return code = 
 0x0002
 May 28 15:19:21 server1 kernel: end_request: I/O error, dev sdd, sector 
 190057552
 May 28 15:19:21 server1 kernel: sd 16:0:0:0: SCSI error: return code = 
 0x0002
 May 28 15:19:21 server1 kernel: end_request: I/O error, dev sdd, sector 
 190057560
 May 28 15:19:21 server1 multipathd: sdd: readsector0 checker reports path is 
 down
 May 28 15:19:21 server1 multipathd: checker failed path 8:48 in map 
 promise_test1
 May 28 15:19:21 server1 multipathd: promise_test1: remaining active paths: 1
 May 28 15:19:21 server1 iscsid: Nop-out timedout after 10 seconds on 
 connection 14:0 state (3). Dropping session.
 May 28 15:19:25 server1 iscsid: connection14:0 is operational after recovery 
 (2 attempts)
 May 28 15:19:26 server1 multipathd: sdd: readsector0 checker reports path is 
 up
 May 28 15:19:26 server1 multipathd: 8:48: reinstated
 May 28 15:19:26 server1 multipathd: promise_test1: remaining active paths: 2
 May 28 15:19:26 server1 multipathd: promise_test1: switch to path group #1
 
 $ iscsiadm -m node --targetname name | grep timeo 
 node.session.timeo.replacement_timeout = 15
 node.session.err_timeo.abort_timeout = 10
 node.session.err_timeo.reset_timeout = 30
 node.conn[0].timeo.logout_timeout = 15
 node.conn[0].timeo.login_timeout = 15
 node.conn[0].timeo.auth_timeout = 45
 node.conn[0].timeo.active_timeout = 5
 node.conn[0].timeo.idle_timeout = 60
 node.conn[0].timeo.ping_timeout = 5
 node.conn[0].timeo.noop_out_interval = 5
 node.conn[0].timeo.noop_out_timeout = 10
 node.session.timeo.replacement_timeout = 15
 node.session.err_timeo.abort_timeout = 10
 node.session.err_timeo.reset_timeout = 30
 node.conn[0].timeo.logout_timeout = 15
 node.conn[0].timeo.login_timeout = 15
 node.conn[0].timeo.auth_timeout = 45
 node.conn[0].timeo.active_timeout = 5
 node.conn[0].timeo.idle_timeout = 60
 node.conn[0].timeo.ping_timeout = 5
 node.conn[0].timeo.noop_out_interval = 5
 node.conn[0].timeo.noop_out_timeout = 10
 
 Basicly those Nop-out timedout errors keep showing up all the time when
 there is IO going on.. and if I have dd if=/dev/mpath of=/dev/null running 

You can expand the timeout to a higher value? 30 seconds ? Also you might
want to limit the node.session.queue_depth to a lower value as well.

 IO rates seem to go down every 20 seconds or so and stay stalled (at 0) for 
 5 seconds or so.. weird.

That could be due to the NOP not getting its response and stalling the session
until it receives the response.

--~--~-~--~~~---~--~~
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: Design Questions

[Konrad Rzeszutek]

On Wed, May 28, 2008 at 01:15:36PM -0300, Arturo 'Buanzo' Busleiman wrote:
 
 Arturo 'Buanzo' Busleiman wrote:
  So, the obvious question here: I want to store the data in the SAN. 
  Should I get my sessions running in the host, or inside each virtual 
  machine?
 If this is not the correct group to ask this question, I'd gladly accept 
 suggestions for other groups! :)

I am not sure how you are partitioning your space. Does each guest
have an iSCSI target (or LUN) assigned to it? Or is it one big
drive that they run from? Also are you envisioning using this
with LiveMigration (or whatever it is called with your virtualization
system)?

--~--~-~--~~~---~--~~
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: Help! On Ubuntu or RHEL 5.1 client I always get: iscsiadm: discovery session to [IP] received unexpected opcode 0x20

[Konrad Rzeszutek]

On Wed, May 28, 2008 at 09:56:38AM -0700, [EMAIL PROTECTED] wrote:
 
 Has anyone experienced this error?  I have no firewall, no SELinux
 running, etc.  The iSCSI target should be fine as windows clients were
 able to utilize the sanfly targets before (or ones like it).

Well, the error is just bizzare. It looks as the target is misbehaving
and the initiator can't handle that.

Can you capture the TCP data and provide on the mailing list? That can
help a bit in narrowing down the problem. Search for 'tcpdump' and for
e-mails from Mike Christie on how to sniff your TCP session data.

 
 Is there a howto or directions I can follow?  Can I not do a discovery
 and just connect to it directly? What commands should I be using?  I

Those are the proper steps (well, you can substitue the /etc/init.d/open-iscsi
restart with iscsiadm -m node -L all). What is your iSCSI target?

--~--~-~--~~~---~--~~
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: Should connection restored?

[Konrad Rzeszutek]

 The Rule: Only after logout,target daemon can be restarted.
 
 But it sounds little weird.is it?

It looks like a safety feature. 

 
 If some I/O going on the initiators side,i cannot logout that target.

You sure about that? Did you do 'iscsiadm -m node -U all' and the
session wouldn't logout?

 
 Without restarting target daemon,we can not make target/LUN
 addition,modification changed to reflect on initiators on discovery
 commmand.

From the initiator side that is not true. The initiator can
get new targets, rescan the LUNs, find new devices, etc. The limitation
is in the iscsi-target software which doesn't allow you to dynamically
do these things. If you have the experience you could write this
functionality and propose it to the iscsi-target folks.


--~--~-~--~~~---~--~~
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: System hanging with MD3000i with Debian Etch

[Konrad Rzeszutek]

On Sun, May 18, 2008 at 06:21:17PM -0700, Bryan Mclellan wrote:
 
 Of the linux servers console? Sure I can dig one up, it's the first two lines 
 of the scsi disk sort of display, twice. Something sort of like:

Preferably the whole thing from start. Not just the last X lines.

 
 Disk: DELL  Model: MD3000
 Blah blah   blah blah
 
 I don't recall exactly what it said, but it wasn't very interesting.

It is for kernel engineers. Also please pass in as bootup parameter this value 
'loglevel=8'.

--~--~-~--~~~---~--~~
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: Logical Unit Not Ready, Initializing Cmd. Required

[Konrad Rzeszutek]

On Thu, May 15, 2008 at 10:07:32PM -0700, sinysee wrote:
 
 Hello,
 
 I am trying to use open-iscsi to connect to an FC storage via an ATTO
 IPBridge 2700C. This is not a planned setup, but an emergency attempt
 to regain access to the data after an FC switch failure.
 
 I am using SLES 10.1 on the host. When trying to connect to the target
 I get through the discovery stage successfully. When I log in,
 iscsiadm returns success, but there are messages like
 
   sd 17:0:0:1: Device not ready: 6: Current: sense key: Not Ready
Additional sense: Logical unit not ready, cause not reportable
 
 in the kernel log and the device never gets available.

What do you mean by never gets available? Can you attach the full dmesg? Is 
it that
the block device (/dev/sdX) that is unavailable or the multipath device 
(/dev/dm-XX)?

Is it all of them or just one or two?
 
 I got the tcpdump from the host and it shows that the host repeatedly
 sends Test Unit Ready requests and receives Logical Unit Not Ready,
 Initializing Cmd. Required (0x0402) in response. Mode Sense and
 Read Capacity get meaningful responses. Then the host does a Read
 request and gets Logical Unit Not Ready, Cause Not Reportable
 (0x0400).

Is that for each of the block disks that showed up when you logged in
or just for some of them? If it is the latter than is expected with
Active-Passive targets which you might have.

.. snip..
 Having very little prior experience with iSCSI I am not sure what
 Initializing Cmd. Required is supposed to mean.

This looks more like an multipath configuration, or the lack of
it.

--~--~-~--~~~---~--~~
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: Logical Unit Not Ready, Initializing Cmd. Required

[Konrad Rzeszutek]

On Fri, May 16, 2008 at 08:28:43AM -0700, sinysee wrote:
 
 Hello,
 
  What do you mean by never gets available? Can you attach the full dmesg? 
  Is it that
  the block device (/dev/sdX) that is unavailable or the multipath device 
  (/dev/dm-XX)?
 
 I am looking to set up an initiator-target configuration with an FC-
 iSCSI bridge in between.
 As I understand the bridge should be transparently packaging an FC
 disk as an iSCSI target.
 
 After
 # iscsiadm -m node -p target portal -T target -l
 I get errors in dmesg and finally
sd 6:0:0:1: Attached scsi disk sdb

So the block disks show up fine. That means iSCSI works just fine.

 However
 # fdisk /dev/sdb
 Returns with
Unable to read /dev/sdb
 Finally,
 # iscsiadm -m node -p target portal -T target -u
 returns.
 
 I am attaching the relevant part of the dmesg log. Hope it can clarify
 the problem

You only see one disk? Either way, are you running multipath on your machine?
If you are, what is the multipath -ll output?

 
 Dear Konrad, I find it strange that the host does not send Request
 Sense after receiving an error
 for Test Unit Ready. Is it a legit SCSI behaviour?

The kernel intoragates the disks and that is what it gets. It reports to you
these errors. There is no need to send a Request Sense command as the Test Unit
Ready has already provided you the SCSI error, along with the ASC/ASCQ values, 
as
you can see:

 sd 6:0:0:1: Device not ready: 6: Current: sense key: Not Ready
 Additional sense: Logical unit not ready, cause not reportable

The next step for enterprise storages, such as the HP StorageWorks
is to issue a START SCSI command - which is what you should see if you
are using multipath. The path checker would start the LUN.

--~--~-~--~~~---~--~~
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: connection2:0: detected conn error (1011).. when rebooting the machine hangs the reboot sequence.

[Konrad Rzeszutek]

 Synchronizing SCSI cache for disk happens because:
 
 - iSCSI sessions were not properly disconnected, and

Correct.

 - they can't be properly disconnected any more, because the network is 
 already disabled.

Kind of. There is a kernel timer that gets activated during the logout sequence
that waits for up to 120 seconds (or what you have set in
node.session.timeo.replacement_timeout) and if the logout sequence hasn't 
completed releases the kernel resources.

 
 Most distributions shut down all network interfaces when a halt 
 command is started (i.e., they add -i option to the halt command):
 
  -i: shut down all network interfaces.
 
 Without this flag, everything should shut down properly, even when it's 

Right. And this situation will hang the kernel during reboot b/c the
SCSI error handlers wait for a logout state condition that never happens.

 not possible to logout all sessions earlier (i.e., a diskless machine 
 started off iSCSI).

And the patch I attached in the previous e-mail describes a solution
to 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
-~--~~~~--~~--~--~---

Feature: Support sysfs/firmware/ibft parsing.

[Konrad Rzeszutek]

Mike,

I've added the bug-fixes and the missing functionality you put in RHEL5.2 to 
make this
one check-in. But if you would like me to split it out in two posts: initial 
code and
bugfix I would be more than happy to do this.

This patch parses the kernel exposing the iBFT information via the sysfs entry.
Here is the git commit from the kernel.org:

commit 138fe4e069798d9aa948a5402ff15e58f483ee4e
Author: Konrad Rzeszutek [EMAIL PROTECTED]
Date:   Wed Apr 9 19:50:41 2008 -0700

Firmware: add iSCSI iBFT Support

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along 
with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table?  It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target.  Currently the iSCSI
information is hard-coded in the initrd.  The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do  echo -n $a: ;  
cat $a; done
/sys/firmware/ibft/target0/target-name: 
iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: 
iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0



 Makefile |3 
 fw_entry.c   |3 
 fwparam_ibft.h   |3 
 fwparam_ibft_sysfs.c |  330 +++
 4 files changed, 336 insertions(+), 3 deletions(-)


 Signed-off-by:  Konrad Rzeszutek [EMAIL PROTECTED]


diff --git a/utils/fwparam_ibft/Makefile b/utils/fwparam_ibft/Makefile
index 6d7d00a..71d27a9 100644
--- a/utils/fwparam_ibft/Makefile
+++ b/utils/fwparam_ibft/Makefile
@@ -20,8 +20,7 @@
 #  Doug Maxey [EMAIL PROTECTED]
 #  Prasanna Mumbai [EMAIL PROTECTED]
 #
-
-OBJS := fwparam_ibft.o fw_entry.o
+OBJS := fwparam_ibft.o fw_entry.o fwparam_ibft_sysfs.o
 OBJS += prom_lex.o prom_parse.tab.o fwparam_ppc.o
 CLEANFILES = $(OBJS) *.output *~
 
diff --git a/utils/fwparam_ibft/fw_entry.c b/utils/fwparam_ibft/fw_entry.c
index 915bbb7..e575da4 100644
--- a/utils/fwparam_ibft/fw_entry.c
+++ b/utils/fwparam_ibft/fw_entry.c
@@ -29,7 +29,10 @@ int fw_get_entry(struct boot_context *context, const char 
*filepath)
 
ret = fwparam_ppc(context, filepath);
if (ret)
+   ret = fwparam_ibft_sysfs(context, filepath);
+   if (ret)
ret = fwparam_ibft(context, filepath);
+
return ret;
 }
 
diff --git a/utils/fwparam_ibft/fwparam_ibft.h 
b/utils/fwparam_ibft/fwparam_ibft.h
index 90ecb17..0eed9cd 100644
--- a/utils/fwparam_ibft/fwparam_ibft.h
+++ b/utils/fwparam_ibft/fwparam_ibft.h
@@ -153,6 +153,7 @@ extern int dev_count;
 #define TARGET target
 
 extern int fwparam_ibft(struct boot_context *context, const char *filepath);
+extern int fwparam_ibft_sysfs(struct boot_context *context,
+   const char *filepath);
 extern int fwparam_ppc(struct boot_context *context, const char *filepath);
-
 #endif /* FWPARAM_IBFT_H_ */
diff --git a/utils/fwparam_ibft/fwparam_ibft_sysfs.c 
b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
new file mode 100644
index 000..004a1ea
--- /dev/null
+++ b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
@@ -0,0 +1,330 @@
+/*
+ * Copyright (C) IBM Corporation. 2007
+ * Copyright (C) Konrad Rzeszutek, 2008
+ * Author: Konrad Rzeszutek [EMAIL PROTECTED]
+ *
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#define  _XOPEN_SOURCE 500
+#include

Re: target*/*/block:change

[Konrad Rzeszutek]

On Wed, May 14, 2008 at 01:29:43PM +0200, Stefan de Konink wrote:
 
 What was the reason for adding the block device name to the block symlink
 if this symlink already provides this name?

I find it useful when doing this:

 find /sys/class/iscsi_session/session*/device/ -name block:* | sed 's/.*:/'

And I can get all of the block disks names without have to read the link(s).

 
 It probably breaks everything that uses this block path directly to find
 out the device it is pointing to.

Not sure what you mean. This sysfs structure has been in existence for some 
time (since 2.0-754)
so code written to use this format is not broken.

I would think that code that uses the block device would be using the
/sys/block/sdX interface instead?


--~--~-~--~~~---~--~~
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: Accessing specific lun in target with open-e

[Konrad Rzeszutek]

  Attached scsi disk sds  State: running
 
 Nothing said about the snapshot.
 
 Anyone has an idea? Would that be a specific to open-e dss storage?

What does

#sg_luns /dev/sds

give you?

(sg_luns is part of sg3_utils package).

--~--~-~--~~~---~--~~
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: Should connection restored?

[Konrad Rzeszutek]

On Fri, May 09, 2008 at 02:36:25AM -0700, MAKHU wrote:
 
 Hello All,
 
 1. I am using latest iscsitarget-0.4.16-1 from sourceforge.

And an older version of Open-iSCSI..would say 868-20. Have you tried
using the one that got released about a week ago?

... snip ...
 
 Host Number: 14 State: running
 scsi14 Channel 00 Id 0 Lun: 0
 Attached scsi disk sdh  State: running
 scsi14 Channel 00 Id 0 Lun: 1
 Attached scsi disk sdi  State: running
 
 Though Disk state is running,still iSCSI Connection State: IN LOGIN.
 So disks still becomes unusable.

Are the disks really unusable? What happens when you do 'dd if=/dev/sdh 
of=/dev/null count=1' ?

--~--~-~--~~~---~--~~
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: Should connection restored?

[Konrad Rzeszutek]

On Thu, May 08, 2008 at 08:52:35AM -0700, MAKHU wrote:
 
 When target is logged in to an initiator and then either target/
 initiator is restarted,connection is lost.

It goes the other way. Initiator logs in the target.

If the initiator (client) is restarted the connection would be lost.
If the target is restarted it might do:
 1). If it a NetApp, send a command asking the initiator to logout.
 2). If is a EqualLogic, send a AsyncMsg telling the initiator that the block
 device is going to be off-line.
 3). For others it might just terminate the connection without notifying
 the initiator at all. At which point the nop-ping timer (which runs
 by default every 15 seconds) would figure out the connection is lost, kick
 a retry and if that failed terminate the connection.

--~--~-~--~~~---~--~~
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: iscsi root on Ubuntu

[Konrad Rzeszutek]

On Fri, May 02, 2008 at 11:48:16PM +0200, Tomasz Chmielewski wrote:
 
 aspasia schrieb:
  
  
  On May 2, 7:14 am, Tomasz Chmielewski [EMAIL PROTECTED] wrote:
  aspasia schrieb:
 
 
  iSCSI initiators and dynamic IP address are two things which don't like
  each other very much.
 
  It will work if you add a dhclient to your initrd, but with any IP
  address change you'll run into problems.
 
  
  that's true ... although, in my pilot I have followed your script and
  statically assigned an IP address ...
  i finally got it to a point where it successfully chroot'ed and
  started the /sbin/init ...
  
  however, at some point it loses its connection ... at some point:

You need to start the iscsi service _after_ you have pivoted in your
bootable system. That means you need to run first 'iscsistart' from
your initrd (which you do I believe), and then when you pivot in-to your
booted environment, run the iscsi service to start up the iSCSI 
daemon. It is imperative to have the iSCSI daemon run as it handles
the management components of the iSCSI connection.

Thought a lot of this (for example the nop-out sending code) has
moved up to the kernel in 2.0-869 release. Are you using this recent release?

--~--~-~--~~~---~--~~
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: IPv4/IPv6 initiator-target--automatic mapping of targets

[Konrad Rzeszutek]

On Sun, May 04, 2008 at 12:56:46AM -0700, Padmanabhan wrote:
 
 Hello All,
 I have a case where both initiator and target are configured with IPv4
 and IPv6 address. The target listens ob both sockets.
 
 When i login to the target without mentioning  the portal , it logins
 and creates two sessions for the same target.
 
 Questions
 1.How to force the initiator to login with a specific IP version ? It
 is configured for automatic login and both systems have to retain dual
 ip address version.

Look in the README file for ' 5.1 How to setup iSCSI interfaces (iface) for 
binding'

 2.The session id  always get incremented after each new login. Can
 this be changed to reset /start from least available after for each
 new session ?

I don't believe it can be without some hacking. The SCSI middle-layer is
the one that gives us the 'host' number which is what we use. Every time
you open/tear down a session, we open/tear down an SCSI Host and the 
SCSI layer gives us a host-number.

 3. How to persistently map iscsi target to fixed sdX id ?

Use multipath or convert the scsi_id to retain a cache so that when it
returns a value the device-mapper can re-create a /dev/mapper/XX to
point to the old block device.

Multipath is probably a better choice - as that is easily installed
on most distros and it automaticly map block devices to uniquely
identified devices that won't change between reboots.


 
 for third Question, I came across couple of threads in forum and IET
 for similar issue. I am trying to configure the ScsiId in the
 ietd.conf and create the udev rule on the initiator. But no success.
 == Ietd.conf==
 Target iqn.2008-03.storageserver:storage.target1
 Lun 1 Path=/dev/VolGroup00/target1,Type=blockio,ScsiId=1234567
 
 Initiator Udev rule and ScsiId
 ===
 [EMAIL PROTECTED] rules.d]$ sudo scsi_id -g -s /block/sdc
 1494554003736353433323100
 
 [EMAIL PROTECTED] rules.d]$ cat 20-names.rules
 KERNEL=sd*, BUS=scsi, PROGRAM=/sbin/scsi_id, RESULT=1234567,
 NAME=sdb%n
 
 [EMAIL PROTECTED] rules.d]$ sudo iscsiadm --version
 iscsiadm version 2.0-865
 ===
 
 Once, I am successful with a single system,it has to be replicated on
 other systems. Is there  feature in consideration on future initiator
 software releases  to extract this info and provide a option to
 automate this event ?
 
 thanks in advance for your time and suggestions
 
 Regards
 Padmanabhan
 

--~--~-~--~~~---~--~~
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: open-iscsi boot with Intel Pro/1000 PT

[Konrad Rzeszutek]

On Mon, May 05, 2008 at 07:03:41AM -0700, Zoney1409 wrote:
 
 Hi all,
 
 Excuse me if this has been asked before but I'm a newbie currently
 being overflowed with info.
 
 I have an Intel Pro/1000 PT setup to boot off iscsi, the target server
 is an open-scsi setup.  The network card picks up the iscsi target
 drive without an issue but doesn't not boot off the drive eventhough
 it should be bootable (it has Ubuntu 8.04 installed on to it).

How did you install Ubuntu on the iSCSI target? 

 
 My question is open-iscsi bootable with this card or am I missing
 something?

It does work with some distros quite well. I don't think Ubuntu is on
the list yet (you are more than welcome along with other people to
get that working).

Here is a PDF of how to get do this setup on a IBM Blade
with RHEL5 as a base-line. The blade uses a specialized firmware to
emulate the iSCSI initiator, similar to what the Intel Pro/1000 PT can
do when you flash it with the iSCSI firmware.

ftp://ftp.software.ibm.com/systems/support/system_x_pdf/iscsi_rhel_bladeboot.pdf

You can also do this with SuSE. You will need to pass in the 'iscsi'
bootup parameter to take advantage of 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: boot error: iscsi: can not broadcast skb

[Konrad Rzeszutek]

On Mon, May 05, 2008 at 10:39:01AM -0700, aspasia wrote:
 
 Hello all,
 
 Process of testing an iscsiRoot ... and in one of my servers, I get
 the following error during the boot process:
 
 iscsi: can not broadcast skb (-3)
 
 And I'm in a hang state;  I think that somehow it lost its network
 connectivity.  Can someone pls shed light as to what the above error

It means that the iSCSI daemon isn't running anymore. It particular it
is the kernel trying to communicate to the iSCSI daemon and failing to do so
via a socket call.


--~--~-~--~~~---~--~~
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: Q: enable iscsi read/write cache

[Konrad Rzeszutek]

On Mon, May 05, 2008 at 12:14:22PM -0700, info-dtnet wrote:
 
 Hi,
 
 while looking around in google, if found a logfile
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467390, where the
 iscsi LUN cache is enabled, read+write:
 Feb 21 22:19:15 localhost kernel: sd 1:0:0:0: [sdc] Write cache:
 enabled, read
 cache: enabled, supports DPO and FUA
 
 My dmsg tells me a not enabled write-cache:
 May  5 20:48:00 xen04 kernel: scsi190 : iSCSI Initiator over TCP/IP
 May  5 20:48:01 xen04 iscsid: connection189:0 is operational now
 May  5 20:48:02 xen04 kernel: scsi 190:0:0:0: Direct-Access
 SUN  SOLARIS  1PQ: 0 ANSI: 5
 May  5 20:48:02 xen04 kernel: sd 190:0:0:0: [sdh] 10485726 512-byte
 hardware sectors (5369 MB)
 May  5 20:48:02 xen04 kernel: sd 190:0:0:0: [sdh] Write Protect is off
 May  5 20:48:02 xen04 kernel: sd 190:0:0:0: [sdh] Write cache:
 disabled, read cache: enabled, doesn't support DPO or FUA
 May  5 20:48:02 xen04 kernel: sd 190:0:0:0: [sdh] 10485726 512-byte
 hardware sectors (5369 MB)
 May  5 20:48:02 xen04 kernel: sd 190:0:0:0: [sdh] Write Protect is off
 May  5 20:48:02 xen04 kernel: sd 190:0:0:0: [sdh] Write cache:
 disabled, read cache: enabled, doesn't support DPO or FUA
 May  5 20:48:02 xen04 kernel:  sdh: sdh1
 May  5 20:48:02 xen04 kernel: sd 190:0:0:0: [sdh] Attached SCSI disk
 May  5 20:48:02 xen04 kernel: sd 190:0:0:0: Attached scsi generic sg11
 type 0
 M
 Question: Who can i enable the cache ? hdparms does not work:

You can't. The disk firmware doesn't support it. Thought I wouldn't worry much 
about it as
the iSCSI target (EqualLogic, NetApp, IBM, etc) will have a write/read cache - 
so
the data is being cached and isn't synchronous I/O (unless you define it as so).


--~--~-~--~~~---~--~~
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: can't start iscsid on 2.6.25.1

[Konrad Rzeszutek]

 shmget(IPC_PRIVATE, 52, IPC_CREAT|IPC_EXCL|0644) = -1 ENOSYS (Function 
 not implemented)

What OS under Xen are you running that doesn't have the shm* commands 
implemented?
That is your problem BTW.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---