Re: Using failover with differing EUI / IQN values
Possibly not. I've seen the same disk receive different SCSI Ids when exported using stgt (linux userspace iSCSI target) and iscsitarget (linux kernel iSCSI target). You need to try it out. If /sbin/scsi_id outputs the same value at the initiator for both LUNs then multipathd will consider them to be paths to the same device and add them to the same map. (See /etc/multipath.conf for the exact /sbin/scsi_id usage.) Regards, Alex Claude Bing wrote: Does this still apply if I'm using two separate iSCSI target devices sharing the same data source (RAID)? On Mar 19, 2010 1:24 PM, Alex Zeffertt alex.zeffe...@eu.citrix.com mailto:alex.zeffe...@eu.citrix.com wrote: Yes, I've done it! multipathd uses /sbin/scsi_id to determine which block devices are really the same as eachother. (Actually, the callout is configured in /etc/multipath.conf, but its usually /sbin/scsi_id). If /sbin/scsi_id returns the same ID for two block devices then you should be able to failover between them. The path failovers are handled by the kernel part of the device-mapper-multipath package, and path recovery is handled by multipathd. Regards, Alex Claude Bing wrote: Hello, I am wondering if it is possible to failover an iSCSI path from one EUI / IQN to one ... -- 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 mailto:open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com mailto:open-iscsi%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- 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 mailto:open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com mailto:open-iscsi%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- 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. -- 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: Using failover with differing EUI / IQN values
Thanks, I will! On Mar 22, 2010 5:52 AM, Alex Zeffertt alex.zeffe...@eu.citrix.com wrote: Possibly not. I've seen the same disk receive different SCSI Ids when exported using stgt (linux userspace iSCSI target) and iscsitarget (linux kernel iSCSI target). You need to try it out. If /sbin/scsi_id outputs the same value at the initiator for both LUNs then multipathd will consider them to be paths to the same device and add them to the same map. (See /etc/multipath.conf for the exact /sbin/scsi_id usage.) Regards, Alex Claude Bing wrote: Does this still apply if I'm using two separate iSCSI target devices sharing the same data sourc... On Mar 19, 2010 1:24 PM, Alex Zeffertt alex.zeffe...@eu.citrix.commailto: alex.zeffe...@eu.ci... mailto:open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.comopen-iscsi%2bunsubscr...@googlegroups.com mailto:open-iscsi%2bunsubscr...@googlegroups.comopen-iscsi%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. ... To post to this group, send email to open-iscsi@googlegroups.com mailto: open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.comopen-iscsi%2bunsubscr...@googlegroups.commailto: open-iscsi%2bunsubscr...@googlegroups.comopen-iscsi%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group... -- You received this message because you are subscribed to the Google Groups open-iscsi group. ... -- 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: The be2iscsi driver support for bsg
FUJITA Tomonori wrote: If vendors use the common data structures via bsg, it's totally fine by me. I see why bsg is preferable. The only thing that I care about is managing any iSCSI HBA with iscsiadm instead of various vendor specific utilities. agreed About the implementation, I think that it's better to have the common library code rather than just copying the fs bsg code into iscsi. Note: I tried to library-ize the transport implementation on the first pass of the RFC. But it was making things more complex. I tried to explain this, perhaps not very well (http://marc.info/?l=linux-scsim=125725904205688w=2). -- james s -- 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: The be2iscsi driver support for bsg
On Fri, 19 Mar 2010 08:56:30 -0400 James Smart james.sm...@emulex.com wrote: I still want to know why vendors can't do this via the existing netlink interface. open-iscsi uses the netlink interface for some pdu so I guess that having a different channel for management might be a good idea. Separate this request into two needs: The first need is for the iscsi driver to have some kind of entry point to kick off a vendor specific thing - primarily diagnostics and internal f/w and flash mgmt items. Here, using the same mechanism that we had on the FC side, which also supports dma payloads, made a lot of sense. I like and prefer the symmetry. The second need is for common iscsi link/stack mgmt. All vendors would be expected to implement the same items the same way - thus the formalization of the api in the transport. It also makes sense that all use of these common interfaces comes via the open-iscsi mgmt utilities. Given the data set, it could be done by netlink or bsg. I gave some pros/cons on the interfaces in (http://marc.info/?l=linux-scsim=124811693510903w=2). In my mind, the main reason these settings ended up in bsg vs netlink is - the functionality is typically migrating from a vendor-specific ioctl set, which maps rather easily to the bsg model. Not that netlink is that more difficult (although to NLA_ or not may confuse some of the contributors). And, if you already had the bsg infrastructure for the first need, you had to add very little to support it. Thus, the main reason they are together is one of expediency. The first had to be done, so it was very easy to use the same methodology for the second. If vendors use the common data structures via bsg, it's totally fine by me. I see why bsg is preferable. The only thing that I care about is managing any iSCSI HBA with iscsiadm instead of various vendor specific utilities. About the implementation, I think that it's better to have the common library code rather than just copying the fs bsg code into 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-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: open-iscsi against sun storage tek 2500 fails: 1011 error.
Mike, we are happy: no more packets lost. Now the dmesg shows: scsi2 : iSCSI Initiator over TCP/IP scsi 2:0:0:0: Direct-Access SUN LCSM100_I 0735 PQ: 0 ANSI: 5 sd 2:0:0:0: Attached scsi generic sg1 type 0 sd 2:0:0:0: [sdb] 2147483648 512-byte logical blocks: (1.09 TB/1.00 TiB) scsi 2:0:0:31: Direct-Access SUN Universal Xport 0735 PQ: 0 ANSI: 5 scsi 2:0:0:31: Attached scsi generic sg2 type 0 sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 77 00 10 08 sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA sdb: unknown partition table sd 2:0:0:0: [sdb] Attached SCSI disk GFS2: gfs2 mount does not exist So, we are going to install the package: sys-cluster/gfs-kernel, but an error appears: see http://bugs.gentoo.org/show_bug.cgi?id=310689 Oriol -- 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. attachment: oriol_morell.vcf
Debian Lenny and md3000i with modified RDAC
Hi list, Hope this is the place to ask. I've been using http://www.performancemagic.com/Dell1950_MD3000i_Xen_Debian_iSCSI_RDAC/Multipathing.html to setup serveral systems in the past. Under load, I'm seeing occasional controller resets, and then some i/o timeouts on disks owned by the controller being reset. Now I'm told by Dell support that the rdac module on their support cd is modified specifically for the md3000i, which is why I'm experiencing these problems. My question is if anybody experienced this before, or if anybody is actually using a ported version of the mpp/rdac module from the md3000i support cd on Debian. Thanks! :-) Regards Kristoffer -- 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.
Reboot hangs on failing multipath devices
Every time I reboot my server it hangs on the multipath devices. The server is Debian based. I've had this problem with all kernels I've tried (2.6.18, 2.6.24, 2.6.32). In /etc/multipath.conf, no_path_retry is set to queue Here are snippets from the reboot log: snip Stopping multipath daemon: multipathd. ... Saving the system clock. Unmounting iscsi-backed filesystems: /umount: /? device is busy umount: /: device is busy ... Disconnecting iSCSI targets:Logging out of session [sid: 1, Logging out of session [sid: 2, Logging out of session [sid: 3, sd 8:0:0:0: [sde] Synchronizing SCSI cache sd 9:0:0:0: [sdd] Synchronizing SCSI cache sd 10:0:0:0: [sdf] Synchronizing SCSI cache connection2:0: detected conn error (1020) connection1:0: detected conn error (1020) connection3:0: detected conn error (1020) Logout of [sid: 1...successful Logout of [sid: 2...successful Stopping iSCSI initiator server:. Cleaning up ifupdown Deactivating swap...done. Shutting down LVM Volume Groupsdevice-mapper: multipath: Failing path 8:64. device-mapper: uevent: dm_send_uevents: kobject_uevent_env failed device-mapper: multipath: Failing path 8:48. device-mapper: uevent: dm_send_uevents: kobject_uevent_env failed device-mapper: multipath: Failing path 8:80. device-mapper: uevent: dm_send_uevents: kobject_uevent_env failed /snip The server is then stuck there indefinitely. What can I do to avoid this problem when rebooting? Thanks. -- James -- 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: Reboot hangs on failing multipath devices
James Hammer wrote: Every time I reboot my server it hangs on the multipath devices. The server is Debian based. I've had this problem with all kernels I've tried (2.6.18, 2.6.24, 2.6.32). In /etc/multipath.conf, no_path_retry is set to queue I found that if I set no_path_retry to its default value of 0, then the server reboots immediately. Is it possible to get this working with no_path_retry set to queue? -- James -- 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: FW: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
On 03/19/2010 05:48 PM, Ravi Anand wrote:
On Thu, 18 Mar 2010 16:02:52 -0500
Mike Christiemicha...@cs.wisc.edu wrote:
On 03/18/2010 08:58 AM, FUJITA Tomonori wrote:
- You invent your hardware specific data structure for the simplest
operation such as setting IP address.
I think this is what Jay is not trying to do. I think the patch has some
extra code like the ISCSI_BSG_HST_VENDOR parts that makes it confusing -
it got me too. The ISCSI_BSG_HST_VENDOR code in be2iscsi looks like it
is basically disabled (should remove for a formal patch when he sends
for merging).
It looks like there is a common struct iscsi_bsg_common_format that is
getting passed around, and then in be2iscsi the driver is using that
info to make a be2iscsi specific command. So scsi_transport_iscsi /
ISCSI_SET_IP_ADDR / iscsi_bsg_common_format gets translated by b2iscsi
to b2iscsi / OPCODE_COMMON_ISCSI_NTWK_MODIFY_IP_ADDR / be_modify_ip_addr.
Yeah, seems you are right. But looks like this patchset also adds the
vendor specific message support (ISCSI_BSG_HST_VENDOR)?
...
Here's an early snapshot of the patch which we are working on to add
the support using bsg vendor specific part - btw this is based on the previous
iscsi bsg patch and need to be synced up with what was posted recently.
Just to make sure we are all on the same page. Tomo's comments above
means that for your comment about updating to the new code does not mean
that you should just use the new HST_VENDOR cmd, and it does not mean
that we only should use a common struct/cmd for net operations that Jay
handled.
For other common operations we should do like Tomo suggested, and Jay
started with the network stuff, and make common operations. You guys
should also not feel like you have to use the format Jay posted with. We
can modify it so it make sense for everyone.
+ switch (msgcode) {
+ case ISCSI_BSG_HST_VENDOR:
+ rval = qla4xxx_process_vendor_specific(job);
+ break;
+ case ISCSI_BSG_HST_PING:
+ rval = qla4xxx_ping(job);
+ break;
+ default:
+ break;
+ }
+
--
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: Reboot hangs on failing multipath devices
On 03/22/2010 03:38 PM, James Hammer wrote: Every time I reboot my server it hangs on the multipath devices. The server is Debian based. I've had this problem with all kernels I've tried (2.6.18, 2.6.24, 2.6.32). In /etc/multipath.conf, no_path_retry is set to queue Here are snippets from the reboot log: snip Stopping multipath daemon: multipathd. ... Saving the system clock. Unmounting iscsi-backed filesystems: /umount: /? device is busy umount: /: device is busy ... Disconnecting iSCSI targets:Logging out of session [sid: 1, Logging out of session [sid: 2, Logging out of session [sid: 3, sd 8:0:0:0: [sde] Synchronizing SCSI cache sd 9:0:0:0: [sdd] Synchronizing SCSI cache sd 10:0:0:0: [sdf] Synchronizing SCSI cache connection2:0: detected conn error (1020) connection1:0: detected conn error (1020) connection3:0: detected conn error (1020) Logout of [sid: 1...successful Logout of [sid: 2...successful Stopping iSCSI initiator server:. Cleaning up ifupdown Deactivating swap...done. Shutting down LVM Volume Groupsdevice-mapper: multipath: Failing path 8:64. device-mapper: uevent: dm_send_uevents: kobject_uevent_env failed device-mapper: multipath: Failing path 8:48. device-mapper: uevent: dm_send_uevents: kobject_uevent_env failed device-mapper: multipath: Failing path 8:80. device-mapper: uevent: dm_send_uevents: kobject_uevent_env failed /snip Are there file systems mounted on the multipath device? -- 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.
