Project

General

Profile

action #99441

action #93441: [sle][security][sle15sp4][CC] CC hand over

[sle][security][sle15sp4][CC][s390x]test fails in netfilter, communication failed with macvlan

Added by rfan1 2 months ago. Updated 20 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2021-09-29
Due date:
% Done:

30%

Estimated time:
40.00 h
Difficulty:

Description

Observation

openQA test in scenario sle-15-SP4-Online-s390x-cc_net_case_client@s390x-kvm-sle12 fails in
netfilter

Test suite description

Reproducible

Fails since (at least) Build 36.1

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest


Related issues

Related to openQA Tests - action #101157: [sle][security][sle15sp4][CC][s390x][cc_net_case_client]test fails in boot_to_desktopResolved2021-10-19

History

#1 Updated by rfan1 2 months ago

Add the background here, I may need kindly help from expert from s390x platform.

Hello Matthias,

Thanks for your feedback on my question issued in Slack "eng-testing" channel! it was a bit complex to describe my issue. hence writing this mail to you and include my mate and Sunny here.

Let me share some background information at first, we have been working on some Common Criteria tests in past few months, and some tests should be run on multi-machine setup.

One test scenario is creating a macvlan device upon the default NIC "eth0" [or bridge "br0"] on VM1 and configuring static ip address on it as well.

The same thing should be done on the other VM2. then both VMs can commute via macvlan device.

We have passed the tests on x86_64 platform:
https://openqa.suse.de/tests/7148558
https://openqa.suse.de/tests/7148559

But failed on s390x platform:
https://openqa.suse.de/tests/7192884
https://openqa.suse.de/tests/7192885

I did some investigation, And I found the issue might have something to do with the VM's network configuration within openQA.

Take XXXX as an example, all VM's networks are configured with macvtap + ethx

TEST:~ # virsh dumpxml openQA-SUT-2|grep -A5 interface






In this case, if I configure macvlan device on the VM, I can't ping through between VM1/VM2 later.

I tried to change my own VM's network to default bridge "virbr0", no issue seen. [I think x86_64 tests within openqa uses tap devices for multi-machine tests]

TEST:~ # virsh dumpxml openQA-SUT-rfan|grep -A5 interface





The sample command to configure ma​cvlan device:

VM1:
susetest:~ # ip link add link eth0 address 00:11:11:11:11:10 eth0.0 type macvlan
susetest:~ # ip link set eth0.0 up
susetest:~ # ip addr add 192.168.0.2/24 dev eth0.0

VM2:
susetest:~ # ip link add link eth0 address 00:11:11:11:11:11 eth0.0 type macvlan
susetest:~ # ip link set eth0.0 up
susetest:~ # ip addr add 192.168.0.4/24 dev eth0.0

=======================================================================================================

So many messages have been pasted here, let me summary my question/requirement :)

  1. Can you please help fix this issue as you are expert on s390x, I am not sure if I need modify some parameters

  2. Given the fact that, configure VM's network from bridge can be a workaround, can you please help create a new ZKVM lpar with bridge network? like below configuration:

eth0->> br0, and then all VMs' network can use this bridge br0. I think we can also get a dhcp address as we use current mode :ethx + macvtap

However, codes need to be revised to fit openQA tests run, may need lots of effort.

Please let me know if any information required.

BR//Richard.

#2 Updated by rfan1 2 months ago

  • Parent task set to #93441

#3 Updated by rfan1 about 2 months ago

  • Related to action #101157: [sle][security][sle15sp4][CC][s390x][cc_net_case_client]test fails in boot_to_desktop added

#4 Updated by openqa_review about 1 month ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: cc_net_case_client
https://openqa.suse.de/tests/7503406

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

#5 Updated by rfan1 about 1 month ago

  • Copied to action #101914: [sle][security][sle15sp4][CC] handle network difference for s390x compare to aarch64 and x86_64 on netfilter and netfilebt tests added

#6 Updated by rfan1 about 1 month ago

  • Copied to deleted (action #101914: [sle][security][sle15sp4][CC] handle network difference for s390x compare to aarch64 and x86_64 on netfilter and netfilebt tests )

#7 Updated by openqa_review 27 days ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: cc_net_case_client
https://openqa.suse.de/tests/7647288

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

#8 Updated by rfan1 20 days ago

  • Priority changed from Low to Normal
  • % Done changed from 0 to 30

Matthias has helped setup a new s390x zkvm lpar with bridge network.

however, right now, the vm on this lpar fails to get dhcp ip address. investigating

Also available in: Atom PDF