The function the upstream fix relates to in Openstack is:
def set_vif_host_backend_ethernet_config(conf, tapname):
"""Populate a LibvirtConfigGuestInterface instance
with host backend details for an externally configured
host device.
Before the change it was part of "get_config(self, instance, network, mapping)" in
"class LibvirtOpenVswitchDriver(LibvirtBaseVIFDriver)"
I'm not sure but does that imply it might trigger in any openvswitch setup?
Some of our tests should have had the same then.
I'll rerun some of those later to be sure.
The libvirt change on the other hand "only" changes to NOT refuse guests right away that have a script= attribute set. See the referred bug for details.
Now it does no more refuse to start those - that should (tm) not cause the issue. Maybe it really is the openstack commit you referred to (causing it to fallback to the default).
But as I said I'd wonder if that commit is active in your Software stack at all.
The function the upstream fix relates to in Openstack is: host_backend_ ethernet_ config( conf, tapname): estInterface instance
def set_vif_
"""Populate a LibvirtConfigGu
with host backend details for an externally configured
host device.
Before the change it was part of "get_config(self, instance, network, mapping)" in tchDriver( LibvirtBaseVIFD river)"
"class LibvirtOpenVswi
I'm not sure but does that imply it might trigger in any openvswitch setup?
Some of our tests should have had the same then.
I'll rerun some of those later to be sure.
The libvirt change on the other hand "only" changes to NOT refuse guests right away that have a script= attribute set. See the referred bug for details.
Now it does no more refuse to start those - that should (tm) not cause the issue. Maybe it really is the openstack commit you referred to (causing it to fallback to the default).
But as I said I'd wonder if that commit is active in your Software stack at all.