allspace | 6 Jun 14:56 2015
Picon

iscsistart and iscsid

Hi,

I run iscsistart in initrd to bring up all iscsi disks (include root disk).
After switch root, do I still need run iscsid service, considering I have no need to run iscsiadm for administration operations.

Mike

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Turbo Fredriksson | 31 May 14:13 2015
Picon

LUN turns r/o after server crash

My server (a Debian GNU/Linux Wheezy running ZFSOnLinux GIT master, sharing ZVOLs to VMs on another host) have two SuperMicro AOC-SAS2LP-MV8 (Marvel 88SE9485) SAS cards with is driven by the "mvsas" driver. That driver is a piece of crap and under heavy load it crashes the machine. The driver isn't really maintained any more either, which complicates things further.


After it (the server) comes up again and shares all the targets, the machine running all the VMs have had it's primary filesystem for VM config files etc remounted read-only. All VMs (Oracle, previously Sun, VirtualBox) have all their storage directly attached to the targets so no virtual disk is on the target fs, only their configs.

Trying to remount the filesystem gives:

     Negotia:~# touch /Machines/Machines/x
     touch: cannot touch `/Machines/Machines/x': Read-only file system
     Negotia:~# umount /Machines/Machines
     umount: /Machines/Machines: device is busy.
             (In some cases useful info about processes that use
              the device is found by lsof(8) or fuser(1))
     Negotia:~# mount -o remount,rw /Machines/Machines
     mount: cannot remount block device /dev/sdc1 read-write, is write-protected
     Negotia:~# ll /dev/disk/by-path/ip-192.168.69.8\:3260-iscsi-iqn.2012-11.com.bayour\:share.virtualmachines.negotia.machines-lun-0-part1
     lrwxrwxrwx 1 root root 10 May 31 13:58 /dev/disk/by-path/ip-192.168.69.8:3260-iscsi-iqn.2012-11.com.bayour:share.virtualmachines.negotia.machines-lun-0-part1 -> ../../sdc1
     Negotia:~# mount | grep sdc1
     /dev/sdc1 on /Machines/Machines type ext4 (ro,relatime,user_xattr,barrier=1,stripe=128,data=ordered,_netdev)

The only to resolve this (that I've been able to find) is to kill all the VMs that "locks" the device, unmount it, fsck it and then mount it again.

This, of course, isn't very nice. It interrupts the running of the VMs (which is Paused by VBox as soon as it sees that it can't write to the config etc). So if there's another way to resolve this, I'd be happy.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Mike Christie | 28 May 22:32 2015
Picon

Re: Restarting iscsid, iscsi socket protocol stability

On 05/28/2015 02:55 PM, Christian Seiler wrote:
> Trying again, since google groups thought my response was spam
> (twice)... (Explicitly putting you on Cc so at least you get my message.)
> 
> On 28.05.2015 20:56, Mike Christie wrote:
>> On 05/26/2015 04:14 PM, Christian Seiler wrote:
>>> Final question regarding that matter:
>>
>> Sorry, I originally read this mail with my phone and missed the
>> questions below.
> 
> No worries.
> 
>>> Is that possible? (I'm basically looking for the equivalent of
>>> udevadm settle for iSCSI sessions.)
>>
>> Currently, you have to script it,
> 
> Yes, I figured. But instead of using iscsiadm, I wrote up the
> following check:
> 
> cat /sys/class/iscsi_session/session*/state 2>/dev/null \
>    | grep -qv LOGGED_IN
> 
> If that succeeds, all sessions (if any) are properly up. Unless you have
> any objections, I'm going to stick to that.
> 

That is fine. The iscsiadm command just reads that sysfs file and prints
it, so same thing.

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Christian Seiler | 28 May 18:33 2015
Picon

[PATCH 0/4] Assorted fixes

Hi,

I've been going through Debian's packaging of open-iscsi and I've
noticed that a couple of fixes that should go upstream (with some
improvements I'll make to Debian's package this will bring the number
of patches in Debian down to zero). I've polished them a bit and am
forwarding them here.

Summary of the patches:

1. make clean is now idempotent (can be called multiple times
   without failing) and also does make distclean in iscsiuio.

2. CFLAGS and LDFLAGS set on the outside are now respected.

3. remove debian/
   This is really outdated (was added 10 years ago and never
   changed since), is better maintained downstream.

4. Some speilling fixes that have been in the Debian package for
   quite a while. This patch is not by me, so I've set the git
   author accordingly.

(I can also create a github pull request if you prefer that.)

Best regards,
Christian

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Christian Seiler | 26 May 20:24 2015
Picon

Restarting iscsid, iscsi socket protocol stability

Hi there,

I want to improve open-iscsi packaging in Debian and I've stumbled upon
the question of what to do on package upgrades. Currently, Debian's
package doesn't do anything on upgrades, i.e. the old iscsid is left
running. (The current documentation in Debian is misleading when it
comes to updates btw.)

I have a couple of questions about that:

1. How stable is the socket protocol between iscsiadm and iscsid? Are
there any guarantuees there? Or could it happen that you upgrade and
then the new iscsiadm can't properly talk to the old iscsid (which is
needed at e.g. shutdown to log out)?

But even if the protocol is guaranteed to be stable: is that a good
idea? In principle, there could be security upgrades in the future,
where you'd want to restart iscsid... which leads to:

2. What I'd rather like to do is just restart iscsid (but keep the
currently active iSCSI sessions). From my short tests it seems to work,
and I observe this:

 - Stopping iscsid seems to be completely harmless, the TCP connections
   of the current session remain open and storage is still acessible.
   Obviously, if you need to react to external events and e.g. change
   portals, that won't happen in this case (without iscsid running),
   but for a short period of time, this should be perfectly fine.

 - Starting iscsid again, it will close the current TCP connections for
   the sessions, reconnect to the portal and then use that. It also
   says 'connection1:0 is operational after recovery (1 attempts)',
   although that typically takes a couple of seconds after it started.

   I didn't notice any trouble with the storage, filesystems reamined
   mounted, no kernel messages (even active I/O would continue,
   blocking only for a very short amount of time).

 - Also, with root on iSCSI, you typically have the configuration:
   initramfs uses iscsistart to log in initially, then when the system
   comes up properly iscsid is started for the first time. So there you
   already have the case that iscsid is regularily started with already
   active iSCSI sessions.

On the other hand, I don't have any weird corner-case configurations
here (my test system is in fact a VM that connects to a software
target), so I can't test any really weird setups.

What I want to know there is:

 - Is it safe to restart iscsid? (As long as it can log in to the
   target again it should be, right?) Are there any side effects?

 - If it generally is: can you think of any idea why it wouldn't be a
   good idea to restart iscsid after upgrading the package?

   Note: package upgrades of open-iscsi should be a rare occurrence:
   during the lifetime of a Debian stable release there should only be
   some if there are really serious bugs (security or otherwise), and
   then every time an upgrade is done to a new Debian version.

Thanks in advance for your responses.

Christian

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

milo wong | 25 May 09:58 2015
Picon

Can anybody tell me how do we force a login redirect in software array TGT?

I have already acknowledged the way to config a login redirect in TGT as below:

tgtadm --op update --mode target --tid 1 --name RedirectAddress --value 10.76.0.30
tgtadm --op update --mode target --tid 1 --name RedirectPort --value 3260
tgtadm --op update --mode target --tid 1 --name RedirectReason --value Temporary
tgtadm --op show --mode target --tid 1
RedirectAddress=10.76.0.30
RedirectPort=3260
RedirectReason=Temporary

But I don't know how to make it do that redirect in my testing, really needs help here.

Thank you in advance!

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
justopeniscsi | 23 May 09:53 2015

ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery

    Hello open-iscsi members,
          now  I meet the question,  this  question  log  is below:
May 23 15:21:24 linuxhost kernel: connection14:0: detected conn error (1021)
May 23 15:21:24 linuxhost kernel: connection14:0: detected conn error (1021)
May 23 15:21:25 linuxhost iscsid: Kernel reported iSCSI connection 14:0 error (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery) state (3)
May 23 15:21:25 linuxhost iscsid: Kernel reported iSCSI connection 14:0 error (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery) state (3)
May 23 15:21:28 linuxhost iscsid: connection14:0 is operational after recovery (1 attempts)May 23 15:21:28 linuxhost iscsid: connection14:0 is operational after recovery (1 attempts)
May 23 15:21:57 linuxhost kernel: connection12:0: detected conn error (1021)  

       my test environment: 
                    target :   system: Red Hat Enterprise Linux Server release 6.4     target driver:  stgt 1.0.55
                    initiator:    system:  Red Hat Enterprise Linux Server release 6.4
       my test tools:
                    fio
       now I have changed below iscsi config
                change  node.session.cmds_max = 128          to      node.session.cmds_max = 32

                   change     node.session.queue_depth = 32        to      node.session.queue_depth = 8

                   change     scsi device timeout,                             echo  300  > /sys/block/sdm/device/timeout

        but  the error still  happen

                  I should how to resolve this question?

       

        Thanks in advance and regards



--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Christian Seiler | 21 May 20:41 2015
Picon

[PATCH] Fix small typo in iscsid.conf

Hi there,

I've recently started co-maintaining the open-iscsi package in Debian
and was going through the list of bugs in Debian's bugtracker.

I'm attaching a patch to fix a small typo in iscsid.conf. The original
bug report can be found under:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627908
(I set the git author of the attached patch to be the reporter of the bug.)

Christian

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Ancoron Luciferis | 7 May 14:06 2015

Reconnects and I/O errors with Synology iSCSI targets

Hi,

I currently have some trouble with LUNs exposed by Synology boxes.

As of Linux kernel 3.19, the max_sectors_kb value always is 32767 for
any LUN, which results into errors on the Synology target side and
reconnects on the Linux initiator side:

On the Synology target:

iSCSI: Unable to allocate memory for iscsi_cmd_t->iov_data.
iSCSI: iSCSI: Close -
I[iqn.1993-08.org.debian:01:99bdf6552818][192.168.xxx.78],
T[iqn.2000-01.com.synology:yyy.mylun.7e92dd8012]
iSCSI: iSCSI: Single CHAP security negotiation completed sucessfully.
iSCSI: iSCSI: Login -
I[iqn.1993-08.org.debian:01:99bdf6552818][192.168.xxx.78],
T[iqn.2000-01.com.synology:yyy.mylun.7e92dd8012][192.168.xxx.91:3260]

On the Linux initiator side:

Kernel reported iSCSI connection 4:0 error (1020 -
ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)
connection4:0: detected conn error (1020)
iscsid: connection4:0 is operational after recovery (1 attempts)

In some cases, e.g. when stacking a LUN with LUKS encryption, I also see
a lot of I/O errors at the client side (in this example, I created an
ext3 file-system on it):

sd 11:0:0:1: [sdj] UNKNOWN(0x2003) Result: hostbyte=0x0e driverbyte=0x00
sd 11:0:0:1: [sdj] CDB: opcode=0x2a 2a 00 00 00 1a 00 00 1e 08 00
blk_update_request: I/O error, dev sdj, sector 6656
Buffer I/O error on dev dm-0, logical block 64, lost async page write
Buffer I/O error on dev dm-0, logical block 65, lost async page write
Buffer I/O error on dev dm-0, logical block 66, lost async page write
Buffer I/O error on dev dm-0, logical block 67, lost async page write
Buffer I/O error on dev dm-0, logical block 68, lost async page write
Buffer I/O error on dev dm-0, logical block 69, lost async page write
Buffer I/O error on dev dm-0, logical block 70, lost async page write
Buffer I/O error on dev dm-0, logical block 71, lost async page write
Buffer I/O error on dev dm-0, logical block 72, lost async page write
Buffer I/O error on dev dm-0, logical block 73, lost async page write
sd 11:0:0:1: [sdj] UNKNOWN(0x2003) Result: hostbyte=0x0e driverbyte=0x00
sd 11:0:0:1: [sdj] CDB: opcode=0x2a 2a 00 3e 78 c5 50 00 40 00 00
blk_update_request: I/O error, dev sdj, sector 1048102224
...
buffer_io_error: 6835 callbacks suppressed

I suspect this is due to the fact that the Synology target does not
present any meaningful block limits, e.g.:

# sg_vpd -p bl /dev/sdj
Block limits VPD page (SBC):
  Write same no zero (WSNZ): 0
  Maximum compare and write length: 0 blocks
  Optimal transfer length granularity: 0 blocks
  Maximum transfer length: 0 blocks
  Optimal transfer length: 0 blocks
  Maximum prefetch length: 0 blocks
  Maximum unmap LBA count: 0
  Maximum unmap block descriptor count: 0
  Optimal unmap granularity: 0
  Unmap granularity alignment valid: 0
  Unmap granularity alignment: 0
  Maximum write same length: 0x0 blocks

What bothers me most is that "Maximum transfer length" is set to zero,
which from my understanding of the spec means that no limits apply,
hence the Linux initiator is correctly not applying any limit here.

However, at the target side, I can see the following limits:

For block-level LUNs:
# cat /sys/kernel/config/target/core/.../attrib/hw_max_sectors
128
# cat /sys/kernel/config/target/core/.../attrib/max_sectors
128

...and for file-level LUNs:
# cat /sys/kernel/config/target/core/.../attrib/hw_max_sectors
1024
# cat /sys/kernel/config/target/core/.../attrib/max_sectors
1024

According to a sector size of 512 bytes, I should be safe with 64
respectively 512 for the value of max_sectors_kb. I have tested
extensively with heavy load and different scenarios (e.g. formatting,
iozone single and multi-threaded tests) that after lowering that value
on the initiator side seems to resolve the problem.

However, while testing I also came up with the following limits for
max_sectors_kb:

fileio: 4096
iblock: 512

...which to me does not make much sense, except if the sector size would
be 4096, which it isn't (at least not reported):
$ cat /sys/block/sdj/queue/hw_sector_size
512

So, I am puzzled. Can someone help me making sense out of this?

Btw., the DI VPD of the LUNs are:

# sg_vpd -p di_lu /dev/sdj
Device Identification VPD page:
  Addressed logical unit:
    designator type: NAA,  code set: Binary
      0x600140520cc460dd155ed32b5db631d3
    designator type: T10 vendor identification,  code set: ASCII
      vendor id: SYNOLOGY
      vendor specific: iSCSI Storage:20cc460d-155e-32b5-b631-3e5d006efbd2
    designator type: Logical unit group,  code set: Binary
      Logical unit group: 0x0

Is there a way to _configure_ attributes for specific SCSI devices?

Thanx for any help! :)

Regards,

	Ancoron

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Johannes Thumshirn | 11 May 13:38 2015
Picon

[PATCH] iscsiuio: Fix lookup of IPv6 router address

When iscsiuio performs a lookup in it's routing table
for the default router, nothing is returned as ndpc_request()
didn't understand the 'GET_DEFAULT_ROUTER_ADDR' request.
The solution is to add the request and return the default router
address.

Signed-off-by: Johannes Thumshirn <jthumshirn@...>
---
 iscsiuio/src/uip/ipv6_ndpc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/iscsiuio/src/uip/ipv6_ndpc.c b/iscsiuio/src/uip/ipv6_ndpc.c
index 62d1c21..8422d7e 100644
--- a/iscsiuio/src/uip/ipv6_ndpc.c
+++ b/iscsiuio/src/uip/ipv6_ndpc.c
 <at>  <at>  -413,6 +413,9  <at>  <at>  int ndpc_request(struct uip_stack *ustack, void *in, void *out, int request)
 			(struct ipv6_addr *)((struct ndpc_reqptr *)in)->ipv6,
 			(struct mac_address *)((struct ndpc_reqptr *)in)->eth);
 		break;
+	case GET_DEFAULT_ROUTER_ADDR:
+		ipv6_get_default_router_ip_addrs(ipv6c, *(struct ipv6_addr **)out);
+		break;
 	case GET_HOST_ADDR:
 		*(struct ipv6_addr **)out = ipv6_find_longest_match(ipv6c,
 							(struct ipv6_addr *)in);
-- 
2.3.7

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Chris Leech | 14 May 00:12 2015
Picon

[RFC PATCH 0/4] Make iSCSI network namespace aware

I've had a few reports of people trying to run iscsid in a container, which
doesn't work at all when using network namespaces.  This is the start of me
looking at what it would take to make that work, and if it makes sense at all.

The first issue is that the kernel side of the iSCSI netlink control protocol
only operates in the initial network namespace.  But beyond that, if we allow
iSCSI to be managed within a namespace we need to decide what that means.  I
think it makes the most sense to isolate the iSCSI host, along with it's
associated endpoints, connections, and sessions, to a network namespace and
allow multiple instances of the userspace tools to exist in separate namespaces
managing separate hosts.

It works well for iscsi_tcp, which creates a host per session.  There's no
attempt to manage sessions on offloading hosts independently, although future
work could include the ability to move an entire host to a new namespace like
is supported for network devices.

This is only about the structures and functionality involved in maintaining the
iSCSI session, the SCSI host along with it's discovered targets and devices has
no association with network namespaces.

These patches are functional, but not complete.  There's no isolation enforced
in the kernel just yet, so it relies on well behaved userspace.  I plan on
fixing that, but wanted some feedback on the idea and approach so far.

Thanks,
	Chris

Chris Leech (4):
  iscsi: create per-net iscsi nl kernel sockets
  iscsi: sysfs filtering by network namespace
  iscsi: make all netlink multicast namespace aware
  iscsi: set netns for iscsi_tcp hosts

 drivers/scsi/iscsi_tcp.c            |   7 +
 drivers/scsi/scsi_transport_iscsi.c | 264 +++++++++++++++++++++++++++++-------
 include/scsi/scsi_transport_iscsi.h |   2 +
 3 files changed, 222 insertions(+), 51 deletions(-)

-- 
2.1.0

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.


Gmane