(look towards the bottom of the message for the "hidden lead" :-) On 1/16/20 1:16 PM, Rob Roschewsk wrote: Oh, I see - you're running a version of libvirt that was released exactly 4 years ago today! You should notice in the web page you referenced above that <target dev='blah' managed='no'/> has only been supported since libvirt 5.7.0, which was released just last September. What you're running is incredibly ancient, and there is *a lot* of stuff documented on libvirt.org that it doesn't support (although we do try to note the minimum version required for any new feature). Aside from missing the very recent "managed='no'" feature (which I think you probably don't need or even care about - you'd rather just let libvirt create the tap device for you, right?), the version of libvirt you're running doesn't even contain the very *old* commit 9c17d665fd (from March of 2016) which removed the necessity to run qemu as root when using <interface type='ethernet'>. So you have two choices: 1) upgrade to a newer libvirt (something in the 5.x.0 or even 6.0.0 if possible). In this case you'll also probably want to remove the <target dev='blah' managed='no'/> line (unless you really do want give the device a specific name (controlled by "dev='blah'") and/or precreate the tap device yourself (controlled by "managed='no'"). 2) change /etc/libvirt/qemu.conf to tell libvirt it should run qemu as user root and not clear the capabilities privileges for the qemu process (done by uncommenting 'user = "root"' and 'clear_emulator_capabilities = 0'). This is a *VERY* bad idea, since 1) it allows the qemu process to run as root, meaning that if a virtual machine finds an exploit in your (*also* very old) qemu binary and "breaks out", it will have full root access to your host. Also in this case you will need to manually create the tap device beforehand (before commit 9c17d665fd libvirt would not auto-create a tap device for <interface type='ethernet'>). I hope I've convinced you to take choice (1)!