From: Wim B. <su...@sy...> - 2010-08-11 14:36:54
|
LS I have a machine running iet iscsid , one lun , Lun 0, is exported which is a lvm partition : Lun 0 Path=/dev/vg_rhel6/iscsi1,Type=blockio,ScsiId=0,ScsiSN=0 no authentication is configured . iscsi-target starts with one error : Starting iSCSI Target: FATAL: Error inserting crc32c_intel (/lib/modules/2.6.32-44.2.el6.i686/kernel/arch/x86/crypto/crc32c-intel.ko): No such device apparently support for a proper crc32c kernel module has been dropped by redhat in favor of a crc32c-intel module that only loads on very esoteric and expensive hardware, never spotted in the wild as far as I know, but ietd seems to run properly despite this error. On the client (centos 5.5) side iscsid has been configured and running and after discovery with iscsiadm , iscsi is started and it appears to have connected : ------------------ Loading iSCSI transport class v2.0-724. iscsi: registered transport (tcp) iscsi: registered transport (iser) scsi4 : iSCSI Initiator over TCP/IP Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdb: 83886080 512-byte hdwr sectors (42950 MB) sdb: Write Protect is off sdb: Mode Sense: 77 00 00 08 SCSI device sdb: drive cache: none SCSI device sdb: 83886080 512-byte hdwr sectors (42950 MB) sdb: Write Protect is off sdb: Mode Sense: 77 00 00 08 SCSI device sdb: drive cache: none sdb: unknown partition table sd 4:0:0:0: Attached scsi disk sdb sd 4:0:0:0: Attached scsi generic sg4 type 0 ------------------- but there is no /dev/sdb device node made and of course fdisk consequently fails : ------------ [root@tk63 ~]# fdisk /dev/sdb Unable to read /dev/sdb ---------- What is going wrong here ? Is the fatal error on iscsi-target the cause ? But then how can the lun be discovered by the client? Thanks Wim Bakker -- ________________________________________________ Systux Linux Systeemdiensten Wim Bakker Adres : Krom Boomssloot 49-2 1011GS , Amsterdam Telefoon : 020-4702501 Mobiel : 06-13561637 E-mail : KvK Nr. : 34286248 URL : www.systux.nl |
From: Arne R. <arn...@go...> - 2010-08-11 15:00:52
|
2010/8/11 Wim Bakker <su...@sy...>: > > LS > > I have a machine running iet iscsid , one lun , Lun 0, is exported > which is a lvm partition : > Lun 0 Path=/dev/vg_rhel6/iscsi1,Type=blockio,ScsiId=0,ScsiSN=0 > > no authentication is configured . > iscsi-target starts with one error : > Starting iSCSI Target: FATAL: Error inserting crc32c_intel > (/lib/modules/2.6.32-44.2.el6.i686/kernel/arch/x86/crypto/crc32c-intel.ko): > No such device > apparently support for a proper crc32c kernel module has been dropped by > redhat in favor of a crc32c-intel module that only loads on very esoteric > and expensive hardware, never spotted in the wild > as far as I know, but ietd seems to run properly despite this error. > > On the client (centos 5.5) side iscsid has been configured and running and > after discovery > with iscsiadm , iscsi is started and it appears to have connected : > ------------------ > Loading iSCSI transport class v2.0-724. > iscsi: registered transport (tcp) > iscsi: registered transport (iser) > scsi4 : iSCSI Initiator over TCP/IP > Vendor: IET Model: VIRTUAL-DISK Rev: 0 > Type: Direct-Access ANSI SCSI revision: 04 > SCSI device sdb: 83886080 512-byte hdwr sectors (42950 MB) > sdb: Write Protect is off > sdb: Mode Sense: 77 00 00 08 > SCSI device sdb: drive cache: none > SCSI device sdb: 83886080 512-byte hdwr sectors (42950 MB) > sdb: Write Protect is off > sdb: Mode Sense: 77 00 00 08 > SCSI device sdb: drive cache: none > sdb: unknown partition table > sd 4:0:0:0: Attached scsi disk sdb > sd 4:0:0:0: Attached scsi generic sg4 type 0 > ------------------- > but there is no /dev/sdb device node made and of course > fdisk consequently fails : > ------------ > [root@tk63 ~]# fdisk /dev/sdb > > Unable to read /dev/sdb > ---------- > What is going wrong here ? Is the fatal error on iscsi-target the cause ? Wim, since the LU is visible on the initiator side, it looks like a problem with creating the device node on the initiator and not like a target problem. You can use the sg utils to check if the iscsi conn is working as expected, e.g. sg_inc /dev/sg4. Or you can find out the major / minor of the device in sysfs and create the device node manually with mknod Are there any udev related errors in the logs on the initiator machine? HTH, Arne |
From: Ross S. W. W. <RW...@me...> - 2010-08-11 15:15:35
|
Wim Bakker [mailto:su...@sy...] wrote: > > LS > > I have a machine running iet iscsid , one lun , Lun 0, is exported > which is a lvm partition : > Lun 0 Path=/dev/vg_rhel6/iscsi1,Type=blockio,ScsiId=0,ScsiSN=0 > > no authentication is configured . > iscsi-target starts with one error : > Starting iSCSI Target: FATAL: Error inserting crc32c_intel > (/lib/modules/2.6.32-44.2.el6.i686/kernel/arch/x86/crypto/crc3 > 2c-intel.ko): > No such device > apparently support for a proper crc32c kernel module has been > dropped by > redhat in favor of a crc32c-intel module that only loads on > very esoteric > and expensive hardware, never spotted in the wild > as far as I know, but ietd seems to run properly despite this error. It appears to run properly, but doesn't because the checksum code doesn't have a failure path if there is no CRC32 hash available. Looks like we need to either, a) disable checksums if CRC32 isn't available, b) implement our own CRC32 hash code which is used if the system doesn't supply one. Either, or, prefferably both, needs to be implemented. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. |
From: Arne R. <arn...@go...> - 2010-08-11 15:36:25
|
2010/8/11 Ross S. W. Walker <RW...@me...>: > Wim Bakker [mailto:su...@sy...] wrote: >> >> LS >> >> I have a machine running iet iscsid , one lun , Lun 0, is exported >> which is a lvm partition : >> Lun 0 Path=/dev/vg_rhel6/iscsi1,Type=blockio,ScsiId=0,ScsiSN=0 >> >> no authentication is configured . >> iscsi-target starts with one error : >> Starting iSCSI Target: FATAL: Error inserting crc32c_intel >> (/lib/modules/2.6.32-44.2.el6.i686/kernel/arch/x86/crypto/crc3 >> 2c-intel.ko): >> No such device >> apparently support for a proper crc32c kernel module has been >> dropped by >> redhat in favor of a crc32c-intel module that only loads on >> very esoteric >> and expensive hardware, never spotted in the wild >> as far as I know, but ietd seems to run properly despite this error. > > It appears to run properly, but doesn't because the checksum > code doesn't have a failure path if there is no CRC32 hash > available. > > Looks like we need to either, a) disable checksums if CRC32 > isn't available, b) implement our own CRC32 hash code which > is used if the system doesn't supply one. Either, or, > prefferably both, needs to be implemented. You wouldn't see the LU on the initiator if that was an issue, no? Arne |
From: Ross S. W. W. <RW...@me...> - 2010-08-11 15:54:06
|
Arne Redlich [mailto:arn...@go...] wrote: > 2010/8/11 Ross S. W. Walker <RW...@me...>: > > Wim Bakker [mailto:su...@sy...] wrote: > >> > >> LS > >> > >> I have a machine running iet iscsid , one lun , Lun 0, is exported > >> which is a lvm partition : > >> Lun 0 Path=/dev/vg_rhel6/iscsi1,Type=blockio,ScsiId=0,ScsiSN=0 > >> > >> no authentication is configured . > >> iscsi-target starts with one error : > >> Starting iSCSI Target: FATAL: Error inserting crc32c_intel > >> (/lib/modules/2.6.32-44.2.el6.i686/kernel/arch/x86/crypto/crc3 > >> 2c-intel.ko): > >> No such device > >> apparently support for a proper crc32c kernel module has been > >> dropped by > >> redhat in favor of a crc32c-intel module that only loads on > >> very esoteric > >> and expensive hardware, never spotted in the wild > >> as far as I know, but ietd seems to run properly despite > this error. > > > > It appears to run properly, but doesn't because the checksum > > code doesn't have a failure path if there is no CRC32 hash > > available. > > > > Looks like we need to either, a) disable checksums if CRC32 > > isn't available, b) implement our own CRC32 hash code which > > is used if the system doesn't supply one. Either, or, > > prefferably both, needs to be implemented. > > You wouldn't see the LU on the initiator if that was an issue, no? I believe it gets through the login process OK, hands off to the kernel module where it hangs shortly after lu detection. I know the crypto stuff I did for ScsiId/SN generation checks to see if the crypto is available and falls back to a simple hash if it isn't, but I don't think the checksum code does that and it's probably hanging up there somewhere. This is all guess work right now because I don't have access to the code at the moment, but if I were to look somewhere that is where I'd look first. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. |
From: Arne R. <arn...@go...> - 2010-08-11 17:03:08
|
No Am 11.08.2010 17:53 schrieb "Ross S. W. Walker" <RW...@me...>: Arne Redlich [mailto:arn...@go...] wrote: > 2010/8/11 Ross S. W. Walker <RWalker@meda... I believe it gets through the login process OK, hands off to the kernel module where it hangs shortly after lu detection. I know the crypto stuff I did for ScsiId/SN generation checks to see if the crypto is available and falls back to a simple hash if it isn't, but I don't think the checksum code does that and it's probably hanging up there somewhere. This is all guess work right now because I don't have access to the code at the moment, but if I were to look somewhere that is where I'd look first. -Ross ______________________________________________________________________ This e-mail, and any ... |
From: Arne R. <arn...@go...> - 2010-08-11 17:32:44
|
[Sorry, premature send.] 2010/8/11 Arne Redlich <arn...@go...>: > No > > Am 11.08.2010 17:53 schrieb "Ross S. W. Walker" <RW...@me...>: > > Arne Redlich [mailto:arn...@go...] wrote: >> 2010/8/11 Ross S. W. Walker <RWalker@meda... > > I believe it gets through the login process OK, hands off to the > kernel module where it hangs shortly after lu detection. > > I know the crypto stuff I did for ScsiId/SN generation checks > to see if the crypto is available and falls back to a simple > hash if it isn't, but I don't think the checksum code does > that and it's probably hanging up there somewhere. No, in that case we would not see any LU on the initiator, since the REPORT LUNs and the INQUIRY reqs/rsps also need to be sent with CRCs. Arne > This is all guess work right now because I don't have access > to the code at the moment, but if I were to look somewhere > that is where I'd look first. > > -Ross > > ______________________________________________________________________ > This e-mail, and any ... |
From: Wim B. <su...@sy...> - 2010-08-11 18:10:48
|
Op woensdag 11 augustus 2010 19:32:36 schreef Arne Redlich: > [Sorry, premature send.] > > 2010/8/11 Arne Redlich <arn...@go...>: > > No > > > > Am 11.08.2010 17:53 schrieb "Ross S. W. Walker" <RW...@me...>: > > > > Arne Redlich [mailto:arn...@go...] wrote: > >> 2010/8/11 Ross S. W. Walker <RWalker@meda... > > > > I believe it gets through the login process OK, hands off to the > > kernel module where it hangs shortly after lu detection. > > > > I know the crypto stuff I did for ScsiId/SN generation checks > > to see if the crypto is available and falls back to a simple > > hash if it isn't, but I don't think the checksum code does > > that and it's probably hanging up there somewhere. > > No, in that case we would not see any LU on the initiator, since the > REPORT LUNs and the INQUIRY reqs/rsps also need to be sent with CRCs. > > Arne > > > This is all guess work right now because I don't have access > > to the code at the moment, but if I were to look somewhere > > that is where I'd look first. I installed ietd on another server , running archlinux instead of RHEL6-beta2 and there I have a kernel module crc32c , the daemon ietd starts without errors , and on the client (centos 5.5 again) , the discovery is smooth with creation of the device node and I have an accessable /dev/sdb now. Still the crc32c-intel module that spoils it? On arch-linux I have the following modules : Module Size Used by iscsi_trgt 89424 4 crc32c 3352 0 but crc32c does not seem to be used but the machine works as a target. Wim bakker -- ________________________________________________ Systux Linux Systeemdiensten Wim Bakker Adres : Krom Boomssloot 49-2 1011GS , Amsterdam Telefoon : 020-8458490 Mobiel : 06-13561637 E-mail : su...@sy... KvK Nr. : 34286248 URL : www.systux.nl |
From: Arne R. <arn...@go...> - 2010-08-11 18:19:05
|
2010/8/11 Wim Bakker <su...@sy...>: > Op woensdag 11 augustus 2010 19:32:36 schreef Arne Redlich: >> [Sorry, premature send.] >> >> 2010/8/11 Arne Redlich <arn...@go...>: >> > No >> > >> > Am 11.08.2010 17:53 schrieb "Ross S. W. Walker" <RW...@me...>: >> > >> > Arne Redlich [mailto:arn...@go...] wrote: >> >> 2010/8/11 Ross S. W. Walker <RWalker@meda... >> > >> > I believe it gets through the login process OK, hands off to the >> > kernel module where it hangs shortly after lu detection. >> > >> > I know the crypto stuff I did for ScsiId/SN generation checks >> > to see if the crypto is available and falls back to a simple >> > hash if it isn't, but I don't think the checksum code does >> > that and it's probably hanging up there somewhere. >> >> No, in that case we would not see any LU on the initiator, since the >> REPORT LUNs and the INQUIRY reqs/rsps also need to be sent with CRCs. >> >> Arne >> >> > This is all guess work right now because I don't have access >> > to the code at the moment, but if I were to look somewhere >> > that is where I'd look first. > > I installed ietd on another server , running archlinux instead of RHEL6-beta2 > and there I have a kernel module crc32c , the daemon ietd starts without > errors , and on the client (centos 5.5 again) , the discovery is smooth with > creation of the device node and I have an accessable /dev/sdb now. > Still the crc32c-intel module that spoils it? On arch-linux I have the > following modules : > Module Size Used by > iscsi_trgt 89424 4 > crc32c 3352 0 > > but crc32c does not seem to be used but the machine works as a target. Can you post ietd.conf kernel logs for the failing target system? Also, a wireshark capture of the traffic for that one will be helpful. A. > > Wim bakker > > -- > ________________________________________________ > Systux Linux Systeemdiensten > Wim Bakker > Adres : Krom Boomssloot 49-2 > 1011GS , Amsterdam > Telefoon : 020-8458490 > Mobiel : 06-13561637 > E-mail : su...@sy... > KvK Nr. : 34286248 > URL : www.systux.nl > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Iscsitarget-devel mailing list > Isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > |
From: James L. <ja...@su...> - 2010-08-25 01:50:30
|
I searched the mail archives, but couldn't find the answer. I tried to use IETD disk for a Server 2008 cluster but it's unable to come online. I've read some various posts stating IETD doesn't support SCSI3 reservations thus does not support Server 2008 Clustering. So I'm at a dilemma. I now need to support both a VMware cluster and a Hyper-V cluster with my storage solution. Assuming what I read is correct about the SCSI3 reservation, is Windows Server 2008 clustering on the IETD roadmap? Any possible solutions to this? Thanks, James LeRoy |
From: Ross S. W. W. <RW...@me...> - 2010-08-25 03:01:02
|
James LeRoy [mailto:ja...@su...] wrote: > > I searched the mail archives, but couldn't find the answer. > > I tried to use IETD disk for a Server 2008 cluster but it's > unable to come online. > > I've read some various posts stating IETD doesn't support > SCSI3 reservations thus does not support Server 2008 Clustering. > > So I'm at a dilemma. I now need to support both a VMware > cluster and a Hyper-V cluster with my storage solution. > Assuming what I read is correct about the SCSI3 reservation, > is Windows Server 2008 clustering on the IETD roadmap? > > Any possible solutions to this? Well we hope to put SCSI3 into play, but probably not by the time you need it. If you really plan on Hyper-V clustering then you could give LIO a try it supposedly supports SCSI3 right now. There is also CIFS and/or NFS for datastores, then pump iSCSI into the VMs. You can look at Nexenta as an option, iSCSI, FCoE, NFS and CIFS in one box. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. |
From: James L. <ja...@su...> - 2010-08-25 15:31:22
|
I found LIO, but I'm really hesitant just by looking at their website. I can't find anything, not even the download for it. It has a crazy link that says 'random page' that I had to just keep clicking to read more about it because there weren't actual links to all the pages in the site. I've previously looked into Nexenta because of interest in the dedup, but I discovered their free iSCSI was too limiting. Every client gets to see every target. If it was all VMware no big deal, but I don't want Hyper-V and VMware seeing each other's LUNs. SCST and STGT look like possible options, but STGT doesn't support a config file natively only a hacked one. Unfortunately I just completed my lease replacement of my old IET server to latest and greatest IET and I can't switch to another solution without doing some proper testing. That testing will take me some time and hopefully, I'll keep my fingers crossed, IET will add SCSI3 reservation before I'm ready to switch. If anything I will probably just have a small solution in parallel to IET to bide me some time until IET is ready. Ross, if I were a C programmer I'd help you all I can. You've been impressively dedicated to this project for a long time. All too often open source developers abandon their projects. You do a great job and you're greatly appreciated. -----Original Message----- From: Ross S. W. Walker [mailto:RW...@me...] Sent: Tuesday, August 24, 2010 10:01 PM To: James LeRoy; Isc...@li... Subject: RE: [Iscsitarget-devel] Windows Server 2008 Clustering Well we hope to put SCSI3 into play, but probably not by the time you need it. If you really plan on Hyper-V clustering then you could give LIO a try it supposedly supports SCSI3 right now. There is also CIFS and/or NFS for datastores, then pump iSCSI into the VMs. You can look at Nexenta as an option, iSCSI, FCoE, NFS and CIFS in one box. -Ross |
From: Ross S. W. W. <RW...@me...> - 2010-08-25 16:08:06
|
James LeRoy [mailto:ja...@su...] wrote: > > I found LIO, but I'm really hesitant just by looking at their website. I > can't find anything, not even the download for it. It has a crazy link that > says 'random page' that I had to just keep clicking to read more about it > because there weren't actual links to all the pages in the site. Yeah their website could use a little work. > I've previously looked into Nexenta because of interest in the dedup, but I > discovered their free iSCSI was too limiting. Every client gets to see > every target. If it was all VMware no big deal, but I don't want Hyper-V > and VMware seeing each other's LUNs. That really shouldn't be if configured properly. Nexenta uses a general SCSI target framework, so after adding the volume to the framework you need to define "views" which say which initiators can see which volumes. If creating views isn't available on the interface then you should be able to do it from the command line. > SCST and STGT look like possible options, but STGT doesn't > support a config file natively only a hacked one. > > Unfortunately I just completed my lease replacement of my old IET server to > latest and greatest IET and I can't switch to another solution without doing > some proper testing. That testing will take me some time and hopefully, > I'll keep my fingers crossed, IET will add SCSI3 reservation before I'm > ready to switch. If anything I will probably just have a small solution in > parallel to IET to bide me some time until IET is ready. How about this: 1) Use IET to provide iSCSI storage to Nexenta Community Edition head server, which then builds a zpool of one or more iSCSI targets, then serves that out via NFS and CIFS to ESX/Hyper-V (separate datasets on same zpool). 2) Configure iSCSI within the VM guests themselves to connect to IET for their application data. In my testing the heavy read caching of NFS and CIFS allows for a greater VM density per datastore. I recommend having 2 or more RAID sets on IET for this. One RAID maybe 1TB SATA drives for VM datastore (in RAID6) and 600GB SAS drives for application data (in RAID10). Of course if the app data is file based you can put it on the SATA otherwise if it is database based put it on the SAS. > Ross, if I were a C programmer I'd help you all I can. You've been > impressively dedicated to this project for a long time. All too often open > source developers abandon their projects. You do a great job and you're > greatly appreciated. Thanks for the encouragement. I want to see if we can get SCSI3 compatibility by year end. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. |