From: Roopa Prabhu <roprabhu(a)cisco.com&gt; For direct attach devices, in qemuBuildCommandLine, we seem to be freeing actual device on error path (with networkReleaseActualDevice). But the actual device is not deleted. qemuProcessStop eventually deletes the direct attach device and releases actual device. But by the time qemuProcessStop is called qemuBuildCommandLine has already freed actual device. Leaving stray macvtap devices behind on error. So the simplest fix is to remove the networkReleaseActualDevice in qemuBuildCommandLine. This patch does just that. Does this look right ?. I have only verified this with direct and bridge mode. The other option is to do both delMacvtap and networkReleaseActualDevice in qemuBuildCommandLine instead of doing only networkReleaseActualDevice. I do have a patch for this too. Signed-off-by: Roopa Prabhu <roprabhu(a)cisco.com&gt; --- src/qemu/qemu_command.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index bb12016..ba33a4a 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -5378,8 +5378,6 @@ qemuBuildCommandLine(virConnectPtr conn, virReportOOMError(); error: /* free up any resources in the network driver */ - for (i = 0 ; i < def->nnets ; i++) - networkReleaseActualDevice(def->nets[i]); for (i = 0; i <= last_good_net; i++) virDomainConfNWFilterTeardown(def->nets[i]); virCommandFree(cmd);