Project

General

Profile

Actions
Copy link

action #123960

closed

s390x tests fail to log into VNC console on worker2 due to already present VM with same mac address

Added by MDoucha about 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Low
Assignee:
mgriessmeier
Category:
-
Target version:
QA - future
Start date:
2023-02-06
Due date:
% Done:

0%

Estimated time:

Description

Observation

s390x tests started randomly failing last week when they try to log into the freshly booted test system. There are multiple instances across all SLE releases both before and after applying incident patches so this is most likely an infra issue.
https://openqa.suse.de/tests/10427719#step/update_kernel/20
https://openqa.suse.de/tests/10427825#step/update_kernel/20
https://openqa.suse.de/tests/10432751#step/update_kernel/20
https://openqa.suse.de/tests/10424294#step/boot_ltp/21

Reproducible

Fails since (at least) Build :27598:kgraft-patch-SLE12-SP5_Update_35

Expected result

Last good: :27599:kgraft-patch-SLE12-SP5_Update_36 (or more recent)

Further details

Always latest result in this scenario: latest

Related issues 2 (2 open — 0 closed)

Related to openQA Tests - action #119233: [security] boot_to_desktop test fails on specific s390 workers due to closed SSH portWorkable

Actions
Copied to openQA Project - action #123972: s390x tests fail to log into VNC console on worker2 due to already present VM with same mac address, check within backendNew2023-02-06

Actions
Actions
Copy link
 #1

Updated by MDoucha about 1 year ago

  • Project changed from openQA Tests to openQA Infrastructure
  • Category deleted (Bugs in existing tests)
Actions
Copy link
 #2

Updated by amanzini about 1 year ago

  • Related to action #119233: [security] boot_to_desktop test fails on specific s390 workers due to closed SSH port added
Actions
Copy link
 #3

Updated by jlausuch about 1 year ago

Yes, I also detected it in SLE Micro, the combustion configuration can't reach conncheck.opensuse.org
https://openqa.suse.de/tests/10433042#step/boot_to_desktop/9

Actions
Copy link
 #4

Updated by mgriessmeier about 1 year ago

  • Status changed from New to Feedback

As found out very quickly, only worker2:28 was affected.
There was a VM manually spawned on s390zp18 (on 27th of January) which used the same mac address as the worker instance worker2:28
since this machine was up and running, the actual worker could not login.
machine was shutdown and the jobs pass again on worker2:28 (https://openqa.suse.de/tests/10433735#)

I wonder what would be the best approach to monitor this, probably by scanning for duplicate max adresses on the s390x LPARs (virsh dumpxml)

@okurz - closed for me, followup if necessary :)

Actions
Copy link
 #5

Updated by okurz about 1 year ago

  • Copied to action #123972: s390x tests fail to log into VNC console on worker2 due to already present VM with same mac address, check within backend added
Actions
Copy link
 #6

Updated by okurz about 1 year ago

  • Subject changed from s390x tests fail to log into VNC console on worker2 to s390x tests fail to log into VNC console on worker2 due to already present VM with same mac address
  • Status changed from Feedback to Resolved
  • Assignee set to mgriessmeier
  • Priority changed from Normal to Low
  • Target version set to future

I think checking XML files for validity is a good idea. I created #123972 for that idea

Actions
Copy link

Also available in: Atom PDF