[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libvir] Proposal: More script hooks for <interface type='ethernet'>



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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]