[libvirt] [PATCH 2/2] network: check for bridge name conflict with existing devices

Shivaprasad bhat shivaprasadbhat at gmail.com
Fri Apr 24 10:58:26 UTC 2015


Thanks for the patches Laine. I agree pretty much with both the patches.
also had a chance to try these out.

Only scenario I see a trouble is,

net-create without bridge name in the xml, followed by net-define
using the same xml file.
The live and --inactive xmls both show different bridge names, though
the active bridge
can be reused by the network for "this scenario alone". I think this
is a very rare case and not worth
to fix it, as net-destroy followed by net-create using the same xml
file would anyway reuse the
same old bridge name if available.

Outside of this patch,
the net->newDef->bridge's are not considered in virNetworkBridgeInUseHelper().
Do we need to?

Thanks,
Shiva

On Fri, Apr 24, 2015 at 12:33 AM, Laine Stump <laine at laine.org> wrote:
> Since some people use the same naming convention as libvirt for bridge
> devices they create outside the context of libvirt, it is much nicer
> if we check for those devices when looking for a bridge device name to
> auto-assign to a new network.
> ---
>  src/network/bridge_driver.c | 25 +++++++++++++++++--------
>  1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
> index abacae3..3b879cd 100644
> --- a/src/network/bridge_driver.c
> +++ b/src/network/bridge_driver.c
> @@ -2037,11 +2037,13 @@ networkStartNetworkVirtual(virNetworkDriverStatePtr driver,
>
>      /* Create and configure the bridge device */
>      if (!network->def->bridge) {
> -        /* this can only happen if the config files were edited
> -         * directly. Otherwise networkValidate() (called after parsing
> -         * the XML from networkCreateXML() and networkDefine())
> -         * guarantees we will have a valid bridge name before this
> -         * point.
> +        /* bridge name can only be empty if the config files were
> +         * edited directly. Otherwise networkValidate() (called after
> +         * parsing the XML from networkCreateXML() and
> +         * networkDefine()) guarantees we will have a valid bridge
> +         * name before this point. Since hand editing of the config
> +         * files is explicitly prohibited we can, with clear
> +         * conscience, log an error and fail at this point.
>           */
>          virReportError(VIR_ERR_INTERNAL_ERROR,
>                         _("network '%s' has no bridge name defined"),
> @@ -2762,8 +2764,9 @@ static int networkIsPersistent(virNetworkPtr net)
>
>  /*
>   * networkFindUnusedBridgeName() - try to find a bridge name that is
> - * unused by the currently configured libvirt networks, and set this
> - * network's name to that new name.
> + * unused by the currently configured libvirt networks, as well as by
> + * the host system itself (possibly created by someone/something other
> + * than libvirt). Set this network's name to that new name.
>   */
>  static int
>  networkFindUnusedBridgeName(virNetworkObjListPtr nets,
> @@ -2777,7 +2780,13 @@ networkFindUnusedBridgeName(virNetworkObjListPtr nets,
>      do {
>          if (virAsprintf(&newname, templ, id) < 0)
>              goto cleanup;
> -        if (!virNetworkBridgeInUse(nets, newname, def->name)) {
> +        /* check if this name is used in another libvirt network or
> +         * there is an existing device with that name. ignore errors
> +         * from virNetDevExists(), just in case it isn't implemented
> +         * on this platform (probably impossible).
> +         */
> +        if (!(virNetworkBridgeInUse(nets, newname, def->name) ||
> +              virNetDevExists(newname) == 1)) {
>              VIR_FREE(def->bridge); /*could contain template */
>              def->bridge = newname;
>              ret = 0;
> --
> 2.1.0
>




More information about the libvir-list mailing list