Project

General

Profile

action #123960

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

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

Status:
Resolved
Priority:
Low
Assignee:
mgriessmeier
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

Related to openQA Tests - action #119233: [security][15sp5][s390x] boot_to_desktop test fails on specific s390 workersWorkable2022-10-24

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

History

#1 Updated by MDoucha about 1 month ago

  • Project changed from openQA Tests to openQA Infrastructure
  • Category deleted (Bugs in existing tests)

#2 Updated by amanzini about 1 month ago

  • Related to action #119233: [security][15sp5][s390x] boot_to_desktop test fails on specific s390 workers added

#3 Updated by jlausuch about 1 month 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

#4 Updated by mgriessmeier about 1 month 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 :)

#5 Updated by okurz about 1 month 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

#6 Updated by okurz about 1 month 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

Also available in: Atom PDF