Created my bridge and my ports:
ovs-vsctl add-br ovsbr0
for i in {0…24}
do
ovs-vsctl add-port ovsbr0 port${i} – set Interface port${i} type=internal
done
No errors and ovs-vsctl show showed everything as fine.
for i in {0…24}
do
echo STARTMODE=‘auto’ > ifcfg-port${i}
echo BOOTPROTO=‘none’ >>ifcfg-port${i}
done
Performed ifup all connected my KVM VM systems to the ports and everything worked (e.g. ssh, ping, etc.).
When I reboot the bridge and ports are not there. Running this again re-creates them fine:
ovs-vsctl add-br ovsbr0
for i in {0…24}
do
ovs-vsctl add-port ovsbr0 port${i} – set Interface port${i} type=internal
done
ifup all
Am I missing a step to preserve the database? I could not find anything in the openvswitch documentation.
Although I haven’t done this myself personally,
To my eye,
the following is possibly faulty because although you assigned to a bridge device, you didn’t specify an interface like what is described in the referenced openvswitch portal (which should probably be renamed as a SDB, portals I usually see don’t get into the technical stuff)
ovs-vsctl add-br ovsbr0
for i in {0..24}
do
ovs-vsctl add-port ovsbr0 port${i} -- set Interface port${i} type=internal
done
Although it’s cool to set your ports programmaticly, it might be more clear for “only” 25 ports to just use repetitive statements for sureness (You can also modify to use programming after you’re sure your config works)
openvswitch has a backend database. Since my configuration works with no errors or complaints when setting it up and when querying the database I assume the schema is correct. Yet the database retains no data after reboot.
You can probably test your assumption that the settings aren’t in your database by restarting the wicked service (which is described as a working alternative to rebooting).
I’m assuming that the openvswich configuration doesn’t somehow exist in memory during your User session, so restarting the wicked service should read the configuration from the openvswitch database and in so doing verify your database contain your settings.
After a reboot,
You can also try invoking openvswitch without re-creating your configuration(eg systemctl restart openvswitch) which can further indicate whether your database contains your settings.
If in the end you can’t find a solution, creating network settings and objects like this is fairly commonly done by invoking with lines in /etc/sysctl.conf. If you end up doing this, I recommend you read related blogs and MAN pages, I also used this method for modifying TCP/IP stack settings in an article I wrote long ago
Curious,
If your openvswitch is not working, is the service running?
Especially if the service is not running, you may want to view the journal snippet in
systemctl status openvswitch.service
And, although I’d presume that openvswitch.service cannot start without the following perhaps they should be checked as well
systemctl status ovsdb-server.service
systemctl status ovs-vswitchd.service
Thanks, those are great troubleshooting suggestions. The /etc/sysctl.conf is certainly an option and easily done. I just hate when things don’t work as designed
Yes all services are running. My apologies for leaving it out of the post. My original contained that information, but somehow I messed up in posting it.
Thank you very much for your help so far. I definitely have a timing issue between the openvswitch.service and the network.service.
If I set the bridge and ports up as I originally did and do not reboot they function as they should.
If I go into yast and disable wicked, reboot, login and check my openvswitch database everything has been saved. Restarting wicked in yast brings the system back online and openvswitch works as I have configured it.
Not disabling wicked before a reboot clears/empties/corrupts the openvswitch database.
I would much rather somehow place a pause between the two services and have a longer boot process than have to disable and re-enable wicked. Otherwise, when the system requires a hard reset I am again having to reconfigure openvswitch.
Any suggestions? I am surprised no one else has run across this issue. i would think docker would utilize this although possibly they are moving the openvswitch part into userspace with DPDK and do not have the same issues.
Openswitch database is automatically preserved, this is specific issue of interaction with wicked. Wicked creates OVS bridges dynamically during ifup and destroys them during ifdown. On sytsem shutdown during network stop ifdown for all interfaces is performed which removes bridge.
Wicked can handle only very limited subset of OVS features - it can only setup bridges on top of existing physical interfaces, it cannot create virtual ports.
Your only workaround is to set STARTMODE=nfsroot for bridge device. Note that this will completely disable ifdown for this interface, even manually. Apparently current wicked also supports --no-delete option on interface which may help in this case although I am not sure whether it is possible to mark bridge as “no delete” in configuration.
Another big hammer is to simply disable ExecStop action of wicked.service thus leaving network running. This means someone may still accidentally run “ifdown ovsbridge” removing it from OVS database.
Requires is orthogonal to After; one cannot “substitute” another. You apparently did not even attempt to read your link yourself.
Thank you very much for this response. It at least confirms that I am not crazy. Since I am actually working in a development, and not a production environment I am beginning to think the easier route is to just script the build of the bridge and internal ports each time before spinning up the virtual environment. I will admit that my background is in large enterprise architecture and I started this thread to determine if I was seeing a bug since I couldn’t find anything on this in the documentation or through searches. Your answer helps me accept that this is at least an understandable occurrence, and why I am seeing it. I seem to be good at finding eclectic issues.
As I answered in another discussion, IMHO without OVS_BRIDGE=yes wicked should not destroy bridge on ifdown. In my testing it still did.
Second topic for bug report is documentation - the behavior is absolutely unclear after reading manual page. A better explanation what OVS_BRIDGE actually does would certainly be helpful.
