[ovs-discuss] Open-vswitch network configuration on Debian

Ben Pfaff blp at nicira.com
Mon Oct 31 19:38:32 UTC 2011

On Fri, Oct 28, 2011 at 01:21:39AM +0200, Hans van Kranenburg wrote:
> An ovs-only solution could be to facilitate an init-script that
> calls ifup for all interfaces that are added by ovs during boot, and
> calls ifdown for them before shutting down ovs. Or even not a
> separate init-script, but this could be a (debian-only?) option in
> OVS saying: "should I call ifup and ifdown for you when
> adding/removing interfaces?" This way (by using ifupdown) the ip
> addresses and other fancy things can be defined in
> /etc/network/interfaces as usual. OVS knows which interfaces it adds
> to the system during boot, so it could be zero-configuration.

This is interesting.  As a generalization, one could add a set of
scripts that ovs-vswitchd invokes before and after it creates an
interface and before and after it removes one.

Some issues that come to mind:

	* We generally don't allow the database to specify full names
          of commands to run, files to create, etc., because
          ovs-vswitchd runs as root and we don't want database users
          to necessarily have root privilege.  So we'd probably just
          to have to choose some "standard" script names and pass the
          interface name as an argument.

	* So far, we've been talking about ovs-vswitchd startup, but
          OVS can create and destroy network devices (and other kinds
          of vports) at other times, too.  I guess that we'd want
          these scripts to run whenever OVS does this, not just at
          startup, but we'd have to think about that.

	* I'm not quite sure what should happen on OVS restart
          (if someone kills and restarts the daemon).  I guess it
          should only run the script if it has to actually create the
          device.  There'd be a race, though: if ovs-vswitchd creates
          the device and then someone kills it before it runs the
          script, then on restart it wouldn't run the script.
          Probably we can ignore this race, but I thought I'd mention
          it anyway.  Alternatively we could *always* run all the
          scripts on startup, in which case the scripts would have to
          be designed to be idempotent.

	* If we want these scripts to run at shutdown, I guess we'd
          have to actually delete the interfaces.

Any further thoughts?

More information about the discuss mailing list