Bridge-less VM

Laine Stump laine at redhat.com
Fri Jan 17 17:46:52 UTC 2020


(look towards the bottom of the message for the "hidden lead" :-)


On 1/16/20 1:16 PM, Rob Roschewsk wrote:
> I'm trying to create a free standing VM that doesn't connect to a bridge.
> 
> This is supposedly do able according to the WIKI:
> https://libvirt.org/formatdomain.html#elementsNICSEthernet
> 
> But with a config similar to:
> 
>    <interface type='ethernet'>
>      <target dev='mytap1' managed='no'/>
>      <model type='virtio'/>
>    </interface>
> 
> When starting the domain I get the error:
> error: internal error: process exited while connecting to monitor: 
> 2020-01-16T18:08:04.788860Z qemu-system-x86_64: -netdev 
> tap,id=hostnet0,vhost=on,vhostfd=26: could not open /dev/net/tun: 
> Operation not permitted
> 
> Checked permissions on /dev/net/tunand it's 666
> 
> If I just configure it as a "bridge" connection the domain starts. Then 
> I can use brctl to remove it from the bridge to get what I want. That 
> just proves it possible but with extra steps (Shout out to Rick and Morty)
> 
> Thoughts??
> Running Ubuntu 16.04.1 Kernel 4.15.0-74
> libvirt 1.3.1-1ubuntu10.27

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)!


> qemu 1:2.5+dfsg-5ubuntu10.41
> 
> Thanks,
> --> Rob
> 
> 
> 
> 




More information about the libvirt-users mailing list