Hi, thanks for the report.  However I was not able to reproduce this bug following the steps described here <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Configure_Network_Bridging.html> or here <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Network_configuration-Bridged_networking.html#sect-Network_configuration-Bridged_networking_in_RHEL>.


I don't know what you mean by these steps:

"The way to use the bridge was changing the *Network source* and here selecting the *Specify shared device name*. On *Bridge name:* field I used the DEVICE name instead of NAME."


Please provide the exact steps how did you create the bridge and also provide content of "/etc/sysconfig/network-scripts/ifcfg-{BRIDGE_NAME|INTERFACE_NAME}" and all related interfaces connected to that bridge.

Hi Pavel, good morning

Thanks for your reply, one question, after create the bridge via OS, should be necessary create a new bridge via virt-manager *like in the second link sent by you* ?

I believe this procedure will create *in fact* a new bridge.

Well, my question is, after create the bridge on OS, this one should be visible into the virt-manager when I create a new machine or just change the network of one already ready ?

I can prepare one step by step on my side just to reproduce all steps, btw I believe your answer will define the next step. :)

Appreciate your help.


Best Regards
-- 
Waldirio M Pinheiro | Senior Software Maintenance Engineer

Hi Waldirio, you can use the OS way or virt-manager way, both will set the bridge for OS and also for virt-manager/libvirt.

Yes this procedure creates a new bridge properly so virt-manager and libvirt are able to see/work with that bridge.

Hi Pavel,

Thanks for your reply, give me some time to create one doc with all steps used in my environment, then I'll share via bz.


Best Regards
-- 
Waldirio M Pinheiro | Senior Software Maintenance Engineer

Created attachment 1267952 [details]
step by step

Hi Pavel, good morning

I added one step by step, looking into the document, you will see the bridgeMundo which should be available or visible on the virt-manager, at the end, I created a new one *newbridgeCLI* and the behavior was the same, not visible on virt-manager.

I did one restart on NetworkManager and libvirtd.

Please, let me know if you need something else from my side.

Best Regards
-- 
Waldirio M Pinheiro | Senior Software Maintenance Engineer

Hi, thanks for the report.  As you can see the newly created bridge "bridgeisolated" is visible.  I also asked for the /etc/sysconfig/network-scripts/ifcfg-* files but you forget to provide them.

All bridges with "virbr" prefix are listed as "Virtual Networks".

Some background for virt-manager, it will display only bridges that are configured properly and also are visible for libvirt, virt-manager has all the data from libvirt and on RHEL libvirt gets all data about network interfaces from netcf.

So if you run "virsh iface-list --all" or "ncftool list --all" (you have to install "netcf" package to have ncftool binary) and you don't see that bridge virt-manager is not able to display that bridge as well.

I'm suspecting that you have something wrong in your configuration, please provide all the "ifcfg-*" files in the /etc/sysconfig/network-scripts/ directory.

Because that error message comes from netcf I'm moving this bug to that component for further investigation.  For some reason netcf is not able to parse all ifcfg files and that's why the bridge is not visible in libvirt and therefore also in virt-manager.

Looks similar to bug 1044770.

Please run the following command and paste the output into a comment here:

   ncftool -d list --all

