Bug 1607760 - virt-install with --network network:default fails on the first run of a test in a batch
Summary: virt-install with --network network:default fails on the first run of a test ...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-24 08:20 UTC by Radek Vykydal
Modified: 2019-05-28 21:56 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-05-28 21:56:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
--debug virt-install output for issue in comment #2 (16.32 KB, text/plain)
2018-07-24 14:53 UTC, Radek Vykydal
no flags Details

Description Radek Vykydal 2018-07-24 08:20:24 UTC
Description of problem:

We are running installer kicstart tests in kvm in Openstack (nested virtualization). When running a batch of tests (using 4 VMs in parallel), the first test (or tests if running at the same time in parallel) using "--network network:default" option fail with:

ERROR Network not found: no network with matching name 'default'

The following tests in the batch find the network without issues.

The issue is hit in following test batches but from some point it seemed to stop occuring.

Version-Release number of selected component (if applicable):

F28
virt-install-1.5.1-1.fc28.noarch
libvirt-daemon-4.1.0-3.fc28.x86_64

Example:

Running... virt-install -n LiveOS-5f27d63c-ca58-44ad-a25a-258ce8fa4beb -r 2048 --noautoconsole --vcpus 1 --rng /dev/random --noreboot --graphics vnc --initrd-inject /home/kstest/kickstart-tests/team.ks --disk path=/var/tmp/kstest-team.sa49nndx/disk-a.img,cache=unsafe --network network:default --network network:default --network network:default --network network:default --network network:default --disk path=/var/tmp/kstest-team.sa49nndx/boot.master.iso,device=cdrom,readonly=on,shareable=on --extra-args ks=file:/team.ks vnc debug=1 inst.debug ip=enp0s3:dhcp inst.updates=http://10.43.136.2/ks/rv/updates.r8importstateonboot.img stage2=hd:CDLABEL=RHEL-8-0-BaseOS-x86_64 --location /var/tmp/kstest-team.sa49nndx/lorax.imgutils.hgnwfxuw --channel tcp,host=127.0.0.1:49021,mode=connect,target_type=virtio,name=org.fedoraproject.anaconda.log.0
WARNING  No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results.

...
ERROR    Network not found: no network with matching name 'default'

Note: we are setting up some virt networks during the tests if it is important.

Any additional info/logs we can provide?

Comment 1 Pavel Hrdina 2018-07-24 10:28:02 UTC
This sounds like some race-condition.  Is the "default" network created by the test suite prior to running virt-install?

You can run virt-install with --debug to see what is going on.

Comment 2 Radek Vykydal 2018-07-24 14:52:07 UTC
We are assuming the default network is there by default, is this a wrong assumption?

Trying to reproduce with --debug it started to give another type of error:

"ERROR    monitor socket did not show up: No such file or directory"

I will attach the output with --debug but I'd like to do the same for the original default network issue.  I'll give it some more tries.

Comment 3 Radek Vykydal 2018-07-24 14:53:04 UTC
Created attachment 1470313 [details]
--debug virt-install output for issue in comment #2

Comment 4 Ben Cotton 2019-05-02 21:15:56 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Ben Cotton 2019-05-28 21:56:53 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.