On Wednesday 09 December 2009, Anthony Liguori wrote:
> This isn't really a generic thing and I dislike pretending it is. This
> is specifically for macvtap.
Well, depending how how things work out with VMD-q and SR-IOV,
I might move the tap interface stuff into a library module and add more
user-level shims for it that deal with the creation of character devices.
Macvtap essentially implements a tun/tap compatible character device,
while leaving out some of the stuff that doesn't make sense there (e.g.
creation of virtual network interfaces). The idea of my patch was
to deal with anything that is a tap protocol implementation.
One thing that is special for macvtap is that the guest MAC address
has to match the MAC address of the macvtap downstream device,
because macvlan filters out all traffic destined for other unicast
addresses.
> If we were going to do this, I'd rather introduce a -net macvtap that
> actually allocated the interfaces (similar to how tap works). The
> problem with this interface is that it's a two stage process. You have
> to create an interface, then hand the name to qemu. It would be just as
> easy to hand qemu an fd with a helper.
You can't really allocate the device from qemu in a nice way.
I had mostly implemented macvtap support for your -net bridge
helper when I realized this.
Since it uses netlink (with CAP_NET_ADMIN) to create or destroy
the netdev, it first needs to wait for udev to create the device
node (which is not so bad by itself), and then use netlink again
after shutting down to destroy the network device.
> What's nice about -net tap is that with a little bit of setup
> (/etc/qemu-ifup), it Just Works. -net tap,dev= does not share this
> property.
The qemu-ifup stuff IMHO is just a workaround for the problem of
having to defer network setup until after you open the device.
Macvtap doesn't have this problem. In the same way we deal with
other host resources (raw disk access, USB passthrough, /dev/kvm),
you first set up specifically what the user is allowed to do, either
manually or through libvirt and then just use it.
> I think this is a good place where an exec helper would be a natural fit.
IMHO, the exec helper is a good way to abstract away the difference
between tap, macvtap and possibly others based on the host configuration,
but it doesn't really make sense for a separate -net macvtap backend
like you suggested. You've shown that the helper can be used to enforce
user permissions for tun/tap, which lacks this, but for macvtap we can
just use regular user permissions.
Arnd
