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?