← Back to team overview

openstack team mailing list archive

Re: openstack brctl addbr not supported on RHEL 6.3

 

On my install of RHEL 6.3 I have CONFIG_BRIDGE=m and it appears to
work just fine.

Although RHEL discussions are completely off topic on a Fedora mailing
list. You should open a support case if you're having issues with
RHEL.

Peter

On Mon, Feb 11, 2013 at 4:58 PM, Pádraig Brady <P@xxxxxxxxxxxxxx> wrote:
> A quick search suggests that kernel has CONFIG_BRIDGE=n set.
> So I presume there another method is possible through config.
> Gary any ideas?
>
> On 02/11/2013 04:33 PM, Greg Chavez wrote:
>>
>>
>> Running latest EPEL Folsom packages on RHEL 6.3.  Three nodes right now,
>> one controller, one network node, one compute node.  The network node has
>> three NICs, one for external net, one for management net, one for VM network
>> traffic.  It has been a miserable journey so far.
>>
>> The lastest calamity began with a failed spawn of the Cirros test image.
>> I booted it like this:
>>
>> # nova --os-username demo --os-password demo --os-tenant-name demoProject
>> boot --image aefa581f-47b0-4d46-8dbc-1a1f7f02dfa0 --flavor 2  --nic
>> net-id=3de1e780-07d1-42af-89cc-0feaf1ece6e9 server-01
>>
>> This succeeded but went directly into an ERROR state.  The compute node's
>> /var/log/nova/compute.log showed this:
>>
>> ProcessExecutionError: Unexpected error while running command.
>> Command: sudo nova-rootwrap /etc/nova/rootwrap.conf brctl addbr
>> qbr2218b8c4-7d
>> Exit code: 1
>> Stdout: ''
>> Stderr: 'add bridge failed: Package not installed\n'
>>
>> Hrm.  So then I ran this:
>>
>> # brctl show
>> bridge namebridge idSTP enabledinterfaces
>> br-eth1/sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> /sys/class/net/br-eth1/bridge: No such file or directory
>> 0000.bc305befedd1no
>> br-int/sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> /sys/class/net/br-int/bridge: No such file or directory
>> 0000.7e1636f42c4bno
>>
>> GAH!   What!!! First of all, bridge capability is set by default in the
>> RHEL 6.3 kernel.  Secondly, nova knows that it's supposed to be using
>> openvswitch.  The ProcessExecutionError's trace showed that the offending
>> code came from /usr/lib/python2.6/site-packages/nova/virt/libvirt/vif.py
>> line 216 which has this comment:
>>
>>      def plug(self, instance, vif):
>>          """Plug using hybrid strategy
>>
>>          Create a per-VIF linux bridge, then link that bridge to the OVS
>>          integration bridge via a veth device, setting up the other end
>>          of the veth device just like a normal OVS port.  Then boot the
>>          VIF on the linux bridge using standard libvirt mechanisms
>>          """
>>
>> Thirdly, ovs-vsctrl is happy:
>>
>> # ovs-vsctl show
>> 44435595-8cc8-469c-ace4-ded76a7b864d
>>      Bridge "br-eth1"
>>          Port "br-eth1"
>>              Interface "br-eth1"
>>                  type: internal
>>          Port "phy-br-eth1"
>>              Interface "phy-br-eth1"
>>          Port "eth1"
>>              Interface "eth1"
>>      Bridge br-int
>>          Port "int-br-eth1"
>>              Interface "int-br-eth1"
>>          Port br-int
>>              Interface br-int
>>                  type: internal
>>      ovs_version: "1.7.3"
>>
>> Final note, my network node fails the same way, but the controller does
>> not.
>>
>> I hope so much that somebody knows what is going on here.  This is very
>> terrible for me as I am struggling to achieve minimal functionality.
>> Thanks.
>
> _______________________________________________
> cloud mailing list
> cloud@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/cloud


References