Comment 7 for bug 640993

I remember the issue now. The problem is that AppArmorSetSecurityHostdevLabel() is only a stub. It is a stub because while we would want to do something like this:
    if (profile_loaded(secdef->imagelabel) >= 0) {
        if (load_profile(drv, secdef->imagelabel, vm, NULL) < 0) {
            virSecurityReportError(VIR_ERR_INTERNAL_ERROR,
                                   _("cannot update AppArmor profile "
                                     "\'%s\'"),
                                   secdef->imagelabel);
            return -1;
        }
    }

we cannot because the 'vm' xml that is passed to virt-aa-helper in this implementation does not have the new xml for the newly attached drive. Indeed

This is not a regression over lucid since it has the same problem and karmic didn't do it either. However, in karmic the /etc/apparmor.d/abstractions/libvirt-qemu had:
  # WARNING: uncommenting these gives the guest direct access to host hardware.
  # This is required for USB pass through but is a security risk. You have been
  # warned.
  #/sys/bus/usb/devices/ r,
  #/sys/devices/*/*/usb[0-9]*/** r,
  #/dev/bus/usb/*/[0-9]* rw,

But in lucid and later we have:
  # For hostdev access. The actual devices will be added dynamically
  /sys/bus/usb/devices/ r,
  /sys/devices/*/*/usb[0-9]*/** r,

part of the functionality for hostdev access was added to virt-aa-helper in lucid and later, but clearly not enough to fully fix hostdev hot attach. So the workaround is to update /etc/apparmor.d/libvirt-qemu to have:
  /dev/bus/usb/*/[0-9]* rw,

That does give all guests access to any usb hardware of course, which is not all that great. People can add a more specific rule to /etc/apparmor.d/libvirt/libvirt-<uuid> (not the .files file!) to limit access for a specific guest to a specific USB device.