blob: 0ca19a79a134d5700d640a553f7edbf48326be26 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
That 10+ ms delay is apparently detrimental. It makes sense because USB is
designed to work over short distances. The protocol and (even) electrical
characteristics are built upon this assumption. The USB frames are short in
length and polled frequently, and almost no buffering is done in the background
as it works closely on the hardware. Therefore, the performance hit is
inevitable and instability issues are expected when USB frames are passed over
IP.
The usb-redir devices are attached via qemu command line passthrough.
virt-manager is not "aware" of this and it doesn't even try to see if there usb
redirection is available.
If you really have to use it , use
[virt-viewer](https://virt-manager.org/download). It is available on most
distros and even on Windows.
### List of Devices
Some usb devices don't like getting passed around over the network.
| DEVICE | LOCAL | OVER IP |
|-|-|-|
| Mobile (Android, Apple) | 🫳kinda(unstable) | ❌NO |
| Flash Drives | ✅YES | 🫳kinda(slow) |
| HID(keyboard and mouse) | ✅YES | ✅YES |
### TODO Analysis: Android and IOS Devices
This is work in progress.
Points:
- To make XNU kernel happy, the devices must be attached to a hub. The kernel
cannot enumerate usb devices directly hot-plugged in the controller
- Performance hit due to the fact that qemu only supports emulation of
full-speed usb hub
- Massive round-trip delay over the network in terms of USB(which speaks in
nanosecond terms)
- As a result, it's possible that Android and IOS devices initiate USB reset
rather than patiently sticking up with the delay (possibly)due to the
limitation of hardware/firmware(TODO: inspect Logcat and Xcode instruments
to verify it)
- TODO: Instead of using USB redirection, USB devices can be attached to the
controller on guest start up
- There are many components that make the USB redirection over network possible.
Quite possibly, the culprit could be one of the components along the chain
- The issue is present on other proprietary solutions using VHCI as
well(FlexiHub, VirtualHere)
- meaning that it's likely the "massive round-trip delay" issue
- or it's a bug in the encapsulation protocol/implementation that's common in
all proprietary/FOSS implementation
"The chain":
```
<- NET ->
CLIENT HOST
tcp/ip tcp/ip
ssh ssh
spice+usbredir libvirt
libusb spice
virt-viewer qemu
xhci
usb-hub
usb-redir
```
"The components"
- virt
- ssh tunneling
- USB/IP
- SPICE
- libusb
- usbredir
- usb/ip
- QEMU
- xhci
- usb-hub
- usb-redir
- Apple
- Apple VHCI
|
