Bug 1631573

Summary: Network creation tools MAY have issues with long adapter names.
Product: [Community] Virtualization Tools Reporter: Brian Woods <bpwoods>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED DEFERRED QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: berrange, crobinso, gscrivan, tburke
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-16 15:44:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot of error. none

Description Brian Woods 2018-09-21 00:23:23 UTC
Created attachment 1485352 [details]
Screenshot of error.

Description of problem:


When working on a system that has two NIC with a naming standard (such as enp1s0f0 and enp1s0f1), it always checks the first interface even is the second is selected.  This only impacts the "Virtual Network" area and does not appear to impact the "Network Interfaces".


How reproducible:
Every time.


Steps to Reproduce:
1.Have a system with stated naming standard for NICs.
2.Try to create a virtual network using the second device while the first it in use.


See the attachment, notice that the interface selected on the first screen does not match the interface in the error.

Comment 1 Brian Woods 2018-09-21 00:24:16 UTC
Version:
virt-manager/bionic,bionic,now 1:1.5.1-0ubuntu1 all [installed]

Comment 2 Cole Robinson 2019-06-16 15:44:14 UTC
Thanks for the report. I think what that error is refering to is that the selected network address is already in use by another virtual network. So for example you specified <ip address='192.168.124.1'> which is already used by another <network> definition. It isn't related to interface naming. The libvirt error could be clearer and virt-manager could try and ensure we don't default to any conflicting network addresses, but it's not due to any naming mixup