[Openstack-operators] Migration from openvswitch to linuxbridge

Mathieu Gagné mgagne at iweb.com
Tue Sep 30 16:36:44 UTC 2014


Hi,

Unfortunately (or fortunately depending on your POV), I never migrated 
from OVS to linuxbridge as I'm running linuxbridge since day 1.


On 2014-09-30 10:34 AM, Robert van Leeuwen wrote:
> Just wondering:
> Did anyone do a migration from ovs to linuxbridge?

To help people help you:
- Are you running with ML2 plugin + ovs mechanism? (yes according to 
below details)
- Do you have flat, vlan, gre and/or vxlan networks?


> We are considering this due to reducing complexity and improving performance:
> - Fewer moving parts = less that can go wrong
> - We have hypervisores with the ovs eating a significant amount of cpu cycles (more than one cpu core)

=)


> However, it seems that there is more to it then just changing the config on the hypervisors and (hard) rebooting the instances.
>  From what I have gathered there is stuff saved in the databases:
> * neutron - ml2_port_bindings - This seems to be easily updated with some SQL statements.

How about migrating your instances to a new compute node running 
linuxbridge agent instead? Will it update ml2_port_bindings accordingly?


> * nova - instance_info_caches - This looks like it is going to be a problem, the whole network stuff is in here.
> Although it is called cache it does not seem to be updated if you delete the content :(

My only real contribution to your question and sanity is this one:
NEVER truncate that table.

I learned it the hard way. This table is the ONLY place (AFAIK) where 
the nic ordering is persisted (if you care about multi-nics). Neutron 
knows nothing about the nic ordering, you won't be able to rebuild it 
from scratch unless you: go through all compute nodes and manually parse 
the nic order and do voodoo stuff to rebuild the actual table content.

And yes, it looks like Nova rebuild this table content from time to time 
using the *existing* content: it won't rebuild it from scratch if truncated.

-- 
Mathieu



More information about the OpenStack-operators mailing list