On Tue, Aug 25, 2015 at 04:40:29PM -0700, Jesse Gross wrote:
> Flavio, there's been a few reports of compilation problems on
> RHEL/Centos 6. Would it be possible for you to take a look?
Yup, I will look into this.
fbl
>
> On Fri, Aug 21, 2015 at 12:09 PM, Gurucharan Shetty
> wrote:
> > Okay,
K, tracked it down to neutron/agent/common/ovs_lib.py:151
Datapath_type has a default value of OVS_DATAPATH_SYSTEM. I'm guessing
somewhere someone created an instance of the object without passing in the
datapath_type variable from config.
Anyway, changing that to OVS_DATAPATH_NETDEV got rid o
My guess would be the neutron ovs agent is changing it back but im not sure why.
My dev environment has been tied up with trying to reproduce a live migrating
bug to the last two days.
I will try to restack my compute node tomorrow and dig into this more then.
-Original Message-
From:
Interesting... it seems that the ovs-vsctl set bridge br-int
datapath_type=netdev does take, but very soon after it is changed back to
system. I'll try and figure out how that is happening.
Gabe
> -Original Message-
> From: Gabe Black
> Sent: Wednesday, August 26, 2015 12:42 PM
> To: '
Hi Sean,
Yes, I did have the OVS_DATAPATH_TYPE set to netdev. Even after setting the
[ovs] datapath_type=netdev and trying to manually set the datapath_type to
netdev (ovs-vsctl set Bridge br-int datapath_type=netdev), the br-int still
shows system.
The interesting thing is that the other bri
We don't have the schedule yet, since we're still accepting talk proposals:
http://openvswitch.org/pipermail/announce/2015-August/76.html
Those are just possible subject areas for proposals. I imagine that we'll have
the final schedule uploaded by the end of September.
--Justin
>
Hello all,
I was watching last year conference videos on YouTube and I noticed
that the speakers last year presented specific topics but the topics stated
this year are not that meticulous. Were the topics stated last year specific to
a high extent? or, should the speaker’s presenta
Hi Daya,
BFD operates on top of any data protocol (network layer, link
layer, tunnels(vxlan tunnel), etc.) being forwarded between two systems. BFD
provides failure detection on direct physical links, virtual circuits,
tunnels(vxlan tunnel) etc. If BFD is run over a VXLAN tunnel
I have followed the getting started guide
(http://git.openstack.org/cgit/stackforge/networking-ovs-dpdk/tree/doc/source/getstarted.rst)
on both fedora 21 and Ubuntu 15.04 to get a single-node set up with dpdk ovs.
My local.conf file is identical to the one provided as the single node
template:
thanks ravi and alex! ravi, alex has also confirmed that the pkts are vxlan
encapsulated, outer IP would have to be the TEP IP, and inner IP is immaterial
since the slow path at the receiver would essentially ignore it.
thanks!daya
From: "ravi_sabapa...@dell.com"
To: day...@yahoo.com; dis
Hi All,
Thanks all for suggestion. What turns out the issue is openvswitch upstart
process kicked too early before networking service is fully started. Once I
changed the condition of openvswitch upstart process to "stopped networking" no
looping is seen anymore.
Not openvswitch issue but some w
After creating a user space ovs bridge, and assign an valid ip address
after the "internal" bridge name, then add a physical interface, e.g.
ens806f1 to the bridge. Ping the internal bridge ip address from the
other host will work ok.
But once I prevent all the packets reaching ens806f1 by ipt
I know the feeling. I think your horizon issue can be fixed by
Running
sudo iptables -F
sudo iptables -X
iptables based security groups do not work with vhost-user so this will have no
effect on vm security
I think the ovs-ofctl: br-int is not a bridge or a socket error is because the
datapath
13 matches
Mail list logo
