On 10/24/2011 08:20 PM, Ben Pfaff wrote:
On Sat, Oct 22, 2011 at 10:50:11PM +0200, Hans van Kranenburg wrote:
On 10/22/2011 01:54 AM, Ben Pfaff wrote:
On Thu, Oct 20, 2011 at 01:08:57PM +0200, Frank wrote:
Is there a good way to with some kind of hook to add ip addresses to
interfaces defined via ovs-vsctl and set interfaces links up?
One way to do it would be to add a init script to run after
openvswitch-switch.
udev is another way.
I'm sure that there are still other ways, too.
I see openvswitch does not store/remember ip addressing, (default)
route and interface administrative link states (up/down) in it's
conf.db. This is by design, I suppose. When configuring a physical
switch, you generally assign an ip address and default route to the
management vlan on the switch for administrative access. Why doesn't
ovs support this? Or am I missing something obvious?
I'm not entirely against doing something like this, but there are some
reasons why it isn't implemented.
First, we haven't yet internally had a use case for it.
Second, I'm concerned about synchronization issues. For most
configuration in its database, OVS carefully applies that
configuration at startup, and then reapplies it whenever the database
changes. That would cause any manual administrator changes (with
e.g. "ifconfig") to be wiped out. That sounds like a huge problem to
me, because I don't think administrators really want to have to do all
their network configuration through ovs-vsctl or risk having it lost.
Third, it's easy enough to configure link states and IP addresses, but
the Linux network stack has tons of other state. I don't really want
to get in a situation where OVS has to understand how to configure
every bit of that state. It might easily be a slippery slope.
This makes so much sense, that I already won't ever dare to ask again
about implementing this functionality. I've been thinking about this for
the past few days, and right now I think copying network configuration
into ovs really would be a badly misplaced useless extra level of
abstraction. The feeling I have about this is the same feeling as I have
about firewall tools that implement an abstraction of the iptables
ruleset syntax, always providing you with an immediate dead-end road,
unless reimplementing the feature set completely, which would make them
superfluous again. (Yes, this is exactly the same feeling I have about
the ifup/ifdown abstraction, and the reason I'm abusing the up/down
hooks to do all configuration directly with the iproute2 commands or any
other things I want to do instead of using the native debian
/etc/network/interfaces syntax (see example Frank provided in the first
post of this thread))
So...
Perhaps it's best to consider the devices set up by ovs at boot time
equal to the nics that are physically present in a server. Using this
approach, I can just say "Yay, I have a switch built in to my server
where I can plug in virtual machines!" (as if it were a physical
hardware thing). Seems rather like a way of thinking you did want to
achieve with this project anyway. ;]
- Basic configuration of the switch takes place at the time I install
my (e.g. Xen dom0) server. (yes, I can make changes later)
- OVS makes sure it will restore the configured setup when I reboot
the machine.
- I can just use the 'normal' way of setting up links and configuring
ip addresses and network routing using the ifupdown tools. Although it's
not perfect, until now I've been able to perfectly abuse ifupdown and
its hooks to do everything I wanted to do to set up and tear down
interface configuration. (Note: this will *require* the 'networking'
init script to be run *after* ovs sets up the devices!)
Voila. So I think the init-script reordering would be the best option in
this case. Best, as in... one of the most clear ways to communicate this
behaviour to a huge installed user-base already using the ifupdown
tools: "Just consider ovs as putting some extra hardware into your
machines, which you can use like it were real physical devices, just
like eth0 and eth1."
Setting up OVS devices *before* /etc/init.d/networking is run on Debian
would provide this behaviour.
The current opposite situation leads to questions like I tried to answer
with the udev experiments etc I described. It's just the wrong order of
doing things. When you want to do this right, you really will need
pre-up/up/post-up/pre-down/down/post-down hooks, which udev hooks do not
provide, etc.. etc..
I'm curious about your response to these thoughts.
I'd also like, (I you agree) to ask the current maintainer of ifupdown
in Debian (newsflash! someone is actually putting effort into ifupdown
in Debian right now!) about his thoughts about these issues.
Note: I'm still very new to ovs itself, and I'm talking from the
background of just starting to implement ovs to replace bridging/vlans
on a Xen dom0 using a system with as most as possible pure Debian
packages installed (which can be cherry-picked backports from testing if
they're official ovs releases).
We still need to free up some extra test hardware to start testing with
ovs for starting Xen domU's and attaching them to a properly configured
dom0 setup. (one of the main things here is that I want to write a
changed vif-ovs script that properly sets up a 'trunked' vif to a domU
instead of multiple vifs with untagged vlans on it)
--
Hans van Kranenburg - System / Network Engineer
T +31 (0)10 2760434 | hans.van.kranenb...@mendix.com | www.mendix.com
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
