[libvirt] Using Generic Ethernet type with custom networking without lowering the host security level

Ishimoto, Ryu ryu at midokura.com
Wed Oct 31 09:10:13 UTC 2012


Hi Everyone,

I wanted to ask a question about the 'generic ethernet' NIC type.  If I
understand its security concerns correctly, because it expects QEMU to
execute scripts to bring up/down the interface, it requires that the host
security level is lowered to allow QEMU to perform privileged operations.
 While this is definitely not desirable, I'm have a situation where I want
to use libvirt to work with a custom networking solution that is neither
Linux bridge or OpenVSwitch.  Currently, to make this happen, I would
create a tap interface myself, configure it(like adding it to the
datapath), and inform libvirt of this interface as a generic ethernet type
with script attribute set to ''.  In order to make this work without the
security issue mentioned, I would like to suggest a new device type(or just
a modification of generic ethernet type) in which libvirt accepts an
interface name, opens it and gets its fd, and passes the fd to QEMU.  QEMU
does not run any scripts and expects the tap interface to be already open.
 Another solution might be to allow custom scripts to be plugged into
libvirt that allows you to add an interface to a bridge instead of running
brctl or ovs-vsctl.  The latter solution lets libvirt create the tap
interface, whereas the former requires that the tap is 'plugged' into the
network before libvirt takes control for the VM to have connectivity when
it launches.  I prefer the former because it seems less disruptive while
providing similar features.

I would be more than happy to send a patch for this, and I apologize that
this lacks details, but I just wanted to first make sure that what I'm
suggesting here makes sense and that I'm not missing something critical, as
I am fairly new to libvirt.

Thanks,
Ryu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20121031/98dc1e58/attachment-0001.htm>


More information about the libvir-list mailing list