RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1060317 - Creating a bridge results in an error
Summary: Creating a bridge results in an error
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: netcf
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-31 18:55 UTC by Prarit Bhargava
Modified: 2014-06-18 08:36 UTC (History)
7 users (show)

Fixed In Version: netcf-0.2.3-8.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 11:31:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Prarit Bhargava 2014-01-31 18:55:38 UTC 
Description of problem: When creating a bridge the following an error is displayed.


Version-Release number of selected component (if applicable): virt-manager-0.10.0-11


How reproducible: 100%


Steps to Reproduce:

Install system
yum groupinstall gnome
yum install tigervnc-server

reboot

Start a root vncserver (execute "vncserver")

Start virt-manager (through menu)
Edit->Connection Details
Network Interfaces
Add Interface
Create inteface "praritbr0", Start mode: onboot, activate now.


Actual results:
Error creating interface: 'Could not create interface: internal error: failed to create (start) interface praritbr0: failed to execute external program - Running 'ifup praritbr0' failed with exit code 1: ERROR    : [/etc/sysconfig/network-scripts/ifup-eth] Bridge support not available: brctl not found


Expected results:

Traceback (most recent call last):
          File "/usr/share/virt-manager/virtManager/asyncjob.py", line 100, in cb_wrapper
              callback(asyncjob, *args, **kwargs)
            File "/usr/share/virt-manager/virtManager/createinterface.py", line 1134, in do_install
              self.interface.install(meter, create=activate)
            File "/usr/share/virt-manager/virtinst/Interface.py", line 258, in install
              raise RuntimeError(errmsg)
          RuntimeError: Could not create interface: internal error: failed to create (start) interface praritbr0: failed to execute external program - Running 'ifup praritbr0' failed with exit code 1: ERROR    : [/etc/sysconfig/network-scripts/ifup-eth] Bridge support not available: brctl not found

