Comment 31 for bug 1665698

Hi Neil,

1) on what /etc/qemu.ifup (as being the default) actually does
You can look at Debian/Ubuntus script (unchanged since 2013)
https://anonscm.debian.org/cgit/pkg-qemu/qemu.git/tree/debian/qemu-ifup.linux
AFAIK Fedora provides no default, but in most cases it is meant for custom scripts anyway, e.g. https://en.wikibooks.org/wiki/QEMU/Networking#qemu-ifup as a base to create such.

From there the TL;DR for Debian/Ubuntu is in the top quote:
 # Script to bring a network (tap) device for qemu up.
 # The idea is to add the tap device to the same bridge
 # as we have default routing to.
It has various paths with exit as a no-op e.g. if no bridge is there.

2) Why it works in tests
I outlined several combinations of libvirt and openstack above (see the timeline in comment #20) that work well together. If you are on any of those your testing will not show issues.
Also the "error" is not this script failing. It very likely would work just doing nothing or something useless in the case here (yet it is dangerous to rely on that). The issue reported here is that due to the unexpected calling of /etc/qemu-ifup (due to now path being not set) the apparmor protection kicks in and blocks it. So if you tested on a platform without apparmor or with other rules you would not have seen it.
Yet it is correct by apparmor to do so - a user is usually meant to add exceptions if needed (as the workaround for Logan does.)

3)
On detection of the fix that lets libvirt handle "" as no-op - to my knowledge - there is no externally visible thing to check.
It will be upstream with libvirt 3.1 so you can assume it is there starting from this.
But you'll never know who will have it backported or not.

4)
IMHO there is one little piece to the puzzle still missing which is want to understand why in Logans case qemu is calling it (as in newer libvirt it should do it) - see comment #28.
So I'd have expected libvirt saying "error executing '' or anything like it, not the apparmor issue he hit for qemu."
But I'll have to wait on his reply for that.