With Libvirt under modern kernels, you can't use <interface type='ethernet'> unless QEMU is running as root. Running qemu as root is not ideal, but I was able to track down the issue to this linux change: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ca6bb5d7ab22ac79f608fe6cbc6b12de6a5a19f0 Which means that if you're seeing errors like this: 2015-03-02T18:00:51.243477Z qemu-kvm: -netdev tap,script=/tmp/vnet380622.sh,id=hostnet1: could not open /dev/net/tun: Operation not permitted 2015-03-02T18:00:51.243518Z qemu-kvm: -netdev tap,script=/tmp/vnet380622.sh,id=hostnet1: Device 'tap' could not be initialized They can be resolved like this: 1) Edit /etc/libvirt/qemu.conf, and add "/dev/net/tun" to the cgroup_device_acl option 2) Run: setcap cap_net_admin+eip /bin/qemu-system-x86_64 This will give QEMU CAP_NET_ADMIN when it runs. Make sure you review `man capabilities` to see what capabilities this actually gets qemu. The downside here is that in the event a guest somehow breaks out of qemu, CAP_NET_ADMIN gives them a bunch of scary permissions that could result in you having a seriously bad day (it's enough permissions to MITM all the machine's traffic, which could easily result in compromise) It looks to me like libvirt already has the ability to create tap devices and pass them into qemu (src/util/virnetdevtap.c - virNetDevTapCreateInBridgePort), however you need to actually be using a bridged network to do this. There is no way to have libvirt just create a tap device and leave the rest to user defined scripts. I don't think I have the necessary knowledge to add that feature in a generic way, but it seems like it would be pretty handy. I'll probably just work around it by removing the virNetDevBridgeAddPort call from our version of libvirt.
On 3/2/2015 1:41 PM, Brian Rak wrote:> With Libvirt under modern kernels, you can't use <interface > type='ethernet'> unless QEMU is running as root. > > Running qemu as root is not ideal, but I was able to track down the > issue to this linux change: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ca6bb5d7ab22ac79f608fe6cbc6b12de6a5a19f0 > > > Which means that if you're seeing errors like this: > > 2015-03-02T18:00:51.243477Z qemu-kvm: -netdev > tap,script=/tmp/vnet380622.sh,id=hostnet1: could not open > /dev/net/tun: Operation not permitted > 2015-03-02T18:00:51.243518Z qemu-kvm: -netdev > tap,script=/tmp/vnet380622.sh,id=hostnet1: Device 'tap' could not be > initialized > > They can be resolved like this: > > 1) Edit /etc/libvirt/qemu.conf, and add "/dev/net/tun" to the > cgroup_device_acl option > 2) Run: setcap cap_net_admin+eip /bin/qemu-system-x86_64 > > This will give QEMU CAP_NET_ADMIN when it runs. Make sure you review > `man capabilities` to see what capabilities this actually gets qemu. > > The downside here is that in the event a guest somehow breaks out of > qemu, CAP_NET_ADMIN gives them a bunch of scary permissions that could > result in you having a seriously bad day (it's enough permissions to > MITM all the machine's traffic, which could easily result in compromise) > > > It looks to me like libvirt already has the ability to create tap > devices and pass them into qemu (src/util/virnetdevtap.c - > virNetDevTapCreateInBridgePort), however you need to actually be using > a bridged network to do this. There is no way to have libvirt just > create a tap device and leave the rest to user defined scripts. > > I don't think I have the necessary knowledge to add that feature in a > generic way, but it seems like it would be pretty handy. I'll probably > just work around it by removing the virNetDevBridgeAddPort call from > our version of libvirt. >In IRC, I was directed to this patch: https://www.redhat.com/archives/libvir-list/2015-February/msg01212.html ... which does exactly what I was looking for. It doesn't build cleanly in that state, but it's pretty trivial fix (needs actualType added to the function definition for qemuNetworkIfaceConnect and the two calls modified)
2015-03-02 23:41 GMT+03:00 Brian Rak <brak@gameservers.com>:> In IRC, I was directed to this patch: > https://www.redhat.com/archives/libvir-list/2015-February/msg01212.html ... > which does exactly what I was looking for. It doesn't build cleanly in that > state, but it's pretty trivial fix (needs actualType added to the function > definition for qemuNetworkIfaceConnect and the two calls modified)I send new patch version one day ago and it waiting for review. -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru