QA » openQA Project » openQA Tests

Fails also on aarch64.
The default network is not created. Bug or feature update?
We could add '--network none' to the virt-install command to get rid of the network configuration problem, if it is not due to a bug.

We should have a default NAT configuration which is in package 'libvirt-daemon-config-network'.

@aginies as "virtualization expert" as well as the test module maintainer in our tests, what is your judgement: Do we need to change something in tests or should we consider this as a product bug?

The default network should be active by default, so i would say there is something wrong if it is not the case. Sounds like a bug

note that, NM is now the default network management for desktop environment rather than wicked.

mlin7442 wrote:

note that, NM is now the default network management for desktop environment rather than wicked.

NetworkManager? this is not supported at all.
Everything dealing with Hypervisor is on SLES product, with Wicked. NM is desktop only, and we don't support SLED being an hypervisor. So this is not a bug.

Not sure I understand. You mention supported SLE cases which I understand but can we try to find a technical solution here please?

okurz wrote:

Not sure I understand. You mention supported SLE cases which I understand but can we try to find a technical solution here please?

create a network an use it:
/etc/libvirt/qemu/networks/testing_network.xml

<network>
<name>testing_network</name>
<uuid>{UUID}</uuid>
<forward mode='nat'/>
<bridge name='{BRIDGE}' stp='on' delay='0'/>
<mac address='{NETMACHOST}'/>
<domain name='{NETWORKNAME}'/>
<ip address='{NETWORK}.1' netmask='255.255.255.0'>
<dhcp>
<range start='{NETWORK}.128' end='{NETWORK}.254'/>
<host mac="{MACA}" name="{NODENAME}" ip="{NETWORK}.101" />
etc....
</dhcp>
</ip>
</network>
</pre>

virsh net-autostart testing_network
virsh net-start testing_network

another 2 options perhaps:

1) boot from textmode image
2) boot from miniamlX image(generic desktop) which still have had wicked as the default network management

So what do people expect from virt-install? If I have a desktop do I install virt-manager and use the gui to use virt-install to install VMs? If so virt-install should be made to work with NM without hacks out of the box.

@okurz as discussed yesterday, the network manager change was introduced as part of the SLE 15 style system roles. That was coordinated with the SLE functional testing team with the goal of making sure we didn't run into too many test failures due to that significant change in behaviour. This is one that got away, obviously, but I think you're going too far and risk being seen to use this situation as a rod to beat a dead horse into submission.

So, let's stop pointing figures at look at this holistically

First, consider that libvirt networking is abstracted away from both wicked and NM.
The 'default' network is provided by "libvirt-daemon-config-network"

The question to me becomes "Why does libvirt network 'default' get activated when wicked is the default network stack, but not with NM?"

Is the libvirt-daemon-config-network package not being installed?
Is this a bug that needs to be fixed in libvirt-daemon-config-network?
If libvirt-daemon-config-network is installed, why is the default.xml not being activated? This is probably a bug that needs to be fixed.

It's been 11 days since Max reported this issue and right now I would say that no one has actually looked at the bug in question..lets start with that, perhaps with my above points as a headstart, before worrying about changing tests or products.

• Rich

So … can I assume aginies to look into it? Not sure I got how exactly you want to coordinate further work.

RBrownSUSE wrote:

So, let's stop pointing figures at look at this holistically

First, consider that libvirt networking is abstracted away from both wicked and NM.
The 'default' network is provided by "libvirt-daemon-config-network"

The question to me becomes "Why does libvirt network 'default' get activated when wicked is the default network stack, but not with NM?"

Is the libvirt-daemon-config-network package not being installed?
Is this a bug that needs to be fixed in libvirt-daemon-config-network?
If libvirt-daemon-config-network is installed, why is the default.xml not being activated? This is probably a bug that needs to be fixed.

It's been 11 days since Max reported this issue and right now I would say that no one has actually looked at the bug in question..lets start with that, perhaps with my above points as a headstart, before worrying about changing tests or products.

Given no one else seems to have taken the initative and followed my above advice, I took the tiny steps of answering the simple questions above.

Is the libvirt-daemon-config-network package not being installed?

Correct, the libvirt-daemon-config-network package is not installed, neither by yast vm nor zypper in patterns-server-kvm_server

Is this a bug that needs to be fixed in libvirt-daemon-config-network?

Maybe

https://build.opensuse.org/package/view_file/Virtualization/libvirt/libvirt.spec?expand=1

libvirt-daemon-config-network is required by libvirt

libvirt is not installed by patterns-server-kvm_server (it is a suggests: https://build.opensuse.org/package/view_file/openSUSE:Factory/patterns-server/patterns-server.spec?expand=1)

yast vm installs patterns-server-kvm_server https://github.com/yast/yast-vm/blob/3fdc972d9323cd4c1c73898994723c9f5b517bd5/src/modules/VirtConfig.rb

This bug seems to be simply a case of either libvirt missing from patterns-server-kvm_server or some other more suitable dependency solution to ensure libvirt-daemon-config-network is actually installed

The bug has been filed https://bugzilla.opensuse.org/show_bug.cgi?id=1109832

So the bug mentions https://build.opensuse.org/request/show/639622 which in turn was declined to favor https://build.opensuse.org/request/show/625134 which was accepted 5 days ago and the according SR to openSUSE:Factory would be https://build.opensuse.org/request/show/639838 which was also accepted 5 days ago. However, this does not fix the tests and I am not even sure if it was expected to do so: https://openqa.opensuse.org/tests/769647

@aginies I assume you are still aware of this? May I ask what you plan about this ticket and the failing test?

@aginies I assume you are still aware of this? May I ask what you plan about this ticket and the failing test?

Sorry, i don't follow openSUSE openQA.
does the needed patterns installed? Its not done by yast2-vm under openSUSE (as the patterns were not available). You need to get patterns_server_kvm_tools installed to be able to get the default network setup (libvirt one).
Yast2-vm should be modified to handle this installation. I updated the bug.

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

This bug is still referenced in a failing openQA test: virtualization
https://openqa.opensuse.org/tests/779516

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

This bug is still referenced in a failing openQA test: virtualization
https://openqa.opensuse.org/tests/787342

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

This bug is still referenced in a failing openQA test: virtualization
https://openqa.opensuse.org/tests/799902

The SR for https://bugzilla.opensuse.org/show_bug.cgi?id=1109832 has been accepted 15 days ago, tests still fail though in https://openqa.opensuse.org/tests/805269#step/virt_install/24 with "network 'default' is not active". Both pattern kvm_tools and libvirt-daemon-config-network seem to be installed though.

commented the bug.
Based on the fact there is all packages this sounds like the default network is not started.

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

This bug is still referenced in a failing openQA test: virtualization
https://openqa.opensuse.org/tests/815403

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

This bug is still referenced in a failing openQA test: virtualization
https://openqa.opensuse.org/tests/821229

No one has replied to my comment on the bug. There is no way to fix that without log. There is also a way to get this fix in comment (starting the network by hand)

maxlin plans to take a look this week

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

This bug is still referenced in a failing openQA test: virtualization
https://openqa.opensuse.org/tests/832401

@agraul PR merged, seems to be ok. Now the post_fail_hook in the following module https://openqa.opensuse.org/tests/843249#step/virt_install/39 failed *within the post_fail_hook. I think mgriessmeier implemented that "which" part and could help you with that. Please take a look there as well as why the test module actually fails.