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 <fr3...@googlemail.com> 写道： > Greetz all > > Same here on gentoo > > Am 12.02.2013 um 11:38 schrieb Gary Kotton <gkot...@redhat.com>: > >> On 02/11/2013 07:26 PM, Greg Chavez wrote: >>> >>> Solution: >>> >>> [root@kvm-cs-sn-10i nova]# modprobe -r brcompat >>> [root@kvm-cs-sn-10i nova]# modprobe bridge >>> [root@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.cha...@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@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
