Xen hotplugging of USB devices in passthrough

Xen's management of USB devices in passthrough (especially for HVM guests, such as windows machines) sucks like a tornado. (kvm's does not shine either, for mostly the same reasons). Among other shortcomings, hotplugging does not work: unplug the device, or turn off your printer, and it disappears - for good. Plugging it in/turning it on will not bring it back into your domU.

The situation can be improved upon using udev rules and a script.

Udev file: /etc/udev/rules.d/99-zlocal:

  SUBSYSTEM=="usb", SYSFS{idVendor}=="0951", SYSFS{idProduct}=="1646", \ 
   ENV{idDomU}="mosaico", ENV{idVendor}="0951", ENV{idProduct}="1646",\
   RUN+="/usr/local/bin/xen-usb-hotplug mosaico 0951 1646"

(Translation:
if subsystem is usb, vendor 0951 and product 1646 - this numbers can be found with lsusb - put some stuff in the environment and insert a program in the run chain for this event)

The program goes like this::

#!/bin/bash

PROMPT="xen-usb-hotplug(ORION):"
XM=/usr/sbin/xm
logger "${PROMPT} HOTPLUGGING"
logger "${PROMPT} started with environment: $(env)"
DOMU=$1
VENDOR=$2
PRODUCT=$3
#if CLI parameters are unavailable, try to use environment

[[ x${DOMU:=$idDomU}       == x ]] && { logger -p user.error "${PROMPT} DOMU is not set"; exit 0 ;    }
[[ x${VENDOR:=$idVendor}   == x ]] && { logger -p user.error "${PROMPT} VENDOR is not set"; exit 0 ;  }
[[ x${PRODUCT:=$idProduct} == x ]] && { logger -p user.error "${PROMPT} PRODUCT is not set"; exit 0 ; }
if [[ x$ACTION != xadd ]]; then
  logger "${PROMPT} ${XM} usb-del  $DOMU host:${VENDOR}:${PRODUCT}"
  ${XM} usb-del  $DOMU host:${VENDOR}:${PRODUCT}
else
  logger "${PROMPT} ${XM} usb-add  $DOMU host:${VENDOR}:${PRODUCT}"
  ${XM} usb-add  $DOMU host:${VENDOR}:${PRODUCT}
fi

This sets some service variables, grabs parameters from the CLI, and - if action equals "add", uses "xm usb-add" to stuff the device in the approrpiate domU.
Note that the "remove" part is purely ornamental, because - when unplugged - the device has different information, and the rule is not triggered.
Also note that, to be complete, one would need to discriminate among devices with same vendor and prodID. This is left as an exercise to the reader.

Note: I owe part of what above (essentially the idea of using udev to run a script on usb insertion) to a - since disappeared - blog note by Lorenzo Simionato.