On 10/27/2011 10:23 PM, Ben Pfaff wrote:
On Wed, Oct 26, 2011 at 01:37:08AM +0200, Hans van Kranenburg wrote:
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!)
I mainly like the ideas behind this approach (I have considered
similar approaches before), but there are some difficulties.
A technical difficulty is that OVS installs many files under /usr, but
the Filesystem Hierarchy Standard that Linux distributions follow says
that /usr is supposed to be shareable, that is, it should be possible
for a number of machines to mount it from a network share. This means
that files in /usr must not be needed to mount a network share.
Hence, OVS must not put anything in /usr. Fine; we could move files
elsewhere.
I see. That's why ovs is started after networking now.
This solution raises an organizational difficulty: /bin, /sbin, /lib,
etc. are supposed to be reserved for programs essential to booting
only. I have not yet felt up to the task of arguing that
ovs-vswitchd, ovsdb-server, ovs-dpctl, and so on in fact fall into
this category. Maybe it would not be a difficult hurdle to cross, or
maybe it would be, but I haven't done it yet.
I would not advocate this. Trying to remove this dependency by forcing
all ovs files into local filesystems (somewhat violating the FHS) feels
like the wrong way to fix things.
A possible way could be to introduce a separation of 'early' and 'later'
setup of networking devices. That way you could:
- configure non-ovs network devices
- mount remote fs
- start ovs
- configure ovs network devices
In case you'd want to support a configuration where /usr is mounted over
a network interface which is provided by ovs... well... hmm... nasty...
or just label it 'Do not want, insane, not supported'.
This would be a situation like:
- cryptdisks-early/cryptdisks to deal with encrypted volumes which
contain lvm volume groups or lvm logical volumes which contain encrypted
volumes (doing this right in a simple, clean way seems to be difficult)
- the various mount-scripts in /etc/init.d, which address issues like
these.
But... this would require a rather big change in the networking packages
and init scripts in Debian (what will the 'auto' definition on a network
interface mean, etc...), only to facilitate the OVS project. (I do not
know of other scenario's which would benefit of this, but maybe someone
can come up with one?)
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.
Please feel free to ask him. You can CC me or ovs-discuss, if you
like. Thank you for raising these issues.
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.
Important argument for this is that you can do pre-down (possibly
shutting down other stuff before the network link goes down), which is a
very useful thing which AFAIK cannot be done with the udev hooks I tried
before.
Sysops can define the configuration of the interfaces in
/etc/network/interfaces and can optionally make use of the if*.d
facilities ifupdown provides to execute scripts provided by other packages.
Interfaces whose configuration are triggered by ovs must not have the
'auto' declaration in /etc/network/interfaces. This could be confusing
for users.
Anyway... let's do another step of discussion and then try to see if we
can present some sane idea to the Debian networking folks.
--
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
