action #107302
open
[qe-core] Work around serial console problems in Hyper-V
Added by szarate almost 3 years ago.
Updated 9 months ago.
Description
Observation¶
Hyper-V sporadically fails when the hypervisor is overloaded and the serial connection to the SUT is erratic (see poo#97745). This makes the first command after the root terminal is sellected to fail. Currently there is no movement on fixing the backend issue so we need to find a workaround.
openQA test in scenario sle-15-SP4-Online-x86_64-default@svirt-hyperv fails in
system_prepare
Test suite description¶
Maintainer: QE Core
The standard scenario where we mainly just follow installation suggestions without any adjustments.
Reproducible¶
Fails since (at least) Build 97.1
Acceptance Criteria¶
- AC1: Workaround the sporadically failing serial console.
- AC2: (Optional) Move the test off serial console to ssh or another type of console. Look at os-autoinst/consoles directory for options.
Expected result¶
Last good: 97.1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Related issues
2 (2 open — 0 closed)
- Description updated (diff)
- Description updated (diff)
- Subject changed from test fails in system_prepare - system prepare should run in serial mode (preferably a script) to [qe-core] test fails in system_prepare - system prepare should run in serial mode (preferably a script)
- Status changed from New to Workable
- Priority changed from Normal to High
- Target version set to QE-Core: Ready
- Parent task set to #107323
- Status changed from Workable to New
- Target version deleted (
QE-Core: Ready)
Please see the ticket description before setting to workable
- Subject changed from [qe-core] test fails in system_prepare - system prepare should run in serial mode (preferably a script) to [qe-core] Work around serial console problems in Hyper-V
- Description updated (diff)
- Status changed from New to Workable
Refinement:
This fails because the SUT has a broken serial console. This should be worked around, either by moving it to ssh or with timeouts, or with whatever the assignee discovers.
If I understood correctly currently on the hyperv host some rather old proprietary solution is used for the serial console serving from the Windows server whereas we use socat on client (backend) side. I already recommended in the scope of #105473 to also use socat on Windows for the server side.
- Related to action #97745: [virtualization][hyperv] ensure_serialdev_permissions fails for hyperv added
- Blocks action #107383: [opensuse]Leap 15.4 test fails in system_prepare - unexpected console login? added
- Category changed from Bugs in existing tests to Spike/Research
- Assignee set to szarate
This is related to how the systems are set up and permissions in the console after a reboot... one idea is that changes in the console can be managed through udev rules.
These tickets are not on high prio
These tickets are not on high pro
- Priority changed from High to Normal
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.
Also available in: Atom
PDF