(you may need to install the netcf package, since libvirt only pulls in netcf-libs, which doesn't include ncftool).

That will show us which line of which file is causing the "errors in loading some config files".

When I put all your ifcfg files on my own RHEL7 system, I don't get any errors.

(BTW, just for general info, it's possible to test a set of ifcfg files from "somewhere else" on your system by extracting them into ${somedir}/etc/sysconfig/network-scripts, and then running:

    ncftool -r ${somedir} list --all

(or dumpxml or whatever))

Hi Laine

Below the output

[root@dvader ~]# ncftool -d list --all
warning: augeas initialization had errors
please file a bug with the following lines in the bug report:
/augeas/files/etc/sysconfig/network-scripts/ifcfg-files.tar/error = "parse_failed"
/augeas/files/etc/sysconfig/network-scripts/ifcfg-files.tar/error/pos = "0"
/augeas/files/etc/sysconfig/network-scripts/ifcfg-files.tar/error/line = "1"
/augeas/files/etc/sysconfig/network-scripts/ifcfg-files.tar/error/char = "0"
/augeas/files/etc/sysconfig/network-scripts/ifcfg-files.tar/error/lens = "/usr/share/augeas/lenses/dist/sysconfig.aug:65.12-.71:"
/augeas/files/etc/sysconfig/network-scripts/ifcfg-files.tar/error/message = "Get did not match entire input"
error: unspecified error
error: errors in loading some config files
[root@dvader ~]#

After see the error, I saw the backup file created in /etc/sysconfig/network-scritps/ifcfg-files.tar, then I removed it and rerun the command.

[root@dvader network-scripts]# ncftool -d list --all
bridgeIsolated
enp0s25
lo
[root@dvader network-scripts]#

Then, I rerun the virsh command

[root@dvader network-scripts]# virsh iface-list 
 Name                 State      MAC Address
---------------------------------------------------
 bridgeIsolated       active     6a:5a:e7:d2:37:e8
 enp0s25              active     68:f7:28:40:e4:c0
 lo                   active     00:00:00:00:00:00

[root@dvader network-scripts]#

Ok, now I can see the output of commands btw I can't see the bridge bridgeMundo.

thank you for all help and sorry *my fault* one tar file starting by ifcfg-xxx


Best Regards
-- 
Waldirio M Pinheiro | Senior Software Maintenance Engineer

> Ok, now I can see the output of commands btw I can't see the bridge
> bridgeMundo.

That's strange - although there are problem with the dumpxml, on my system I do see both of the bridges in the list. Does it show up with "ncftool list --all" or "virsh iface-list --all"? And do you see it in the list in virt-manager now?

BTW, netcf was originally written with the assumption that the ifcfg filename and device name of all network devices would match. Try changing the names of the ifcfg files to ifcfg-enp0s25, ifcfg-bridgeMundo, and ifcfg-bridgeIsolated and see if the situation improves (on my system, that fixes the output of the dumpxml for all interfaces, and removes enp0s25 from the list of toplevel devices (from netcf's POV, it is a slave of bridgeMundo, so it only shows up as a part of that device's xml, not as a device on its own).

Good afternoon

Below all commands from my machine after one full reboot, and no, I can't see the bridgeMundo Bridge via cli *ncftool or virsh* or virt-manager, only via nmcli

Let me know what more do you need from my system.

Thank you!!

---
[root@dvader ~]# ncftool list --all
bridgeIsolated
enp0s25
lo
[root@dvader ~]#
---

---
[root@dvader ~]# virsh iface-list --all
 Name                 State      MAC Address
---------------------------------------------------
 bridgeIsolated       active     ca:e7:4a:eb:3d:e3
 enp0s25              active     68:f7:28:40:e4:c0
 lo                   active     00:00:00:00:00:00

[root@dvader ~]#
---

---
[root@dvader ~]# nmcli c
NAME                    UUID                                  TYPE             DEVICE         
BridgeWall              d2ab98f2-633c-4689-8dbd-e2dba6c54a1f  bridge           bridgeMundo    
São Paulo (GRU2)        26d95e8e-bac5-4308-bc01-ea93656fa112  vpn              bridgeMundo    
bridgeMundo_Slave_1     3f4ad041-bee5-4d35-bec2-dc7c9ae56158  802-3-ethernet   enp0s25        
bridge_isolated         c0440801-cb7f-476a-8870-40127732af88  bridge           bridgeIsolated 
docker0                 e59bfa93-4d80-47a7-a89b-0da46586220a  bridge           docker0        
tun0                    4183928b-5799-4659-ba0b-250fdb1fe962  tun              tun0           
virbr0                  26a946ab-cd5d-4a92-ae38-24a35b535f5a  bridge           virbr0         
virbr1                  01a769fa-db26-486c-aa35-fddee7038561  bridge           virbr1         
virbr2                  c88fb35b-8c9b-402a-939b-e21a38630d6c  bridge           virbr2         
virbr3                  20759c3f-d671-47be-85bf-ff11b41de378  bridge           virbr3         
Amsterdam (AMS2)        7b487c5c-09c9-4c4c-95b0-e562c4a5ad43  vpn              --             
Beijing PEK2 (OpenVPN)  13bdb983-e5b4-4951-9e69-7ba42d6edc49  vpn              --             
Brisbane (BNE)          9822534a-1693-4e50-9f61-1560bf0cee17  vpn              --             
Brno (BRQ)              5777c2b4-defc-46f1-9858-2b850d51587c  vpn              --             
Farnborough (FAB)       f3967fc7-a927-47e2-92fd-a53338d4bb92  vpn              --             
Phoenix (PHX2)          c9509a40-caed-46c2-a3ef-706b5a98265f  vpn              --             
REGUSNETWIFI            aa688015-2ad4-4999-9b7c-f52508151bc2  802-11-wireless  --             
Raleigh (RDU2)          f281b867-85e1-4979-8adf-ad9fac216a7c  vpn              --             
Singapore (SIN2)        461f8cf8-c8dc-478b-9669-80ca01d04c5b  vpn              --             
Speed_Marlus            9b5d663e-d8a3-4492-be77-076cd5296ad6  802-11-wireless  --             
Tokyo (NRT)             ef06e9c8-f787-4419-9790-fd89bcbe70da  vpn              --             
enp0s25                 340503b4-e679-f113-2778-985445badaee  802-3-ethernet   --             
home_papa               17f94272-cf12-47f0-83d7-94f7822f1758  802-11-wireless  --             
home_test               be69ca39-36ee-4ac9-8620-c74c76fa3da6  802-11-wireless  --             
warzone                 de89a1cb-3796-4956-8af7-9a1db618453e  802-11-wireless  --             
warzone1                59f0bf73-4af5-4691-a8af-f1d8fdfdf183  802-11-wireless  --             
zoc                     4799160d-faf5-40d8-877e-2913c87863b2  802-11-wireless  --             
[root@dvader ~]#
---

Created attachment 1272117 [details]
virt-manager

I've added the same files on my RHEL7.4 system and do see "bridgeMundo" in the output of virsh iface-list --all and ncftool list --all, so I'm unsure what the problem might be on your system. Can you verify that the files haven't changed from the files you attached to this BZ?

I noticed that you have a file named ifcfg-enp0s25, and also one named ifcfg-bridgeMundo_Slave_1 that both reference the same interface. That's unusual, but when I have that situation on my machine it still shows bridgeMundo.

The only other thing I can suggest is to rename ifcfg-bridgeWall to ifcfg-bridgeMundo (so that the filename and device name match), and remove the existing  ifcfg-enp0s25 and rename ifcfg-bridgeMundo_Slave_1 to ifcfg-enp0s25. netcf has some level of expectation that the ifcfg filename and device name will match (although, as I've said above, your config files still provide the expected result).

Hello Team

I got the same behavior on another machine, below detailed description.


// Another machine, initially with RHEL 7.2 then I did the upgrade to RHEL 7.3 and did one restart.

[root@desk network-scripts]# nmcli c
NAME                  UUID                                  TYPE            DEVICE        
bridge-BridgeDefault  72459fa9-2671-4294-832d-78582c1ab3c8  bridge          BridgeDefault 
bridge-slave-p1p1     d54239e3-c049-4948-bbe0-2d39a21269c7  802-3-ethernet  p1p1          
virbr0                3233027d-665b-4d21-9839-1a37dee1905b  bridge          virbr0        
virbr1                651ed0f9-5405-4778-b616-f9bf2e42e185  bridge          virbr1        
virbr2                cf1d85a0-04a3-493c-b43f-5790b6120e8e  bridge          virbr2        
Wired connection 1    3113786c-9389-4659-9981-d6a8d22e51c4  802-3-ethernet  --            
br0                   d2d68553-f97e-7549-7a26-b34a26f29318  bridge          --            
p1p1                  46e26279-f69b-daf5-1b79-d03677b7178d  802-3-ethernet  --            
[root@desk network-scripts]#

[root@desk network-scripts]# ncftool list --all
br0
lo
[root@desk network-scripts]#

[root@desk network-scripts]# virsh net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 default              active     yes           yes
 isolated             active     yes           yes
 sat6Prov             active     yes           yes

[root@desk network-scripts]#

[root@desk network-scripts]# virsh iface-list --all
 Name                 State      MAC Address
---------------------------------------------------
 br0                  inactive   
 lo                   active     00:00:00:00:00:00

[root@desk network-scripts]# 

======

[root@desk network-scripts]# pwd
/etc/sysconfig/network-scripts
[root@desk network-scripts]# ll ifcfg*
-rw-r--r--. 1 root root 206 Nov 14 04:06 ifcfg-br0
-rw-r--r--. 1 root root 364 May 11 10:36 ifcfg-bridge-BridgeDefault
-rw-r--r--. 1 root root 146 May 11 09:43 ifcfg-bridge-slave-p1p1
-rw-r--r--. 1 root root 254 Sep 12  2016 ifcfg-lo
-rw-r--r--. 1 root root  57 May 11 10:37 ifcfg-p1p1
-rw-r--r--. 1 root root 340 Apr 15  2016 ifcfg-Wired_connection_1
[root@desk network-scripts]#

// Laine comment
---
I've added the same files on my RHEL7.4 system and do see "bridgeMundo" in the output of virsh iface-list --all and ncftool list --all, so I'm unsure what the problem might be on your system. Can you verify that the files haven't changed from the files you attached to this BZ?

I noticed that you have a file named ifcfg-enp0s25, and also one named ifcfg-bridgeMundo_Slave_1 that both reference the same interface. That's unusual, but when I have that situation on my machine it still shows bridgeMundo.

The only other thing I can suggest is to rename ifcfg-bridgeWall to ifcfg-bridgeMundo (so that the filename and device name match), and remove the existing  ifcfg-enp0s25 and rename ifcfg-bridgeMundo_Slave_1 to ifcfg-enp0s25. netcf has some level of expectation that the ifcfg filename and device name will match (although, as I've said above, your config files still provide the expected result).
---

So doing the follow up according the advices, the first one was remove the *ifcfg-p1p1* file, after that I did restart according below

# systemctl restart NetworkManager
# systemctl restart network

[root@desk network-scripts]# ncftool list --all
BridgeDefault    <=== Visible now
br0
lo
[root@desk network-scripts]# virsh iface-list --all
 Name                 State      MAC Address
---------------------------------------------------
 br0                  inactive   
 lo                   active     00:00:00:00:00:00

[root@desk network-scripts]#

// At this momment I did one restat on libvirtd, just to reflect on the virsh command

[root@desk network-scripts]# systemctl restart libvirtd
[root@desk network-scripts]# virsh iface-list --all
 Name                 State      MAC Address
---------------------------------------------------
 br0                  inactive   
 BridgeDefault        active     00:00:00:00:00:00    <=== Visible now
 lo                   active     00:00:00:00:00:00

[root@desk network-scripts]#

And now I'm able to see the bridge via Virt-Manager UI

To conclude, I believe the single point here was the file *ifcfg-<interface name>*, for any reason *I didn't check the code / flow* this file is blocking the ncftool and virsh to see/reach the bridge.

Appreciate all your help guys.

Hello team

Just one more information, after restart this machine again, I was not possible to see the bridge via virt-manager UI then I come back to the debug and on script dir still one file, according below

// cat ifcfg-Wired_connection_1 
---
HWADDR=B8:AC:6F:E7:ED:81
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME="Wired connection 1"
UUID=3113786c-9389-4659-9981-d6a8d22e51c4
ONBOOT=no
IPADDR=192.168.0.251
PREFIX=24
GATEWAY=192.168.0.1
DNS1=8.8.4.4
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
---

As you can see, ONBOOT=no then should not affect, but only after remove this file from the network-scripts and restart all related services again everything come back to normality.

Thank you all.

(netcf doesn't look just at the config files of interfaces that are active, but at all interfaces regardless of whether they are active (or of the setting of ONBOOT), so if the presence of that file caused problems when it had ONBOOT=yes, then behavior wouldn't be changed by changing to ONBOOT=no)

Okay. While I think it would be nice to support different filename vs. device name in all circumstances, the presence of a workaround makes this a low priority, so I'm going to close it as DEFERRED for now.