Error code: SR_BACKEND_FAILURE_200 Error parameters: , General IO error [opterr=An error occured during the scsi operation],

[Syed Muhammad Hassan Hassan]

When I add HBA LUNS from xencenter or by command (xe sr-probe type=lvmohba host-uuid=279782eb-95a8-4d03-9684-33282d99a11b). I get an error:

 

Error code: SR_BACKEND_FAILURE_200 Error parameters: , General IO error [opterr=An error occured during the scsi operation],

 

Please help me to resolve this issue. I am badly in need of help.

[Alan Lantz]

Is your hardware on the HCL ? What is your XenServer version? Do you multipath and/or use Jumbo Frames ? Has this ever worked or is 

this something new ?

 

--Alan--

 

[Tobias Kreidl]

Could also be related to a failure on the storage itself (such as a failing hard drive), in other words, not the fault of XenServer itself.  Is there anything more related to this error that might add extra clues in the /var/log/SMlog files?

 

-=Tobias

[ali raza1709160995]

@ Alan: Xenserver version is 6.5 , we have also tried this with xen 7.0 also. But issue persists. and we are using multipath. We have been using Hardware HBA to probe new LUNs (from FC SAN backend)

 

@Tobias: I am also checking SAN logs for any issues (so far none) and it is only affecting new probes. Existing LUNs are working fine. I have also tried to safely move (LUNs) from one XENserver to another (in which case, it reattaches the LUNs and "we move them from backend storage Views) but still fails to detect that and gives same General IO error. I have  pasted SMlogs for reference.

SMLogs when failure occurs are: 
May 25 10:55:03 esnode17 SM: [18608] '
May 25 10:55:03 esnode17 SM: [18608] ['scsi_id', '-g', '--device', '/dev/sdx'] failed with ('Operation not permitted',)
May 25 10:55:03 esnode17 SM: [18608] ['scsi_id', '-g', '-s', '/block/sdx']
May 25 10:55:03 esnode17 SM: [18608]   pread SUCCESS
May 25 10:55:03 esnode17 SM: [18608] ['scsi_id', '-g', '--device', '/dev/sdw']
May 25 10:55:03 esnode17 SM: [18608] FAILED in util.pread: (rc 1) stdout: '', stderr: 'scsi_id: invalid option -- -
May 25 10:55:03 esnode17 SM: [18608] '
May 25 10:55:03 esnode17 SM: [18608] ['scsi_id', '-g', '--device', '/dev/sdw'] failed with ('Operation not permitted',)
May 25 10:55:03 esnode17 SM: [18608] ['scsi_id', '-g', '-s', '/block/sdw']

 

Edit#01:  All the multipaths are healthy (verified via xen as well as backend)

[ali raza1709160995]

Issue Solution in Our Case:

 

One liner: " Asssign LUN ID between 0-256 OR Don't assign LUN ID greater than 256 to XEN SR (via FC SAN Backend)". As Xen will throw below exception, if LUN ID (being discovered via Hardware HBA is greater than 256), see below SMlog:

SM: [30020] scsi add-single-device 0 0 0 258
May 25 17:00:54 esnode17 SM: [30020] SCSI_DEV_CTRL: Failure, Invalid argument [22]
May 25 17:01:00 esnode17 SM: [30020] Raising exception [200, General IO error [opterr=An error occured during the scsi operation]]

In above case, I was constantly trying to add LUNs with ID greater than 256 (above case with 4 multipath: 0 0 0 258 ), and then saw in /var/log/SMlog that it was only giving failure if LUN ID was above 256.

It seems there might be a size limit to the LUN ID Number (Might be the size of variable (1 Byte) that stores the LUN ID in XEN, I have not read about the exact technical details, may be there is some other reason behind it ).  Anyways, if it helps anyone else :) 

 

Thank you so much Tobias & Alan for pointing me in the right direction 

 

[Tobias Kreidl]

Ah, that certainly would explain it! Do you have any idea why it's trying to use such a high LUN value (258)?

If it falls outside the acceptable range, that would certainly trigger an error condition. I do ot recall my ever manually needing to set such a value, and always just using the defaults.

 

-=Tobias

[ali raza1709160995]

Exactly, actually XEN was not the culprit, if LUN is added automatically XEN host assigns the lowest unused number (which usually does not reach such high value per XEN server Host).

 

In our case, one of the backend FC SAN Array was the reason for high LUN value (it was set to auto increment the LUN ID value). We usually (manually) kept that exact (LUN ID) value for our XEN host for audit purposes, so when one of the FC Array 'LUN ID count' reached above 256 ( in total for all XEN host), it triggered the error. Now, as you've said, we are ( not manually assigning LUN ID to xen host) auto assigning LUN ID to XEN hosts and it is working fine :)

 

- Ali Raza

[Tobias Kreidl]

Good to hear, @Ali! Glad that's all sorted out now.

 

-=Tobias

[ali raza1709160995]

Thank you so much @Tobias for all the help :)

 

- Ali Raza

[Syed Muhammad Hassan Hassan]

Thank you so much Tobias and Alan for putting us in right direction. I am much obliged for you help. Dear Tobias logs of this ( /var/log/SMlog ) was very useful for us. Thanks again for your extended support. You both of them made our day :-)

 

[Alan Lantz]

wow, I didn't know that LUN limit. I have multiple targets on my storage so I rarely see a LUN number above ten.

Good to here you have that figure out.

 

--Alan--