It looks that, due to lack of thorough testing and the set of circumstances, I brought confusion as well as wrong conclusions into the issue, and I apologize for that.
Lack of thorough testing - I wasn’t aware of uas and usb-storage.
Set of circumstances - some of my usb hdds don’t support uas, and they didn’t make any trouble while attaching to AppVms, so I brought wrong conclusion that attaching hdds via USB to Linux AppVMs works, and I am not sure anymore if it ever worked with USB 3.0 hdds. Attaching those uas devices via qvm-block for sure worked to Linux, and for >2TB did not to Win7 qubes, and for the latter qube probably because it was broken somehow (another set of circumstances).
Now I have tested it enough to correct my statement.
Now:
-
It is possible to attach all devices via qvm-block to all AppVMs
-
It is possible to attach all usb-storage devices (USB 2.0 external HDDs) via qvm-usb to all AppVMs regardless of the controller they are attached to.
-
It is not possible to attach any uas devices (USB 3.0 external HDDs) via qvm-usb to any AppVM on some controllers they are attached to (USB 3.0 controllers/hubs/ports).
-
It is not possible to attach some uas devices (USB 3.0 external HDDs, >2TB) via qvm-usb to win 7 qube regardless of the controller they are attached to.
-
It is possible to attach some uas devices (USB 3.0 external HDDs <2TB) via qvm-usb to win 7 qube on some controllers they are attached to (USB 2.0 controllers/hubs/ports).
Now, what might be interesting in order to identify the issue is that (on USB 3.0 controller/port):
-
lsusb -t
in sys-usb gives
Port x: Dev y, If 0, Class=Mass Storage, Driver=uas, 5000M
as well as
lsmod | grep usb
which gives
usb_storage 81920 1 uas
but,
- Prior to attaching hdd to an AppVM, in that AppVM
lsmod | grep usb
gives
usb_storage 81920 1 uas
usbip_core 40960 1 vhci_hcd
After attaching HDD to that AppVM, it disappears from the block devices list in dom0’s device widget (is this expected? Please answer) and in sys-usb
lsusb -t
now gives
Port x: Dev y, If 0, Class=Mass Storage, Driver=, 5000M
Is this expected? Please explain.
while in AppVM
lsusb -t
it now gives
Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M???
So, why the device is recognized as uas in sys-usb before attaching, and as usb-storage in AppVM? Is this expected? Please explain.
What confuses me even more is that
sudo dmesg | grep “UAS”
in AppVM gives:
[ 3525.722933] usb 2-1: USB controller vhci_hcd.0 does not support streams, which are required by the UAS driver.
[ 3525.722936] usb 2-1: Please try an other USB controller if you wish to use UAS.
In APPVM
sudo fdisk -l, or
sudo lsblk
don’t recognize hdd, so I’m into situation for which I haven’t found a solution on the internet: how to mount a drive that is recognized by lsusb, but not by fdisk or lsblk.
After dettaching hdd from AppVM, in sys-usb hdd is also seen only by lsusb, but not fdisk or lsblk. and the Driver is stil empty, neither uas nor usb-storage. The only way to get it back and make it usable to any qube is to restart sys-usb, or to physically re-plug the hdd.
I’d be very grateful if you could teach me how to mount drives that are seen by lsusb but not by fdisk or lsblk, and to explain dilemmas I asked for above.