I have a few issues with <interface type='ethernet'>:
- The requirement that either
(1) the tap device already exists and has a constant name, or
(2) the tap device can be created by the current user without
privilege escalation
doesn't work for places where the user wants to
- dynamically generate tap devices
- ...but is running kvm without privileges to do so.
(this is particularly likely now that write privileges to
/dev/net/tap are not enough, and the user needs CAP_NET_ADMIN to
create a tap device).
Allowing a target script to be specified (which is responsible for
gaining any privileges necessary) which runs *before* the tap device
is opened and would resolve this.
- A qemu-ifup script can be specified, but not a qemu-ifdown
replacement.
Before looking to use libvirt, I had kvm's invocation wrapped by a
script which did appropriate privilege escalation (ifname=$(sudo tunctl
-b -u $USER), with sudo configured with the NOPASSWORD flag for this
request -- though plenty of other approaches are certainly possible). It
would be ideal if more hooks were available... for instance:
<interface type='ethernet'>
<!-- script gives device name on stdout -->
<target script='/usr/local/bin/make-me-a-tap-device'/>
<!-- preexisting argument and syntax for up scripts -->
<script path='/etc/qemu-ifup-mynet'/>
<!-- option to specify a down script, passed to qemu via
'downscript=' parameter-->
<script-down path='/etc/qemu-ifdown-mynet'/>
</interface>
Working around this means that I would need to preallocate the tap
devices and assign them to specific VMs (boo! hiss!) or that (if I
wrapped libvirt's invocation to have the tap device created just ahead
of time and its name substituted into interface/@dev) 3rd-party
libvirt-based management tools couldn't be used (which would defeat the
point of switching to libvirt from my homegrown script collection in the
first place).
So -- does the proposed syntax extension look reasonable?