action #96296
closedcoordination #96302: [qe-core][QU] Quarterly update failures
[qem] test fails in disk_activation
100%
Description
Observation¶
- no devices are in the list
openQA test in scenario sle-15-SP3-Online-QR-s390x-zfcp@s390x-zfcp fails in
disk_activation
Test suite description¶
Maintainer: QE Yast, mgriessmeier
Installation-only test configuring an s390x ZFCP storage.
Reproducible¶
Fails since (at least) Build 188.11
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by szarate over 3 years ago
- Parent task set to #96302
Setting to parent task to have a common tracker
Updated by oorlov over 3 years ago
This failure does not relate to any test code/schedule files. No changes were introduced.
Looks like a product bug or infrastructure issue. Matthias suggested to set up the machine manually and check the issue.
I'm not an expert in s390x setup, so this ticket is better to address to whom it may concern.
Updated by geor over 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 20
Updated by geor over 3 years ago
- % Done changed from 20 to 90
It seems like s390qa101.qa.suse.de has no issues with zfcp, whereas s390qa102.qa.suse.de does.
Whenever the job ends up running in the second worker instance (s390qa102.qa.suse.de) disk_activation module will fail.
Bringing the FCP device online with chccwdev -e 0.0.fa00 on s390qa101 results in the respective LUNs getting attached:
# lsluns
Scanning for LUNs on adapter 0.0.fa00
at port 0x500507630703d3b3:
0x4001405000000000
at port 0x500507630708d3b3:
0x4001405000000000
Bringing the FCP device online with chccwdev -e 0.0.fa00 on s390qa102 results in the following:
# lsluns
lsluns: No port on any adapter exists
# lszfcp -PHD
0.0.fa00 host0
Error: No fcp devices found.
# cat /proc/scsi/scsi (shows no SCSI attached devices)
Attached devices:
#
Also in s390qa101 the output of lszdev does show the two SCSI devices (with both names)
zfcp-lun 0.0.fa00:0x500507630703d3b3:0x4001405000000000 yes no sdb sg1
zfcp-lun 0.0.fa00:0x500507630708d3b3:0x4001405000000000 yes no sda sg0
whereas, in s390qa102 it does not
After consulting with Matthias on this, it turns out that there could be a probable mapping discrepancy, where the 0.0.fa00 points to different devices between the two s390 instances, resulting in this inconsistency. Further investigation will need to be done in order to pinpoint the exact root of the problem. For now a workaround will be to only schedule the zfcp testsuites on worker instance 1.
Updated by geor over 3 years ago
Updated by geor over 3 years ago
- Related to action #96680: [qe-core] s390qa102.qa.suse.de zfcp issue added
Updated by geor over 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
Resolving this issue,
Added related issue in order to fix s390qa102, for now disc_activation will not fail because it will always run on s390qa101.