Bug 1006915

Summary: [RFE] Add support for udev events
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Gerd Hoffmann <kraxel>
Component: libvirtAssignee: Jonathon Jongsma <jjongsma>
Status: CLOSED DEFERRED QA Contact: lijuan men <lmen>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: ---CC: dyuan, jdenemar, juzhang, kraxel, lmen, mzhan, rbalakri, xuzhang
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-08 14:34:13 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gerd Hoffmann 2013-09-11 13:44:02 UTC
Description of problem:
Hotplugging for usb -host devices is not supported.

Version-Release number of selected component (if applicable):
libvirt-1.1.1-4.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Boot guest with usb host device.
2. Unplug device on the host, watch it go away in the guest.
3. Re-plug device into the host.

Actual results:
Device does NOT show up in the guest.

Expected results:
Device shows up in the guest.

Additional info:
Related issue:
(1) Start guest with usb device unplugged and startupPolicy='optional'.
(2) Plug device into host -> device does NOT show up in the guest.

Comment 4 Martin Kletzander 2015-07-09 16:51:14 UTC
I think this could lead to security problems.  We need to make sure that the user expects that and wants us to do it.  This is possible with auto-usbredir with spice, but without it this might get really problematic.

Did you mean the feature spice has or do you expect this to work even with e.g. headless machines?

Comment 5 Gerd Hoffmann 2015-07-10 07:04:57 UTC
(In reply to Martin Kletzander from comment #4)
> I think this could lead to security problems.  We need to make sure that the
> user expects that and wants us to do it.  This is possible with
> auto-usbredir with spice, but without it this might get really problematic.

I think auto-usbredir is something else:  hotplug *any* usb device plugged in (but only in case spice client has the focus IIRC).

> Did you mean the feature spice has or do you expect this to work even with
> e.g. headless machines?

It should work with headless machines too.
Basically this ...

    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source startupPolicy='optional'>
        <vendor id='0x8564'/>
        <product id='0x1000'/>
      </source>
      <address type='usb' bus='3' port='4'/>
    </hostdev>

... should be improved.

A *specific* usb device is assigned to the guest here (so, no, I don't think we have a security problem here).

Today this can't deal with hotplug.  The guest will only see the device in case it is present when you boot the machine.  Plug it out and back in -> it's permanently gone in the guest.  Boot without device (as allowed by startupPolicy='optional'), plug it in while the guest is running -> it doesn't show up.

Comment 6 Martin Kletzander 2015-07-10 09:26:13 UTC
It might be nice to have this in, although we need to deal with at least
 a) deciding to which VM to plug the device in, in case there are multiple ones with such specification,
 b) how do we get a notification for these changes and
 c) how do we deal with faults (if we cannot assign it to the guest, is information in logs enough or should we guarantee this somehow)

I'm not saying it's impossible, just that it requires some reworks as that's completely new feature.  Thanks for pointing it out!

Comment 7 Martin Kletzander 2016-06-27 14:47:56 UTC
The whole solution for this would be out of scope for libvirt to do by itself, mainly due to various combinations of use cases per each user.  However exposing udev events through libvirt's APIs and virsh would enable doing this with few lines of code/script.  Hence the change in the 'Summary' field.

Comment 8 Jaroslav Suchanek 2020-06-08 14:34:13 UTC
This bug was closed deferred as a result of bug triage.

Please reopen if you disagree and provide justification why this bug should
get enough priority. Most important would be information about impact on
customer or layered product. Please indicate requested target release.