action #48635
closed
[functional][u] test fails in kvm - no svm flag for openqaworker13 (AMD worker)
Added by dheidler about 5 years ago.
Updated almost 5 years ago.
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 25
Description
Observation¶
openQA test in scenario sle-12-SP5-Server-DVD-x86_64-qemu@64bit fails in
kvm
I don't really understand why it doesn't work on openqaworker13 but works fine for O3 worker "imagetester" which has an AMD CPU as well: https://openqa.opensuse.org/tests/864932
Test suite description¶
Maintainer: dheidler@suse.de - Test QEMU and KVM
Reproducible¶
Fails since (at least) Build 0126 (current job)
Expected result¶
Last good: 0126 (or more recent)
Suggestions¶
- Find out why the KVM kernel module can not be loaded on some workers -> #48746
- If necessary run tests based on the worker class and/or move scenario back to test development
- Make sure the prerequisites from the worker side are fulfilled before conducting steps within the SUT which can only work if the worker fulfills KVM
Further details¶
Always latest result in this scenario: latest
Workaround¶
Retrigger until jobs end up on a different worker that works
- Description updated (diff)
- Status changed from New to Workable
- Priority changed from Normal to High
Moved your personal remark from "Further details" to "Observations". Should fit better there, right?
Tickets which are linked to currently failing tests should be at least "High" so feel free to set accordingly for new tickets in the future.
- Copied to action #48746: [functional][u][timeboxed:4h] test fails in kvm - no svm flag for openqaworker13 (AMD worker) - investigate why KVM kernel module can not be loaded on some workers added
- Description updated (diff)
- Status changed from Workable to Blocked
- Assignee set to mgriessmeier
In the sprint planning meeting we should investigate first in the time-boxed task #48746
Assigned to @mgriessmeier for tracking
- Assignee changed from mgriessmeier to dheidler
- Status changed from Blocked to Feedback
hi dheidler, good you found out that soon. Will @nicksinger upgrade the workers that soon? If this is not planned in the near future I suggest to go again with either the dedicated worker class or disable the complete test case for now again on that machine type on osd. Otherwise I fear that we will have a "sporadically failing test case" which will confuse other reviewers and do more harm than good.
dheidler wrote:
--> https://gitlab.suse.de/openqa/salt-pillars-openqa/merge_requests/165/diffs
We will loose capacity by disabling a machine that works for other scenarios. Maybe what we need for these cases is to add a worker class with the machine name to each worker host, so that we can pick a specific worker host if needed (that would also be useful to debug problems that only happens on one worker host) -> #49520
- Related to action #49520: [functional][u] Add an extra unique worker class to each worker host added
- Target version changed from Milestone 23 to Milestone 24
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: qemu
https://openqa.suse.de/tests/2812698
- Related to deleted (action #49520: [functional][u] Add an extra unique worker class to each worker host)
- Related to action #49520: [functional][u] Add an extra unique worker class to each worker host added
- Status changed from Feedback to Workable
I think we can provide a PR on the salt states to add an extra worker class for machines we know that support kvm. Then add this as worker_class for the testsuite.
This should not cause any influence on already running tests.
- Target version changed from Milestone 24 to Milestone 25
moved to M25
@dheidler, could you please clarify current status here?
Waiting for Nick to update the worker OS.
openqaworker13 is now updated to leap15.0
- Status changed from Workable to In Progress
- Status changed from In Progress to Resolved
Also available in: Atom
PDF