Project

General

Profile

Actions

action #99441

closed

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 about 3 years ago. Updated almost 3 years ago.

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

100%

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 1 (0 open1 closed)

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

Actions
Actions #1

Updated by rfan1 about 3 years 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.

Actions #2

Updated by rfan1 about 3 years ago

  • Parent task set to #93441
Actions #3

Updated by rfan1 about 3 years ago

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

Updated by openqa_review about 3 years 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
Actions #5

Updated by rfan1 about 3 years 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
Actions #6

Updated by rfan1 about 3 years 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 )
Actions #7

Updated by openqa_review about 3 years 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
Actions #8

Updated by rfan1 about 3 years 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

Actions #9

Updated by openqa_review almost 3 years 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/7910770

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
Actions #10

Updated by rfan1 almost 3 years ago

  • Status changed from New to In Progress

A new workaround can be applied by adding a 2nd NIC.

#virsh net-start default
#virsh net-autostart default
#virsh attach-interface --domain openQA-SUT-mm-1 --type bridge --source virbr0 --model virtio --config --live
#virsh attach-interface --domain openQA-SUT-mm-2 --type bridge --source virbr0 --model virtio --config --live

XML configuration sample:
    <interface type='direct'>
      <mac address='xx:xx:xx:xx:xx:xx'/>
      <source dev='eth0' mode='bridge'/>
      <target dev='macvtap0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
    </interface>
    <interface type='bridge'>
      <source bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <alias name='net1'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0004'/>
    </interface>
Actions #11

Updated by rfan1 almost 3 years ago

I did a installation tests with 2 NICs attached to the vm and re-used the default boot parameter which defined in openQA sample xml file, and good news was installation passed without any issue:

    <type>hvm</type>
    <kernel>/var/lib/libvirt/images/linux</kernel>
    <initrd>/var/lib/libvirt/images/initrd</initrd>
    <cmdline>ifcfg=dhcp install=ftp://hostname/SLE-15-SP4-Online-s390x-Build79.1-Media1  sshd=1 VNC=1 VNCSize=1024x768 VNCPassword=xxxxxx sshpassword=xxxxxx SetHostname=0   regurl=http://all-79.1.proxy.scc.suse.de</cmdline>

After OS installation, I can see both NICs and the 2nd NIC is in "DOWN" status, we can bring it up for later tests.

Actions #12

Updated by rfan1 almost 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 30 to 100

With Matthias's kindly help, we can move on with a new zkvm lpar to run the s390x zkvm test with the workaround mentioned above. let me close this ticket.

I will file a new one to implement the test

Actions

Also available in: Atom PDF