Bug 605953 - RFE: Add a command to quickly setup a Bridge Networking for KVM
RFE: Add a command to quickly setup a Bridge Networking for KVM
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
: FutureFeature
Depends On:
Blocks: Rhel5KvmTier3 747667 756082
  Show dependency treegraph
 
Reported: 2010-06-19 11:41 EDT by Kirby Zhou
Modified: 2012-06-20 02:23 EDT (History)
17 users (show)

See Also:
Fixed In Version: libvirt-0.9.9-1.el6
Doc Type: Enhancement
Doc Text:
A very common question from users is how to "bridge" one of their host's ethernet devices so that virtual guests can be connected directly to the physical network (rather than through a libvirt virtual network). This RFE adds a simple virsh command to do exactly that. For example: virsh iface-bridge eth0 br0 will create a Linux host-bridge device, attach eth0 to it, and move all IP configuration information from eth0 to br0. You can then connect guests to the br0 interface: <interface type='bridge'> <source bridge='br0'/> </interface> This makes the instructions for using "bridge mode networking" orders of magnitude simpler. There is also an "iface-unbridge" command to revert the interface to its previous un-bridged state.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 02:23:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kirby Zhou 2010-06-19 11:41:37 EDT
Description of problem:

RFE: Add a command to quickly setup a normal Bridge Networking for KVM like xenbr0.

libvirtd depends on network-bridge, but to setup Bridge Networking for KVM is too hardy. Please give us a simple command to do it.


For example:

~]# setup-bridge eth0
ifcfg-eth0 get modified and ifcfg-br@eth0 get created.
The network service automaticly restarted.

~]# setup-bridge -u eth0
ifcfg-eth0 get modified and ifcfg-br@eth0 get removed.
The network service automaticly restarted.
Comment 1 Subhendu Ghosh 2010-10-15 00:24:27 EDT
Moved for RHEL6 feature tracking
Comment 2 brandon theis 2011-02-23 18:55:51 EST
this should also please verify driver support!
Comment 5 Laine Stump 2011-11-28 19:18:50 EST
A command to satisfy this request has been added to virsh in upstream libvirt. It will be included with the next RHEL6 libvirt rebase.

commit 1ae8eed1b4740f1977f05235b47c820c7397e0f9
Author: Laine Stump <laine@laine.org>
Date:   Mon Nov 7 11:15:58 2011 -0500

    virsh: add iface-bridge and iface-unbridge commands
    
    One of the top questions by libvirt users is how to create a host
    bridge device so that guests can be directly on the physical
    network. There are several example documents that explain how to do
    this manually, but following them often results in confusion and
    failure. virt-manager does a good job of creating a bridge based on an
    existing network device, but not everyone wants to use virt-manager.
    
    This patch adds a new command, iface-bridge that makes it just about
    as simple as possible to create a new bridge device based on an
    existing ethernet/vlan/bond device (including associating IP
    configuration with the bridge rather than the now-attached device),
    and start that new bridge up ready for action, eg:
    
        virsh iface-bridge eth0 br0
    
    For symmetry's sake, it also adds a command to remove a device from a
    bridge, restoring the IP config to the now-unattached device:
    
        virsh iface-unbridge br0
    
    During creation of the bridge, it's possible to specify whether or not
    the STP protocol should be started up on the bridge and, if so, how
    many seconds the bridge should squelch traffic from newly added
    devices while learning new topology (defaults are stp='on' and
    delay='0', which seems to usually work best for bridges used in the
    context of libvirt guests).

    There is also an option to not immediately start the bridge (and a
    similar option to not immediately start the un-attached device after
    destroying the bridge. Default is to start the new device, because in
    the case of iface-unbridge not starting is strongly discouraged as it
    will leave the system with no network connectivity on that interface
    (because it's necessary to destroy/undefine the bridge device before
    the unattached device can be defined), and it seemed better to make
    the option for iface-bridge behave consistently.
Comment 6 Kirby Zhou 2011-12-02 04:48:11 EST
Good news
Does 'virsh iface-bridge' do modify scripts inside /etc/sysconfing/ ?
Comment 7 Laine Stump 2011-12-02 05:40:39 EST
virsh iface-bridge uses the virInterface APIs to read the current config of an interface, creates the XML to describe a similar bridged interface, and writes that info back. The files modified will be /etc/sysconfig/network-scripts/ifcfg-($ethdevice|$brdevice).
Comment 9 zhpeng 2012-01-09 22:43:29 EST
Test it with:
libvirt-0.9.9-1.el6.x86_64

Steps:

virsh # iface-bridge em1 br0 --no-stp
Created bridge em1 with attached device br0
Bridge interface br0 started

virsh # iface-unbridge  br0
Device em1 un-attached from bridge br0
Interface em1 started

network profile:
ifcfg-em1:
DEVICE=em1
HWADDR=78:2B:CB:9A:73:9B
ONBOOT=yes
BRIDGE=br0

ifcfg-br0:
DEVICE=br0
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=dhcp
STP=off
DELAY=0


Passed.
Comment 10 Laine Stump 2012-05-08 15:28:51 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
A very common question from users is how to "bridge" one of their host's ethernet devices so that virtual guests can be connected directly to the physical network (rather than through a libvirt virtual network). This RFE adds a simple virsh command to do exactly that. For example:

    virsh iface-bridge eth0 br0

will create a Linux host-bridge device, attach eth0 to it, and move all IP configuration information from eth0 to br0. You can then connect guests to the br0 interface:

   <interface type='bridge'>
      <source bridge='br0'/>
   </interface>

This makes the instructions for using "bridge mode networking" orders of magnitude simpler.

There is also an "iface-unbridge" command to revert the interface to its previous un-bridged state.
Comment 11 Kirby Zhou 2012-05-09 03:14:58 EDT
How about files: /etc/.../route-eth0, rule-eth0 eth0.route ?

(In reply to comment #10)
>     Technical note added. If any revisions are required, please edit the
> "Technical Notes" field
>     accordingly. All revisions will be proofread by the Engineering Content
> Services team.
> 
>     New Contents:
> A very common question from users is how to "bridge" one of their host's
> ethernet devices so that virtual guests can be connected directly to the
> physical network (rather than through a libvirt virtual network). This RFE adds
> a simple virsh command to do exactly that. For example:
> 
>     virsh iface-bridge eth0 br0
> 
> will create a Linux host-bridge device, attach eth0 to it, and move all IP
> configuration information from eth0 to br0. You can then connect guests to the
> br0 interface:
> 
>    <interface type='bridge'>
>       <source bridge='br0'/>
>    </interface>
> 
> This makes the instructions for using "bridge mode networking" orders of
> magnitude simpler.
> 
> There is also an "iface-unbridge" command to revert the interface to its
> previous un-bridged state.
Comment 13 errata-xmlrpc 2012-06-20 02:23:30 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0748.html

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