Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 12/01/2010 12:04 PM, Paul Brook wrote:
>> Hi,
>>
>> On 11/30/2010 12:32 PM, Alon Levy wrote:
>>> On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote:
>> <snip snip>
>>
>>>> Then there would be multiple ways to add a virtual usb device using
>>>> usb-net-redir.c to the virtual machine. One way of adding such a device
>>>> could be starting a tcp/ip server on a machine with an interesting usb
>>>> device, say 192.168.1.100:2222 and then in the monitor type:
>>>> usb_add net:192.168.1.100:2222:[vid]:[pid]
>>>> or:
>>>> usb_add net:192.168.1.100:2222:[busnr]:[addr]
>>>
>>> Wouldn't you want to add a usb_add net:host:port that would just export
>>> anything it has decided to export? or is this just the next step?
>>
>> The idea is one channel (one socket in this case), one device. This way the
>> same server on the usb-host could export multiple devices, using one
>> client connection per device. The server of course should in the end have
>> some sort of security wrt which devices the vm-host can connect to and
>> which not.
>
> I don't think either of vid:pid or bus:address are a good idea for identifying
> remote devices.  The idea that the VM should need to know about the details of
> the USB topology of the remote machine seems fundamentally wrong. It also
> means that it's impossible to use devices that reset+reconnect themselves.
>
> Instead I suggest just using a freeform string ID.  For practical reasons we
> probably want to restrict this to regular characters, like we do other ids
> (i.e. [-_A-Za-z0-9]).  This allows the device server to assign persistent,
> meaningful names to devices.  If you really want to allow the VM free reign of
> devices on a machine you can just make it the server accept and parse names of
> the form device_id_1234_5678 (for example).
>
> For bonus points your protocol should include some way of enumerating the
> available devices.
>

First of all management (enumeration, requesting a specific device) is something
which I want to do separately from the usb redirection protocol itself as
management is transport specific, see below.

> When tunneling over spice/vnc I'd expect the same id to be used. i.e.
>    net:<host:port>:[device_id]
>    spice:[sice_display]:[device_id]
>    vnc:[vnc_display>]:[device_id]

In the spice and vnc cases I do not expect there to be a way to connect
to devices on the client from the monitor. Instead the client will tell
qemu through some sort of command channel, that there is a remote usb
device to be plugged into the virtual machine through redirection.

This is what makes most sense from a use case pov. A user is sitting
behind some client machine connecting to a vm through vnc / spice and
then wants to "plug" some local (to the client machine) usb device
into the vm. The logical way to do this is through some menu / other
UI part of the vnc / spice client. This menu would then show a list of
all currently connected devices and allow the user to choose one to
plug in.

The problem with exotic devices which disconnect and come back under
a different guise then also becomes a client problem, which is IMHO
where it belongs (the client could for example remember which usb-port
it is redirecting to the virtual machine and if a device unplug /
replug happens there also redirect the new device).

Thinking more about this, the solution to the whole device id problem
is not sending a device id from qemu / the monitor at all, iow:
     net:<host:port>:[device_id]

Becomes just:
     net:<host:port>

In this scenario a server already needs to be started manually on the
usb-host, the device / port to share can then be indicated when starting
the server.

And in the rare case one wants to share multiple devices/ports on the same
usb-host one can simply start the server multiple times listening on
different ports.

Regards,

Hans