Additional info: I think virt-manager should have a dependency on bridge-utils.
Comment 2 Giuseppe Scrivano 2014-02-03 14:32:13 UTC 
the error seems to be raised by libvirt, thereby I reassign there.
Comment 3 Jiri Denemark 2014-02-03 15:07:00 UTC 
The error message seems to be pretty clear and coming from ifup, not libvirt... brctl command could not be found, which means the system is not able to create bridge interfaces. Just install bridge-utils on the host.
Comment 4 Prarit Bhargava 2014-02-03 15:40:39 UTC 
(In reply to Jiri Denemark from comment #3)
> The error message seems to be pretty clear and coming from ifup, not
> libvirt... brctl command could not be found, which means the system is not
> able to create bridge interfaces. Just install bridge-utils on the host.

I'm embarrassed by this answer and you should be too.

This _IS_ a bug.  I've followed valid steps in creating a guest and I am not able to.  The reality is that functionality expected in virt-manager is NOT working; I am unable to create a bridge after doing

yum -y install virt-manager.

I do not know enough about virt-manager to know if it calls brctl commands directly (which means that this is a broken virt-manager dependency), or if virt-manager is calling into libvirt which then calls brctl (which means that this is a broken libvirt dependency).

Either way, closing this out as NOTABUG is wrong.  

The steps to reproduce this are TRIVIAL:

1.  Install RHEL7
2.  yum -y install virt-manager
3.  Attempt to install a RHEL6.5 guest.

This does not work.  And that is a bug.  Feel free to assign it to someone else, but closing this out is the wrong answer.

/me thinks either libvirt or virt-manager...
Comment 5 Jiri Denemark 2014-02-03 19:31:09 UTC 
My answer was probably too short but I don't think it was wrong... it's a bit more complicated. Virt-manager does not have to be run on the same host where domains are created so it should only depend on libvirt-client so that it is able to talk to libvirtd. Libvirt itself does not normally need bridge-utils either as bridges created for libvirt's virtual network are created by libvirt talking to the kernel directly. Only when done through the interface driver (in virt-manager this is mapped to connection details -> network interfaces) libvirt will use bridge-utils but not directly. Libvirt will just pass the XML description of the interface to netcf, which is a library for editing network configuration files found in /etc/sysconfig/network-scripts. The end point which may actually run brctl depending on interface configuration is /usr/sbin/ifup from initscripts. Neither libvirt nor netcf don't even know brctl will be used as it is an implementation detail of ifup when it is asked to create a bridge. Requiring bridge-utils in any layer above ifup would not be correct since ifup can decide to use different tool at any time just like it switched from using ifconfig to ip. But should initscripts depend on every single binary that can possibly be used as a result of some network configuration? I don't think so.

Similarly to why initscripts do not depend on bridge-utils because it may not be needed at all depending on configuration and because it's presence can be checked in runtime and an error can be reported when a configuration that requires it is used, libvirt does not depend on, e.g., libvirt-login-shell, libvirt-lock-sanlock, or mounted cgroups. If any of these parts are missing, the functionality depending on them would not work and an error would be reported.

BTW, after "yum install virt-manager" you won't be able to create any guest on your local machine unless you explicitly installed libvirt-daemon-kvm and possibly several other packages because there won't be any libvirtd to connect to. And installing any guest using virt-manager does not require bridge-utils by default because virt-manager will make use of virtual networks provided by libvirt (and implemented without bridge-utils).
Comment 6 Prarit Bhargava 2014-02-03 19:37:47 UTC 
Fair enough, how 'bout this then?

When you install virt-manager and open it for the first time, a warning is displayed indicating that  libvirt-daemon-config-network needs to be installed.  Why not put out a similar warning if the bridge option is specified in the network interfaces tab?

Also, Cole pointed me to https://bugzilla.redhat.com/show_bug.cgi?id=911403.

P.
Comment 7 Prarit Bhargava 2014-02-03 19:41:47 UTC 
Or if you don't want to do that, why not add bridge-utils to the Virtualization install group?

P.
Comment 8 Jiri Denemark 2014-02-05 13:55:41 UTC 
Oh, I didn't know virt-manager already had a warning for libvirt-daemon-config-network. I guess it could make sense to add another one for bridge-utils. Let's move the bug back to virt-manager and see if they are going to add it or if netcf is going to depend on bridge-utils or whatever.
Comment 9 Giuseppe Scrivano 2014-02-07 12:21:29 UTC 
I don't think virt-manager should depend from anything that is not used directly by it (like libvirt) or suggest qemu.  In any case it looks like a minor issue that we can defer to 7.1
Comment 10 Prarit Bhargava 2014-02-07 12:35:40 UTC 
(In reply to Giuseppe Scrivano from comment #9)
> I don't think virt-manager should depend from anything that is not used
> directly by it (like libvirt) or suggest qemu.  In any case it looks like a
> minor issue that we can defer to 7.1

Giuseppe,

1.  Install RHEL7.
2.  yum install virt-manager libvirt libvirt-python python-virtinst libvirt-client
3.  Attempt to install a RHEL6 guest.

That does not work.  Supported features in virt-manager are not working:

Documentation on installing RHEL7 virt packages on top of an existing RHEL7 install:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Virtualization_Deployment_and_Administration_Guide/sect-Virtualization_Host_Configuration_and_Guest_Installation_Guide-Host_Installation-Installing_KVM_packages_on_an_existing_Red_Hat_Enterprise_Linux_system.html


See instructions here on installing guest.  Pay special attention to figure 6.7:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Virtualization_Deployment_and_Administration_Guide/chap-Virtualization_Host_Configuration_and_Guest_Installation_Guide-Guest_Installation_Virt_Manager-Creating_guests_with_virt_manager.html

*Deferring this to 7.1 is the wrong thing to do.*

P.
Comment 11 Laine Stump 2014-02-07 13:36:34 UTC 
This is the same issue as raised against Fedora in Bug 911403
Comment 12 Laine Stump 2014-02-07 15:12:49 UTC 
I've added a Requires: bridge-utils to netcf upstream:

commit 5bb22ec48096338a6651590299740f9e42367bb9
Author: Laine Stump <laine>
Date:   Fri Feb 7 16:17:24 2014 +0200

    Require bridge-utils for netcf-libs in the specfile

    netcf itself doesn't use anything in bridge-utils, but it called
    /sbin/ifup, which *can* run brctl (which is part of bridge-utils).
    Technically, initscripts should require brutils (since /sbin/ifup is a
    part of initscripts), but we all know that's not going to
    happen. Instead we can just make netcf require bridge-utils. It's not
    a very large package, so it's unlikely we'll get any complaints about
    bloat.
    
    (NB: in the past, libvirt had a Requires: bridge-utils, so this didn't
    used to be a problem. libvirt removed this Requires: in v0.9.8, when
    it switched from execing brctl to directly calling ioctls to create
    and manage bridge devices.)
Comment 13 Laine Stump 2014-02-10 15:21:58 UTC 
To test if the above patch has been applied:

1) yum erase bridge-utils 

(this should remove *only* the bridge-utils package)

2) update to the new netcf-libs package built using the above patch.

