action #110170
closedRequest for s390x worker class with SIE support
100%
Description
User story¶
A majority of our s390x test runs for SLE Micro fail when testing kvm because most of the s390 workers do not have the required SIE (start-interpretive execution) CPU feature.
To solve this issue we would need another worker class, e.g. s390-kvm-sle12-virt for workers that hold this feature.
Support for this feature can be done by querying /proc/cpuinfo on the corresponding worker:
grep sie /proc/cpuinfo
Acceptance criteria¶
- Add new worker class e.g.
s390-kvm-sle12-virtfor s390x workers with SIE support
Tasks¶
- Add new worker class e.g.
s390-kvm-sle12-virtfor s390x workers with SIE support
Further details¶
- The name
s390-kvm-sle12-virtis a spontaneous suggestion and can be replace with a better fitting one - See https://progress.opensuse.org/issues/110155
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/appe-kvm_on_zsystems
Updated by okurz over 2 years ago
- Project changed from openQA Project (public) to openQA Infrastructure (public)
- Target version set to future
Sounds feasible but not related to openQA directly, at least not the upstream project, rather infrastructure definitions. Should be doable by everyone with access to salt pillars. @ph03nix any good reason why you couldn't just solve it yourself directly by adding a merge request to salt pillars?
Updated by ph03nix over 2 years ago
- Project changed from openQA Infrastructure (public) to openQA Project (public)
- Target version deleted (
future)
okurz wrote:
Sounds feasible but not related to openQA directly, at least not the upstream project, rather infrastructure definitions. Should be doable by everyone with access to salt pillars. @ph03nix any good reason why you couldn't just solve it yourself directly by adding a merge request to salt pillars?
I unfortunately don't have any knowledge about our s390x workers, nor can I see where the physical machines are located.
You can now point me to people who I could ask how to do this. However I believe it's more economical that someone with knowledge takes this task, instead of me bugging them on how to do it.
Updated by okurz over 2 years ago
- Project changed from openQA Project (public) to openQA Infrastructure (public)
- Target version set to future
Updated by szarate over 2 years ago
A new LPAR or a zKVM host with a SIE enabled needs to be enabled on it's facility, and also have the Adjunct Processor (AP) Cryptographic Facility
https://github.com/os-autoinst/os-autoinst/pull/2036 all there is left to do is to actually try it out and add the path of the device, once it is available.
Updated by okurz over 2 years ago
- Status changed from New to In Progress
- Assignee set to okurz
- Target version changed from future to Ready
I wanted to offer you a way for self-service to solve your own problems but maybe I couldn't make that clear. So I will pick up this ticket and try to help more.
I asked in chat who would like to support: https://suse.slack.com/archives/C02CANHLANP/p1650618602282939
and gladly szarate quickly reacted.
With a combination of
for i in $(sed -n 's/VIRSH_HOSTNAME: \(s390.*\)/\1/p' openqa/workerconf.sls | sort | uniq); do echo $i; sshpass -p XXX ssh-copy-id root@$i; done
to setup the initial connection to each s390 qemu machine we have defined within salt pillars I did
for i in $(sed -n 's/VIRSH_HOSTNAME: \(s390.*\)/\1/p' openqa/workerconf.sls | sort | uniq); do echo $i; ssh root@$i "grep sie /proc/cpuinfo" ; echo $?; done
so seems like all machines already have "sie".
I checked all s390 machines we have for qemu in salt pillars and can confirm that sie is there on s390zp{12,14,15,17,18,19}. Maybe define to pass all flags from the host machine in libvirt?
EDIT: I guess maybe something in https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/installation/bootloader_zkvm.pm ?
Updated by ph03nix over 2 years ago
Thanks for the help! Now waiting for https://github.com/os-autoinst/os-autoinst/pull/2036 to be merged and then see if this fixes the issue.
Updated by ph03nix over 2 years ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
I'm closing this issue, as the root cause for the request of a new worker class originated from a wrong configuration (https://progress.opensuse.org/issues/110155#note-12) and it got resolved in the meantime.
No need for an additional WORKER_CLASS, the systems are not behaving as expected.