]> xenbits.xensource.com Git - people/liuw/libxenctrl-split/libvirt.git/commit
network: save bridge name in ActualNetDef when actualType==network too
authorLaine Stump <laine@laine.org>
Fri, 21 Nov 2014 17:20:37 +0000 (12:20 -0500)
committerLaine Stump <laine@laine.org>
Mon, 8 Dec 2014 19:43:42 +0000 (14:43 -0500)
commita3609121799d44898a3e0d0bf92b755e55e7b418
treedd95fbb14614acf5036c4324f5c402f2d6cf666b
parent40961978ee1f498f3a87baf158c7392e1ba48489
network: save bridge name in ActualNetDef when actualType==network too

When the actualType of a virDomainNetDef is "network", it means that
we are connecting to a libvirt-managed network (routed, natted, or
isolated) which does use a bridge device (created by libvirt). In the
past we have required drivers such as qemu to call the public API to
retrieve the bridge name in this case (even though it is available in
the NetDef's ActualNetDef if the actualType is "bridge" (i.e., an
externally-created bridge that isn't managed by libvirt). There is no
real reason for this difference, and as a matter of fact it
complicates things for qemu. Also, there is another bridge-related
attribute (macTableManager) that will need to be available in both
cases, so this makes things consistent.

In order to avoid problems when restarting libvirtd after an update
from an older version that *doesn't* store the network's bridgename in
the ActualNetDef, we also need to put it in place during
networkNotifyActualDevice() (this function is run for each interface
of each domain whenever libvirtd is restarted).

Along with making the bridge name available in the internal object, it
is also now reported in the <source> element of the <interface> state
XML (or the <actual> subelement in the internally-stored format).

The one oddity about this change is that usually there is a separate
union for every different "type" in a higher level object (e.g. in the
case of a virDomainNetDef there are separate "network" and "bridge"
members of the union that pivots on the type), but in this case
network and bridge types both have exactly the same attributes, so the
"bridge" member is used for both type==network and type==bridge.
src/conf/domain_conf.c
src/network/bridge_driver.c