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 _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