(this should automatically pull in the bridge-utils package)

3) yum erase bridge-utils

(this should produce a rather long list of dependent packages that will also be removed, beginning with "netcf-libs" - ANSWER *NO* to the question so that you don't have to reinstall all these packages).
Comment 15 Laine Stump 2014-02-11 11:52:13 UTC 
A fix is available in the following candidate build:

https://brewweb.devel.redhat.com/buildinfo?buildID=334740
Comment 17 Jincheng Miao 2014-02-24 08:55:55 UTC 
According to Laine's test steps (comment 13),  the latest netcf-0.2.3-8.el7 is depended by bridge-utils:

# rpm -q netcf
netcf-0.2.3-7.el7

# yum erase bridge-utils
Loaded plugins: langpacks, product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Resolving Dependencies
--> Running transaction check
---> Package bridge-utils.x86_64 0:1.5-9.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package             Arch          Version           Repository            Size
================================================================================
Removing:
 bridge-utils        x86_64        1.5-9.el7         @anaconda/7.0         56 k

Transaction Summary
================================================================================
Remove  1 Package

Installed size: 56 k
Is this ok [y/N]: n
Exiting on user command
Your transaction was saved, rerun it with:
 yum load-transaction /tmp/yum_save_tx.2014-02-24.16-38.hfce7r.yumtx


After update netcf to latest version
# rpm -q netcf
netcf-0.2.3-8.el7

# yum erase bridge-utils
Loaded plugins: langpacks, product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Resolving Dependencies
--> Running transaction check
---> Package bridge-utils.x86_64 0:1.5-9.el7 will be erased
--> Processing Dependency: bridge-utils for package: netcf-libs-0.2.3-8.el7.x86_64
--> Running transaction check
---> Package netcf-libs.x86_64 0:0.2.3-8.el7 will be erased
--> Processing Dependency: libnetcf.so.1()(64bit) for package: netcf-0.2.3-8.el7.x86_64
--> Processing Dependency: libnetcf.so.1()(64bit) for package: netcf-devel-0.2.3-8.el7.x86_64
--> Processing Dependency: libnetcf.so.1()(64bit) for package: libvirt-daemon-driver-interface-1.1.1-23.el7.x86_64
--> Processing Dependency: libnetcf.so.1(NETCF_1.0.0)(64bit) for package: netcf-0.2.3-8.el7.x86_64
--> Processing Dependency: libnetcf.so.1(NETCF_1.0.0)(64bit) for package: libvirt-daemon-driver-interface-1.1.1-23.el7.x86_64
--> Processing Dependency: libnetcf.so.1(NETCF_1.2.0)(64bit) for package: netcf-0.2.3-8.el7.x86_64
--> Processing Dependency: libnetcf.so.1(NETCF_1.2.0)(64bit) for package: libvirt-daemon-driver-interface-1.1.1-23.el7.x86_64
--> Processing Dependency: libnetcf.so.1(NETCF_1.3.0)(64bit) for package: libvirt-daemon-driver-interface-1.1.1-23.el7.x86_64
--> Processing Dependency: libnetcf.so.1(NETCF_1.4.0)(64bit) for package: netcf-0.2.3-8.el7.x86_64
--> Processing Dependency: libnetcf.so.1(NETCF_1.4.0)(64bit) for package: libvirt-daemon-driver-interface-1.1.1-23.el7.x86_64
--> Processing Dependency: netcf-libs = 0.2.3-8.el7 for package: netcf-0.2.3-8.el7.x86_64
--> Processing Dependency: netcf-libs = 0.2.3-8.el7 for package: netcf-devel-0.2.3-8.el7.x86_64
--> Processing Dependency: netcf-libs >= 0.2.2 for package: libvirt-daemon-driver-interface-1.1.1-23.el7.x86_64
--> Running transaction check
---> Package libvirt-daemon-driver-interface.x86_64 0:1.1.1-23.el7 will be erased
--> Processing Dependency: libvirt-daemon-driver-interface = 1.1.1-23.el7 for package: libvirt-daemon-lxc-1.1.1-23.el7.x86_64
--> Processing Dependency: libvirt-daemon-driver-interface = 1.1.1-23.el7 for package: libvirt-daemon-kvm-1.1.1-23.el7.x86_64
--> Processing Dependency: libvirt-daemon-driver-interface = 1.1.1-23.el7 for package: libvirt-1.1.1-23.el7.x86_64
---> Package netcf.x86_64 0:0.2.3-8.el7 will be erased
---> Package netcf-devel.x86_64 0:0.2.3-8.el7 will be erased
--> Running transaction check
---> Package libvirt.x86_64 0:1.1.1-23.el7 will be erased
--> Processing Dependency: libvirt for package: virt-who-0.8-12.el7.noarch
---> Package libvirt-daemon-kvm.x86_64 0:1.1.1-23.el7 will be erased
--> Processing Dependency: libvirt-daemon-kvm >= 0.10.2-3 for package: 1:libguestfs-1.22.6-21.el7.x86_64
--> Processing Dependency: libvirt-daemon-kvm for package: gnome-boxes-3.8.3-4.el7.x86_64
---> Package libvirt-daemon-lxc.x86_64 0:1.1.1-23.el7 will be erased
--> Processing Dependency: libvirt-daemon-lxc >= 1.0.2 for package: libvirt-sandbox-libs-0.5.0-9.el7.x86_64
--> Running transaction check
---> Package gnome-boxes.x86_64 0:3.8.3-4.el7 will be erased
---> Package libguestfs.x86_64 1:1.22.6-21.el7 will be erased
---> Package libvirt-sandbox-libs.x86_64 0:0.5.0-9.el7 will be erased
--> Processing Dependency: libvirt-sandbox-1.0.so.4()(64bit) for package: libvirt-sandbox-0.5.0-9.el7.x86_64
--> Processing Dependency: libvirt-sandbox-1.0.so.4(LIBVIRT_SANDBOX_0.2.1)(64bit) for package: libvirt-sandbox-0.5.0-9.el7.x86_64
--> Processing Dependency: libvirt-sandbox-libs = 0.5.0-9.el7 for package: libvirt-sandbox-0.5.0-9.el7.x86_64
---> Package virt-who.noarch 0:0.8-12.el7 will be erased
--> Running transaction check
---> Package libvirt-sandbox.x86_64 0:0.5.0-9.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                          Arch    Version          Repository      Size
================================================================================
Removing:
 bridge-utils                     x86_64  1.5-9.el7        @anaconda/7.0   56 k
Removing for dependencies:
 gnome-boxes                      x86_64  3.8.3-4.el7      @RHEL-Server   4.1 M
 libguestfs                       x86_64  1:1.22.6-21.el7  @anaconda/7.0  3.3 M
 libvirt                          x86_64  1.1.1-23.el7     installed      0.0  
 libvirt-daemon-driver-interface  x86_64  1.1.1-23.el7     installed      102 k
 libvirt-daemon-kvm               x86_64  1.1.1-23.el7     installed      0.0  
 libvirt-daemon-lxc               x86_64  1.1.1-23.el7     installed      0.0  
 libvirt-sandbox                  x86_64  0.5.0-9.el7      @anaconda/7.0  108 k
 libvirt-sandbox-libs             x86_64  0.5.0-9.el7      @anaconda/7.0  1.2 M
 netcf                            x86_64  0.2.3-8.el7      @brewweb        26 k
 netcf-devel                      x86_64  0.2.3-8.el7      @brewweb       8.5 k
 netcf-libs                       x86_64  0.2.3-8.el7      @RHEL-Server   192 k
 virt-who                         noarch  0.8-12.el7       @anaconda/7.0  248 k

Transaction Summary
================================================================================
Remove  1 Package (+12 Dependent packages)

Installed size: 9.2 M
Is this ok [y/N]: n
Exiting on user command
Your transaction was saved, rerun it with:
 yum load-transaction /tmp/yum_save_tx.2014-02-24.16-39.goRXaR.yumtx

This fix is already working, therefore I change the status to VERIFIED.
Comment 18 Ludek Smid 2014-06-13 11:31:40 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.