CentOS 6.7 + cDOT 8.3.1: kernel: scsi: host X channel Y id Z lun4194304 has a LUN larger than allowed by the host adapter
Hi,
Before I take a long journey with NetApp support, let me ask you guys.
I have CentOS 6.7 server and I'm trying to attach a cDOT LUN to it as path discovery fails with:
kernel: scsi: host 0 channel 3 id 0 lun4194304 has a LUN larger than allowed by the host adapter
However it only fails with the message above for one HBA out of two installed into the server. The HBAs (drivers, firmware etc) are identical. The HBA are Qlogic relabeled as HP.
So RedHat has a KB article for it https://access.redhat.com/solutions/67157 and it's advised to contact storage appliance vendor.
I've seen that once, it was due to some FW files being absent under /lib/firmware, it's not the same this time.
Has anyone seen that before?
Cheers, Vladimir
Are both initiators in the same igroup on NetApp?
Отправлено с iPhone
12 окт. 2015 г., в 17:30, Momonth momonth@gmail.com написал(а):
Hi,
Before I take a long journey with NetApp support, let me ask you guys.
I have CentOS 6.7 server and I'm trying to attach a cDOT LUN to it as path discovery fails with:
kernel: scsi: host 0 channel 3 id 0 lun4194304 has a LUN larger than allowed by the host adapter
However it only fails with the message above for one HBA out of two installed into the server. The HBAs (drivers, firmware etc) are identical. The HBA are Qlogic relabeled as HP.
So RedHat has a KB article for it https://access.redhat.com/solutions/67157 and it's advised to contact storage appliance vendor.
I've seen that once, it was due to some FW files being absent under /lib/firmware, it's not the same this time.
Has anyone seen that before?
Cheers, Vladimir _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Yes, they are, both are logged in. On Oct 13, 2015 07:13, "andrei.borzenkov@ts.fujitsu.com" < andrei.borzenkov@ts.fujitsu.com> wrote:
Are both initiators in the same igroup on NetApp?
Отправлено с iPhone
12 окт. 2015 г., в 17:30, Momonth momonth@gmail.com написал(а):
Hi,
Before I take a long journey with NetApp support, let me ask you guys.
I have CentOS 6.7 server and I'm trying to attach a cDOT LUN to it as path discovery fails with:
kernel: scsi: host 0 channel 3 id 0 lun4194304 has a LUN larger than allowed by the host adapter
However it only fails with the message above for one HBA out of two installed into the server. The HBAs (drivers, firmware etc) are identical. The HBA are Qlogic relabeled as HP.
So RedHat has a KB article for it https://access.redhat.com/solutions/67157 and it's advised to contact storage appliance vendor.
I've seen that once, it was due to some FW files being absent under /lib/firmware, it's not the same this time.
Has anyone seen that before?
Cheers, Vladimir _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Funky enough .. I have the 2nd cluster in the other DC, running 8.3.1, with CentOS 6.7 initiator (with default version of HBA drivers, firmwares) that doesn't experience this issue ... I conclude it has something to do with SVM configuration.
On Mon, Oct 12, 2015 at 3:17 PM, Momonth momonth@gmail.com wrote:
Hi,
Before I take a long journey with NetApp support, let me ask you guys.
I have CentOS 6.7 server and I'm trying to attach a cDOT LUN to it as path discovery fails with:
kernel: scsi: host 0 channel 3 id 0 lun4194304 has a LUN larger than allowed by the host adapter
However it only fails with the message above for one HBA out of two installed into the server. The HBAs (drivers, firmware etc) are identical. The HBA are Qlogic relabeled as HP.
So RedHat has a KB article for it https://access.redhat.com/solutions/67157 and it's advised to contact storage appliance vendor.
I've seen that once, it was due to some FW files being absent under /lib/firmware, it's not the same this time.
Has anyone seen that before?
Cheers, Vladimir
"Momonth" == Momonth momonth@gmail.com writes:
Do you have the ostype set correctly? Same initiators on the CentOS 6.7 working system as on the busted on? I assum you did something like:
lun create -vserver foo /vol/bar/lun1 -size 1g -ostype linux
and it's messed up? Did you try creating a new small test lun on the busted setup and seeing if that lun has too big a lun ID?
What does the 'lun show -m' on the problematic lun show? Since it's working on one HBA, but not the other... that semi implies to me that you have an HBA config issue.
Trying to create a new test lun might help figure out what's going on here?
Momonth> Funky enough .. I have the 2nd cluster in the other DC, running 8.3.1, Momonth> with CentOS 6.7 initiator (with default version of HBA drivers, Momonth> firmwares) that doesn't experience this issue ... I conclude it has Momonth> something to do with SVM configuration.
Momonth> On Mon, Oct 12, 2015 at 3:17 PM, Momonth momonth@gmail.com wrote:
Hi,
Before I take a long journey with NetApp support, let me ask you guys.
I have CentOS 6.7 server and I'm trying to attach a cDOT LUN to it as path discovery fails with:
kernel: scsi: host 0 channel 3 id 0 lun4194304 has a LUN larger than allowed by the host adapter
However it only fails with the message above for one HBA out of two installed into the server. The HBAs (drivers, firmware etc) are identical. The HBA are Qlogic relabeled as HP.
So RedHat has a KB article for it https://access.redhat.com/solutions/67157 and it's advised to contact storage appliance vendor.
I've seen that once, it was due to some FW files being absent under /lib/firmware, it's not the same this time.
Has anyone seen that before?
Cheers, Vladimir
Momonth> _______________________________________________ Momonth> Toasters mailing list Momonth> Toasters@teaparty.net Momonth> http://www.teaparty.net/mailman/listinfo/toasters
Hi
On Tue, Oct 13, 2015 at 6:07 PM, John Stoffel john@stoffel.org wrote:
"Momonth" == Momonth momonth@gmail.com writes:
Do you have the ostype set correctly? Same initiators on the CentOS 6.7 working system as on the busted on? I assum you did something like:
lun create -vserver foo /vol/bar/lun1 -size 1g -ostype linux
and it's messed up? Did you try creating a new small test lun on the busted setup and seeing if that lun has too big a lun ID?
The "ostype" is set to "linux". If I create another LUN on the other 2 pairs of filers (i have 6 nodes cluster) in the same cluster, it works as expected, ie 4 paths per LUN.
I think I localized the issue to just one node in the cluster.
What does the 'lun show -m' on the problematic lun show? Since it's working on one HBA, but not the other... that semi implies to me that you have an HBA config issue.
Trying to create a new test lun might help figure out what's going on here?
Momonth> On Tue, Oct 13, 2015 at 6:07 PM, John Stoffel john@stoffel.org wrote:
> "Momonth" == Momonth momonth@gmail.com writes:
Do you have the ostype set correctly? Same initiators on the CentOS 6.7 working system as on the busted on? I assum you did something like:
lun create -vserver foo /vol/bar/lun1 -size 1g -ostype linux
and it's messed up? Did you try creating a new small test lun on the busted setup and seeing if that lun has too big a lun ID?
Momonth> The "ostype" is set to "linux". If I create another LUN on the other 2 Momonth> pairs of filers (i have 6 nodes cluster) in the same cluster, it Momonth> works as expected, ie 4 paths per LUN.
Momonth> I think I localized the issue to just one node in the cluster.
Funky. sounds like maybe rebooting that node (after doing a failover to the other half of the HA pair) might be one solution here.
So if you create new LUNs on that problematic node, they all show up with the high LUN id?
What version of 8.2 are you running? There are some patches out there and we're running 8.2.3P2 ourselves, but not with many LUNs (FCP or iSCSI) at all.
What does the 'lun show -m' on the problematic lun show? Since it's working on one HBA, but not the other... that semi implies to me that you have an HBA config issue.
Trying to create a new test lun might help figure out what's going on here?
On Wed, Oct 14, 2015 at 4:13 PM, John Stoffel john@stoffel.org wrote:
Funky. sounds like maybe rebooting that node (after doing a failover to the other half of the HA pair) might be one solution here.
I'm tempted to do that, however if it fixes the issue, then I'm not able to debug it any further and don't really understand the root cause.
So if you create new LUNs on that problematic node, they all show up with the high LUN id?
Yes, LUN ID changes, it started with 0, I can verify it with "lun mapping show -fields path,lun-id"
What version of 8.2 are you running? There are some patches out there and we're running 8.2.3P2 ourselves, but not with many LUNs (FCP or iSCSI) at all.
It's cDOT 8.3.1
On Wed, Oct 14, 2015 at 5:06 PM, Momonth momonth@gmail.com wrote:
I'm tempted to do that, however if it fixes the issue, then I'm not able to debug it any further and don't really understand the root cause.
The node reboot (via takeover) didn't resolve the issue. Awesome =)
"Momonth" == Momonth momonth@gmail.com writes:
Momonth> On Wed, Oct 14, 2015 at 5:06 PM, Momonth momonth@gmail.com wrote:
I'm tempted to do that, however if it fixes the issue, then I'm not able to debug it any further and don't really understand the root cause.
Momonth> The node reboot (via takeover) didn't resolve the issue. Awesome =)
Ouch... sounds more and more like a cluster wide issue. Have you opened a ticket with Netapp yet on this? Can you show the output (sanitized of course) of 'lun show -m' maybe? But honestly, this is a job for support to deal with.
Good luck! John
Yes, I think I have to open a ticket at this point .. it's just I have CentOS which is strictly speaking not supported, but I'll give it a try.
On Wed, Oct 14, 2015 at 5:56 PM, John Stoffel john@stoffel.org wrote:
Ouch... sounds more and more like a cluster wide issue. Have you opened a ticket with Netapp yet on this? Can you show the output (sanitized of course) of 'lun show -m' maybe? But honestly, this is a job for support to deal with.
Any progress on this? Looking at how Linux kernel presents LUN numbers, 4194304 = 0x400000 translates to LUN 0000:0040 on the wire; and this looks pretty unexpected.
--- With best regards
Andrei Borzenkov Senior system engineer FTS WEMEAI RUC RU SC TMS FOS
FUJITSU Zemlyanoy Val Street, 9, 105 064 Moscow, Russian Federation Tel.: +7 495 730 62 20 ( reception) Mob.: +7 916 678 7208 Fax: +7 495 730 62 14 E-mail: Andrei.Borzenkov@ts.fujitsu.com Web: ru.fujitsu.com Company details: ts.fujitsu.com/imprint This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Momonth Sent: Thursday, October 15, 2015 11:03 AM To: John Stoffel Cc: toasters@teaparty.net Subject: Re: CentOS 6.7 + cDOT 8.3.1: kernel: scsi: host X channel Y id Z lun4194304 has a LUN larger than allowed by the host adapter
Yes, I think I have to open a ticket at this point .. it's just I have CentOS which is strictly speaking not supported, but I'll give it a try.
On Wed, Oct 14, 2015 at 5:56 PM, John Stoffel john@stoffel.org wrote:
Ouch... sounds more and more like a cluster wide issue. Have you opened a ticket with Netapp yet on this? Can you show the output (sanitized of course) of 'lun show -m' maybe? But honestly, this is a job for support to deal with.
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
I opened a ticket with netapp support, it's not progressing fast, i'll keep you posted guys.
On Tue, Oct 20, 2015 at 1:22 PM, andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com wrote:
Any progress on this? Looking at how Linux kernel presents LUN numbers, 4194304 = 0x400000 translates to LUN 0000:0040 on the wire; and this looks pretty unexpected.
With best regards
Andrei Borzenkov Senior system engineer FTS WEMEAI RUC RU SC TMS FOS
FUJITSU Zemlyanoy Val Street, 9, 105 064 Moscow, Russian Federation Tel.: +7 495 730 62 20 ( reception) Mob.: +7 916 678 7208 Fax: +7 495 730 62 14 E-mail: Andrei.Borzenkov@ts.fujitsu.com Web: ru.fujitsu.com Company details: ts.fujitsu.com/imprint This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Momonth Sent: Thursday, October 15, 2015 11:03 AM To: John Stoffel Cc: toasters@teaparty.net Subject: Re: CentOS 6.7 + cDOT 8.3.1: kernel: scsi: host X channel Y id Z lun4194304 has a LUN larger than allowed by the host adapter
Yes, I think I have to open a ticket at this point .. it's just I have CentOS which is strictly speaking not supported, but I'll give it a try.
On Wed, Oct 14, 2015 at 5:56 PM, John Stoffel john@stoffel.org wrote:
Ouch... sounds more and more like a cluster wide issue. Have you opened a ticket with Netapp yet on this? Can you show the output (sanitized of course) of 'lun show -m' maybe? But honestly, this is a job for support to deal with.
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Отправлено с iPhone
14 окт. 2015 г., в 18:16, Momonth momonth@gmail.com написал(а):
On Wed, Oct 14, 2015 at 4:13 PM, John Stoffel john@stoffel.org wrote:
Funky. sounds like maybe rebooting that node (after doing a failover to the other half of the HA pair) might be one solution here.
I'm tempted to do that, however if it fixes the issue, then I'm not able to debug it any further and don't really understand the root cause.
So if you create new LUNs on that problematic node, they all show up with the high LUN id?
Yes, LUN ID changes, it started with 0, I can verify it with "lun mapping show -fields path,lun-id"
If you convert LUN number in hex it is 0x400000. It actually looks like LUN 0, returned in flat addressing format that for some reason gets misinterpreted by Linux. I'd love to see dump of actual CDB on Linux side.
What version of 8.2 are you running? There are some patches out there and we're running 8.2.3P2 ourselves, but not with many LUNs (FCP or iSCSI) at all.
It's cDOT 8.3.1 _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
You mean the CDB dump for a LUN that has no issues?
Here it is:
# /usr/bin/sg_luns -d -vv /dev/sdm open /dev/sdm with flags=0x802 report luns cdb: a0 00 00 00 00 00 00 00 20 00 00 00 report luns: requested 8192 bytes but got 24 bytes Lun list length = 16 which imples 2 lun entries
Output response in hex 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 10 00 03 00 00 00 00 00 00 Report luns [select_report=0]: 0000000000000000 Peripheral device addressing: lun=0 0003000000000000 Peripheral device addressing: lun=3
It looks really different, comparing to what RedHat's KB says ..
On Thu, Oct 15, 2015 at 7:15 AM, andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com wrote:
If you convert LUN number in hex it is 0x400000. It actually looks like LUN 0, returned in flat addressing format that for some reason gets misinterpreted by Linux. I'd love to see dump of actual CDB on Linux side.
I actually mean - dump for LUN having issues ...
--- With best regards
Andrei Borzenkov Senior system engineer FTS WEMEAI RUC RU SC TMS FOS
FUJITSU Zemlyanoy Val Street, 9, 105 064 Moscow, Russian Federation Tel.: +7 495 730 62 20 ( reception) Mob.: +7 916 678 7208 Fax: +7 495 730 62 14 E-mail: Andrei.Borzenkov@ts.fujitsu.com Web: ru.fujitsu.com Company details: ts.fujitsu.com/imprint This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.
-----Original Message----- From: vladimir.zhigulin@gmail.com [mailto:vladimir.zhigulin@gmail.com] On Behalf Of Momonth Sent: Thursday, October 15, 2015 11:01 AM To: Borzenkov, Andrei Cc: John Stoffel; toasters@teaparty.net Subject: Re: CentOS 6.7 + cDOT 8.3.1: kernel: scsi: host X channel Y id Z lun4194304 has a LUN larger than allowed by the host adapter
You mean the CDB dump for a LUN that has no issues?
Here it is:
# /usr/bin/sg_luns -d -vv /dev/sdm open /dev/sdm with flags=0x802 report luns cdb: a0 00 00 00 00 00 00 00 20 00 00 00 report luns: requested 8192 bytes but got 24 bytes Lun list length = 16 which imples 2 lun entries
Output response in hex 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 10 00 03 00 00 00 00 00 00 Report luns [select_report=0]: 0000000000000000 Peripheral device addressing: lun=0 0003000000000000 Peripheral device addressing: lun=3
It looks really different, comparing to what RedHat's KB says ..
On Thu, Oct 15, 2015 at 7:15 AM, andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com wrote:
If you convert LUN number in hex it is 0x400000. It actually looks like LUN 0, returned in flat addressing format that for some reason gets misinterpreted by Linux. I'd love to see dump of actual CDB on Linux side.
There is actually no block device (/dev/sd?) being created for the problematic LUN, I really need to say "the problematic SAN paths" here, as only one node replies something the Linux kernel / HBA driver can not handle.
On Thu, Oct 15, 2015 at 10:27 AM, andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com wrote:
I actually mean - dump for LUN having issues ...
One more thing:
If I move the LUN from the problematic node ("vol move ..") to an aggregate on the healthy node and then re-discover paths - everything comes up properly.
On Thu, Oct 15, 2015 at 10:44 AM, Momonth momonth@gmail.com wrote:
There is actually no block device (/dev/sd?) being created for the problematic LUN, I really need to say "the problematic SAN paths" here, as only one node replies something the Linux kernel / HBA driver can not handle.
On Thu, Oct 15, 2015 at 10:27 AM, andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com wrote:
I actually mean - dump for LUN having issues ...
Is any /dev/sg created for *anything* on this target? You can actually use any device name for REPORT LUNS; and it should always be possible to send command to LUN 0.
--- With best regards
Andrei Borzenkov Senior system engineer FTS WEMEAI RUC RU SC TMS FOS
FUJITSU Zemlyanoy Val Street, 9, 105 064 Moscow, Russian Federation Tel.: +7 495 730 62 20 ( reception) Mob.: +7 916 678 7208 Fax: +7 495 730 62 14 E-mail: Andrei.Borzenkov@ts.fujitsu.com Web: ru.fujitsu.com Company details: ts.fujitsu.com/imprint This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.
-----Original Message----- From: vladimir.zhigulin@gmail.com [mailto:vladimir.zhigulin@gmail.com] On Behalf Of Momonth Sent: Thursday, October 15, 2015 11:45 AM To: Borzenkov, Andrei Cc: John Stoffel; toasters@teaparty.net Subject: Re: CentOS 6.7 + cDOT 8.3.1: kernel: scsi: host X channel Y id Z lun4194304 has a LUN larger than allowed by the host adapter
There is actually no block device (/dev/sd?) being created for the problematic LUN, I really need to say "the problematic SAN paths" here, as only one node replies something the Linux kernel / HBA driver can not handle.
On Thu, Oct 15, 2015 at 10:27 AM, andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com wrote:
I actually mean - dump for LUN having issues ...
No, there is nothing created for the problematic node, the LUN is only available via the node's partner:
# /usr/bin/sg_luns -d -vv /dev/sdb open /dev/sdb with flags=0x802 report luns cdb: a0 00 00 00 00 00 00 00 20 00 00 00 report luns: requested 8192 bytes but got 16 bytes Lun list length = 8 which imples 1 lun entry
Output response in hex 00 00 00 00 08 00 00 00 00 00 01 00 00 00 00 00 00 Report luns [select_report=0]: 0001000000000000 Peripheral device addressing: lun=1
On Thu, Oct 15, 2015 at 11:12 AM, andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com wrote:
Is any /dev/sg created for *anything* on this target? You can actually use any device name for REPORT LUNS; and it should always be possible to send command to LUN 0.
With best regards
Andrei Borzenkov Senior system engineer FTS WEMEAI RUC RU SC TMS FOS
FUJITSU Zemlyanoy Val Street, 9, 105 064 Moscow, Russian Federation Tel.: +7 495 730 62 20 ( reception) Mob.: +7 916 678 7208 Fax: +7 495 730 62 14 E-mail: Andrei.Borzenkov@ts.fujitsu.com Web: ru.fujitsu.com Company details: ts.fujitsu.com/imprint This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.
-----Original Message----- From: vladimir.zhigulin@gmail.com [mailto:vladimir.zhigulin@gmail.com] On Behalf Of Momonth Sent: Thursday, October 15, 2015 11:45 AM To: Borzenkov, Andrei Cc: John Stoffel; toasters@teaparty.net Subject: Re: CentOS 6.7 + cDOT 8.3.1: kernel: scsi: host X channel Y id Z lun4194304 has a LUN larger than allowed by the host adapter
There is actually no block device (/dev/sd?) being created for the problematic LUN, I really need to say "the problematic SAN paths" here, as only one node replies something the Linux kernel / HBA driver can not handle.
On Thu, Oct 15, 2015 at 10:27 AM, andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com wrote:
I actually mean - dump for LUN having issues ...
I got it resolved finally, I had to push NetApp support a lot, but they managed to point me to the right direction in the end.
So, there were two separate issues that I mistakenly combined:
1. Missing paths were due to wrong zoning. It sounds silly, but I couldn't spot it.
2. "kernel: scsi: host 0 channel 3 id 0 lun4194304 has a LUN larger than allowed by the host adapter" error message comes from HP RAID controller, it has nothing to do with NetApp filers.
Key here is to pay attention to details: "host 0 channel 3 id 0" tells exactly what target it is about, also 'lsscsi' utility comes handy in here.
Here is a quote from RedHat's KB article about the error message:
Smart Array Physical Devices Example
# lsscsi [4:0:0:0] disk HP LOGICAL VOLUME 6.00 /dev/sdb /dev/sg0 [4:3:0:0] storage HP P220i 6.00 - /dev/sg1
And within /var/log/messages file:
: Apr 9 10:54:17 hostname kernel: scsi: host 4 channel 3 id 0 lun4194304 has a LUN larger than allowed by the host adapter :
Within the above example, the Smart Array raid controller device at scsi address 4:3:0:0 returns a lun list which includes a lun id value of 4194304. This id value is in a vendor specific format. This is one of the physical devices behind the controller that would typically be used as part of the logical volume. Since only the logical volumes should be accessed by the system, this physical lun number can be ignored. Typically only HP health agents would access information on the physical disk devices via the raid controller device. Not all combinations of Smart Array model, firmware, and hpsa driver revisions will report physical disk devices back to the host. Normally these devices are filtered off in later hpsa driver / Smart Array firmware combinations.
Cheers, Vladimir
On Mon, Oct 12, 2015 at 3:17 PM, Momonth momonth@gmail.com wrote:
So RedHat has a KB article for it https://access.redhat.com/solutions/67157 and it's advised to contact storage appliance vendor.
-
andrei.borzenkov＠ts.fujitsu.com -
John Stoffel -
Momonth