QA » openQA Project » openQA Tests

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.

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

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

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

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.