Bug 1478007

This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

I suspect that this regression is related to the Engine domxml work. Could Virt team take a look?

It was indeed a regression caused by the switch to engine xml, but now it fails on code added as part of https://gerrit.ovirt.org/#/c/80481/. Since it is not clear to me what should happen in that case (which network name should be taken), moving back to network team to decide how should it be fixed.

Arik, Vdsm should see only vdsm_name of a network. <Empty> used to be translated by Engine to the empty string, and later translated by vdsm to ';vdsmdummy;' bridge name.

How do you think this should be done in the age of Engine DomainXML?

(In reply to Dan Kenigsberg from comment #4)
> How do you think this should be done in the age of Engine DomainXML?

If that's the mapping that we always do, let's set it directly on the engine side IMO.
Francesco, 
1. what do you think?
2. I saw in the metadata examples that there is a network-name set per-nic - what's the intended use of it?

(In reply to Arik from comment #5)

> 2. I saw in the metadata examples that there is a network-name set per-nic -
> what's the intended use of it?

For ovs switchType, vdsm maps the requested network name to a host-specific bridge name, that is unknown to Engine.
Another use for the (empty) network name is the one I've already mentioed (map the empty string to the ;vdsmdummy; bridge, which is also an entity unknown to Engine).

(In reply to Arik from comment #5)
> (In reply to Dan Kenigsberg from comment #4)
> > How do you think this should be done in the age of Engine DomainXML?
> 
> If that's the mapping that we always do, let's set it directly on the engine
> side IMO.
> Francesco, 
> 1. what do you think?

It could work. See below

> 2. I saw in the metadata examples that there is a network-name set per-nic -
> what's the intended use of it?

Vdsm can easily and safely learn from engine XML the network to use for the VM NICs (vmdevices.Interface.network) only in the case of linux bridge. 
In this case we can trivially parse the domain XML and learn the network to use.

In the case of OVS, Vdsm cannot (or should not) reverse the mapping, so the network name has to be set explicitely, hence the need for metadata

            ovs_bridge = supervdsm.getProxy().ovs_bridge(self.network)
                                              ^^^^^^^^^^^^^^^^^^^^^^^
            if ovs_bridge:
                if ovs_bridge['dpdk_enabled']:
                    self._source_ovsdpdk_bridge(iface, ovs_bridge['name'])
                else:
                    self._source_ovs_bridge(iface, ovs_bridge['name'])
            else:
                iface.appendChildWithArgs('source', bridge=self.network)

SR-IOV and hostdev there is no need to use the network name.

In turn, Vdsm needs the network name to properly initialize the vmdevices.Interface object. It is not just to build the engine XML, we do logic on device setup/teardown for OVS/DPDK and this logic should be kept in Vdsm[1]
IMHO.

Hit 'send' too soon...

Vdsm should handle the case on which network='' (empty string), we handle this for linux bridges already but for metadata we will need a small patch.

Verified on - 4.2.0-0.0.master.20170915203601.git96df02d.el7.centos

This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.