If DHCP is in use, then the physical devices have to be up before we
configure the local port, otherwise the DHCP request will never hit the
wire and we have no hope of getting an IP address.
This problem has been here for a long time, but it was masked until
commit c170afc1 "xenserver: Really take devices down in
interface-reconfigure." actually caused devices to go down and stay down.
Fixes bug #1809 "vswitch upgrade broke the xenserver".
We previously required that brcompat_mod be loaded before any datapaths
were created, because creation and destruction of datapaths and ports
differed when brcompat_mod was loaded, but the latter is no longer the
case so there is no reason for the former anymore.
Citrix QA scripts expect that "brctl show" shows a bond interface for each
bond that is added to a bridge. The only way to do that without modifying
brctl itself is to create an actual network device by that name, so this
commit adds a new bonding configuration key that causes an internal
device by the name of the bond to be created.
This feature is also necessary, but not sufficient, to allow XenCenter to
accurately show the link status and statistics of bridges (bug #1363).
This new configuration key is intentionally undocumented, because I don't
want anyone to use it.
Bug NIC-19.
The Citrix QA scripts assume that "brctl show" will show a topology as if
the Linux bridge were still in use; that is, as if there were one bridge
per VLAN and as if bonds were network devices of their own instead of
separate devices. However, we were showing the datapath topology, i.e.
all VLANs and bond devices lumped together into a single datapath. This
commit fixes the VLAN end of the problem, by moving the implementation of
the ioctls that brctl uses into userspace in ovs-brcompatd and putting the
necessary translation logic into ovs-brcompatd.
By itself, this commit does not fix the problem for bonds: the port name
for a bond does not (normally) under Open vSwitch exist as an actual
Linux network device, and thus it has no ifindex, and so ovs-brcompatd
can't pass it back to the kernel to report to brctl. This fix will have
to wait for another commit.
Bug NIC-19.
handle_fdb_query_cmd() should return an error when an error occurs, but
in this case it was always returning 0, because error is known to have
value 0 at this point.
Nothing really uses the return value here, and so eventually it would make
sense to just change the return type here and in the rest of the
handle_*() functions to void.
Upcoming commits will require sending Netlink messages to the kernel that
have additional attributes. Instead of adding more arguments to
send_reply() to handle these, it's cleaner to break up send_reply() into
two functions and let the caller add those attributes itself.
Originally, the function dp_enumerate() initialized the 'all_dps'
argument. This is inconsistent with most other functions that take an
svec argument, which would only clear the contents. Further, if someone
were not careful when reusing the svec, it could lead to memory leaks.
With this change, the caller is expected to first call svec_init() on
the argument.
The xen-bugtool tool gathers information that may be useful in debugging
problems. This commit modifies that script to add support for vswitch.
Currently, the information we collect is:
- /etc/ovs-vswitchd.conf
- ovs-dpctl show
- Cores in /var/xen/vswitch
- ovs-ofctl show <bridges>
- ovs-ofctl status <bridges>
- ovs-ofctl dump-flows <bridges>
- ovs-dpctl dump-flows <bridges>
This commit also modifies the way cores are handled. They are now
enabled by default and placed in "/var/xen/vswitch".
Feature #1570
The daemon library provides a few short options, but these then take
away their availability from programs that wish to use the library.
Since the daemon options are generally going to be called from a script
(which doesn't care how much typing is involved), we'll only provide
long options.
By default, Open vSwitch daemons change their working directories to the
root directory. This commit provides a --no-chdir option to prevent this
behavior.
XenServer does not rely on Linux to keep the naming of network devices
stable from one boot to the next. Instead, it requires
interface-reconfigure to ensure that network devices are named such that
they have the MAC address specified for the corresponding physical PIF
in the xapi database.
At one point, we fulfilled this requirement by calling out to the Centos
ifup/ifdown scripts, which rename netdevs as necessary to match the
"HWADDR=" lines in /etc/sysconfig/network-scripts/ifcfg-<devname>. When
we rewrote interface-reconfigure not to use those scripts, however, we
accidentally dropped that support. This commit adds back in that renaming.
Bug NIC-20.
When a port's MAC is explicitly specified in the config file, we did not
initialize 'iface' and therefore later we could dereference a wild pointer.
This commit fixes the problem.
update_port() deals with the case where we have been notified that a
network device with a given name, that is part of the datapath, has changed
in some way. In particular it breaks the problem space up into ports that
have been added, deleted, or modified.
But the code here deals badly with the case where the only change is that
the network device associated with a port has been renamed (which is
reported to it with 'devname' as the network device's new named): it
looks up devname in the ofproto's index by name and doesn't find it, then
it looks up the port number assigned to the netdev in the ofproto's index
by datapath index and sees that there already is one. This makes it
think that it's a new port, but with a port number that conflicts with an
existing port (under the old name for the port), which makes it discard
the notification and keep the old netdev name, and so afterward nothing
on the netdev will work since it still has the old netdev name.
This rewrite fixes the problem and simplifies the code.
We create symlinks from /sys/class/net/<bridgename>/brif/<devname> to
/sys/class/net/<devname>/brport, but until now we have never updated the
links when network devices are renamed. This commit fixes this problem.
(Only the <devname> in /sys/class/net/<bridgename>/brif/<devname> needs to
be updated. Symlinks within sysfs have stable targets; that is, no matter
how the object that a sysfs symlink points to moves around, the link is
still maintained correctly.)
Until now, when dp_sysfs_add_if() failed, the caller ignored the failure.
This is a minor problem, because everything else should continue working,
without sysfs entries for the interface, in theory anyhow. In actual
practice, the error exit path of dp_sysfs_add_if() does a kobject_put(),
and that kobject_put() calls release_nbp(), so that the new port gets
freed. The next reference to the new port (usually in an ovs-vswitchd call
to the ODP_PORT_LIST ioctl) will then use the freed data and probably OOPS.
The fix is to make the datapath code, as opposed to the sysfs code,
responsible for creating and destroying the net_bridge_port kobject. The
dp_sysfs_{add,del}_if() functions then just attach and detach the kobject
to sysfs and their cleanup routines no longer need to destroy the kobject
and indeed we don't care whether dp_sysfs_add_if() really succeeds.
This commit also makes the same transformation to the datapath's ifobj,
for consistency.
It is easy to trigger the OOPS fixed by this commit by adding a network
device A to a datapath, then renaming network device A to B, then renaming
network device C to A, then adding A to the datapath. The last attempt to
add A will fail because a file named /sys/class/net/<datapath>/brif/A
already exists from the time that C was added to the datapath under the
name A.
This commit also adds some compatibility infrastructure, because it moves
code out of #ifdef SUPPORT_SYSFS and it otherwise wouldn't build.
The following commit will move the initialization of the datapath and
net_bridge_port kobjects earlier and the destruction later, without
changing when those kobjects are attached to sysfs. To do so, the
initialization of kobjects and attaching to sysfs has to be done as
separate steps. That's already the case for net_bridge_port kobjects, and
this commit makes it so for datapath kobjects too.
This commit also simplifies some code, since the split API exists both
before and after 2.6.25, but the combined functions changed names.
Also, in dp_sysfs_add_if() call kobject_init() after initializing the
kset member, since kobject_init() expects that. This makes no actual
difference in this case since the kobj is obtained from kzalloc(), but
it still seems better.
In the past problems have arisen due to the different ways that datapaths
are created and destroyed in the three different cases:
1. sysfs supported, brcompat_mod loaded.
2. sysfs supported, brcompat_mod not loaded.
3. sysfs not supported.
The brcompat_mod loaded versus not loaded distinction is the stickiest
because we have to do all the calls into brcompat_mod through hook
functions, which in turn causes pressure to keep the number of hook
functions small and well-defined, which makes it really difficult to put
the hook call points at exactly the right place. Witness, for example,
this piece of code in datapath.c:
int dp_del_port(struct net_bridge_port *p)
{
ASSERT_RTNL();
#ifdef SUPPORT_SYSFS
if (p->port_no != ODPP_LOCAL && dp_del_if_hook)
sysfs_remove_link(&p->dp->ifobj, p->dev->name);
#endif
The code inside the #ifdef is logically part of the brcompat_mod sysfs
support, but the author of this code (quite reasonably) didn't want to
add a hook function call there. After all, what would you call the
hook function? There's no obvious name from the dp_del_port() caller's
perspective.
All this argues that sysfs support should be in openvswitch_mod itself,
since it has to be tightly integrated, not bolted on. So this commit
moves it there.
Now, this is not to say that openvswitch_mod should actually be
implementing bridge-compatible sysfs. In the future, it probably should
not be; rather, it should implement something appropriate for Open vSwitch
datapaths instead. But right now we have bridge-compatible sysfs, and so
that's what this commit moves.
When down_netdev was called with deconfigure=True (which is the default),
it would invoke, e.g. "/sbin/ifconfig eth0 down 0.0.0.0", with the
intention of taking the interface down and removing any IP address from it
at the same time.
In fact, this removed any IP address from it and brought the device *up*,
because ifconfig executes its commands in the order that they are
specified, and setting or unsetting an IP address brings a device up.
We could specify the commands in the opposite order ("0.0.0.0 down") but
it seems to me more obviously correct to just run ifconfig twice, so that
is what this commit does.
This commit could break things, because it could be that there is a bug
elsewhere that depends on down_netdev not actually bringing a device down,
but it is needed for the upcoming device renaming commit (to fix bug
NIC-20), because a network device has to be down to be renamed.
Justin reported that adding an internal port to a bridge caused
ovs-vswitchd to log a pair of warnings. This commit suppresses those
warnings, which were harmless.
The datapath has no problems switching jumbo frames (frames with a payload
greater than 1500 bytes), but it has not supported sending and receiving
them to the device itself. With this commit, the MTU can be set as large
as the minimum MTU size of the devices that are directly attached, or 1500
bytes if there are none. This mimics the behavior of the Linux bridge.
Feature #1736
A previous checkin added the cfg_init() function, so we now call it. We
also check the return value of the initial call to cfg_read(), since if
it fails, there's not much point in continuing.
If cfg_* accessor calls were made before cfg_read() was called (or it
returned error), they could cause segfault. This checkin terminates the
cfg structure in such a way that will prevent these run-time problems.
Bug #1693
It was getting to be too confusing to have both netdev_linux_* functions
and linux_netdev_* functions. Rename the latter to make the distinction
more obvious. "rtnetlink" seems to be a fairly good name because that's
what the kernel calls it, so the name will be familiar at least to people
who know about rtnetlink.
This new abstraction layer allows multiple implementations of network
devices in a single running process. This will be useful, for example, to
support network devices that are simulated entirely in the running process
or that communicate with other processes over Unix domain sockets, etc.
The reimplemented tap device support in this commit has not been tested.
For consistency, it's best if every netdev function takes a netdev instead
of a device name. The netdev_nodev_*() functions have always been a bit
ugly.
The netdev_nodev_*() functions have always been a bit of a kluge. It's
better to keep a network device open than to open it every time that it is
needed. This commit converts all of the users of these functions to use
the corresponding functions that take a "struct netdev *" instead.
The netdev_nodev_*() functions have always been a bit of a kluge. It's
better to keep a network device open than to open it every time that it is
needed.
The netdev_nodev_*() functions have always been a bit of a kluge. It's
better to keep a network device open than to open it every time that it is
needed.
Also updates the only user of netdev_find_dev_by_in4().
Two different pieces of code in vswitchd were both iterating over all
the interfaces in a bridge and deleting some of them, then deleting any
ports that ended up with no interfaces because of this. This commit
factors this operation out into a helper function.
