Looks like dvs-agent should choose proper DVS basing on value returned by VMwareDVSMechanismDriver. get_mappings
Quoting Eugene Nikanorov:
"""
get_mappings returns correspondence between physnet's and physical bridges.
That may or may not not make sense for your particular agent.
For example, for OVS agent that is an indication that tenant networks created for certain "physnet" should "go" through certain bridge configured on controlles/computes. In other words it's a way of mapping between the network and physical bridges.
I guess that doesn't make sense for dvs driver, but I'm not sure.
Most probably you don't need mappings at all indicating that all networks are implemented in the same way via means of the backend you're creating the driver for. That would just means that you agent on compute node (or wherever it will run) will receive the network, having additional attribute "provider:network" empty.
"""
Looks like dvs-agent should choose proper DVS basing on value returned by VMwareDVSMechan ismDriver. get_mappings
Quoting Eugene Nikanorov: computes. In other words it's a way of mapping between the network and physical bridges.
"""
get_mappings returns correspondence between physnet's and physical bridges.
That may or may not not make sense for your particular agent.
For example, for OVS agent that is an indication that tenant networks created for certain "physnet" should "go" through certain bridge configured on controlles/
I guess that doesn't make sense for dvs driver, but I'm not sure.
Most probably you don't need mappings at all indicating that all networks are implemented in the same way via means of the backend you're creating the driver for. That would just means that you agent on compute node (or wherever it will run) will receive the network, having additional attribute "provider:network" empty.
"""