[Openstack] brctl meltdown on RHEL 6.3

vvdbzhi atkisc at gmail.com
Wed Feb 13 02:56:48 UTC 2013


Before a found this problem, it is said that is rhel (centos) 6.3 does not support the openvswitch brcompat module and bridge module used at the same time

在 2013-2-13,上午10:08,Fr34k8 <fr34k8 at googlemail.com> 写道:

> Greetz all
> 
> Same here on gentoo
> 
> Am 12.02.2013 um 11:38 schrieb Gary Kotton <gkotton at redhat.com>:
> 
>> On 02/11/2013 07:26 PM, Greg Chavez wrote:
>>> 
>>> Solution:
>>> 
>>> [root at kvm-cs-sn-10i nova]# modprobe -r brcompat
>>> [root at kvm-cs-sn-10i nova]# modprobe bridge
>>> [root at kvm-cs-sn-10i nova]# brctl show
>>> bridge name bridge id STP enabled interfaces
>>> 
>>> Still can't boot a VM... looking into the reasons now.
>> 
>> Could this be related to SELinux. Can you please look at the nova-compute logfile - /var/log/nova/compute.log.
>> Thanks
>> Gary
>> 
>>> 
>>> 
>>> On Mon, Feb 11, 2013 at 11:33 AM, Greg Chavez <greg.chavez at gmail.com> 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 name bridge id STP enabled interfaces
>>> 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.bc305befedd1
>>>                   no 
>>> 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.7e1636f42c4b
>>>                   no
>>> 
>>> 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.
>>> 
>>> -- 
>>> \*..+.-
>>> --Greg Chavez
>>> +//..;};
>>> 
>>> 
>>> 
>>> -- 
>>> \*..+.-
>>> --Greg Chavez
>>> +//..;};
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130213/9f93a572/attachment.html>


More information about the Openstack mailing list