Well, I’ve bee waiting for 4 years v4.1 to come in order to fully transit to Qubes OS (I simply need Windows for some apps that have no alternatives in Linux world, just like Qubes has no alternative in OS world), so what could be “some time” more, haha.
Thanks for your patience and time.
Link moved, but warning persists: qemu/docs/system/devices/usb.rst at master · qemu/qemu · GitHub
Just FYI,
Brendan
@jevank -
I haven’t tried to reproduce this, but my hunch is this is due to UAS requirements for > 2TB volumes and lack of UAS support under Windows 7.
Other explanations could exist though…e.g. perhaps a hard limit somewhere in the usbip or qemu stack of 2TB per mass storage device?
Looks like the linux kernel got UAS support in version 3.15.
Might be interesting to disable UAS/UASP for that device in the source VM (sys-usb or dom0) and see if that addresses the issue? E.g. via How to disable USB Attached Storage (UAS) - Leo's Notes
B
Thanks, but I have no ability to edit post. I’ve tried to remove unnecessary testing updates.
We use config with disabled UAS and it helps for some devices with USB Streams support. But this case doesn’t look similar because device works fine with linux-based VMs. Virtual USBIP controller (vhci) in 5.10 doesn’t support USB streams as I remember. So I’m still thinking kernel version might be a problem. I saw PR with stubdom updated components, but have no time to test it yet.
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.
In current-testing repo it is now available stubdomain with updated components including kernel, pulseaudio and QEMU (thanks to @fepitre). Quick testing shows much more clear sound with Windows and some VM performance improvements with USB attached devices.
@enmus if you see messages like this in dmesg log while attaching to Linux-based VMs than UAS is a problem. It might be possible to build guest VM kernel w/o UAS support to usb-storage driver instead for all USB storage devices.
[ +0.029211] usb 2-1: USB controller vhci_hcd.0 does not support streams, which are required by the UAS driver.
[ +0.000029] usb 2-1: Please try an other USB controller if you wish to use UAS.
1 Like
Will that degrade performance of HDDs?
Audio is indeed much, much more clearer, but very choppy and lagging while System Interrupts and audiodg.exe take 15-25% CPU.
Is this enough for now?
B
Oh, sorry. I thought you wanted a feedback about your suggestion regarding disabling uas.
Oh that’s absolutely useful!
Sorry, just wanted to be sure you had a workable system. 
@jevank and the Qubes team will likely track the issue with streams (and therefore UAS) support within the USB->VMs feature set (e.g. kernels, stubdomains, usbip, etc.).
B
I am having several problems with usb integration in qubes 4.1. I initially wrote in another post in a somewhat rambling manner, apologies can you delete, not having found this post immediately. I am trying to write the issue more clearly now.
I installed a fresh version of Windows LTSC as a Standalone VM after upgrading to qubes 4.1 from 4.0. In the previous version, the VM was working perfectly.
I followed the tutorial to install @jevank qubes-windows-tools-cross, which I also installed in dom0, and I had also already installed the package xen-hvm-stubdom-linux-full. I also installed the xenbus and xenvbd drivers as suggested in another guide.
My qvm-features output is
stubdom-qrexec 1
rpc-clipboard 1
os Windows
audio-model ich6
The audio works quite well and the VM starts up without any problems, suggesting that the gui features have been taken well. However, when I try to copy any files from another vm the output is:
Filed to execute qubes.Filecopy (From nameVM to namewindowsVM).
The content of the policy is $anyvm $anyvm ask. Modifications to it have not produced any results.
What could this be about? Should I perhaps modify the new 5.0 policy in some way? However, I still don’t quite understand how to do this. Should I install additional drivers? Could it be something to do with how I created the VM?
Any help is appreciated, thanks in advance.
Which tutorial and which version?
Which version too?
Which guide and why didn’t you use the ones provided with QWT?
Which policy, and what is the whole content of it?
Which modifications?
Sorry for my english, the tutorial is the readme file on github . It builded the versiom 4.1.67-1
Version 1.2.3-1fc32 enabling current-testing repo
At the beginning, I start from the official qubes-os page which link me to this github, that makes me install a previous version of QWT.
Only after a while and a deeper searching I finally found the QWT from tabitpro team.
I haven’t been able to read the forum for a while.
The qubes.Filecopy policy Which I mentioned above and which gives me the error. I tried some changes to allow the copy to the winVM without success, but always restoring the file.
The complete content is:
disp-mgmt-fedora-33 fedora-33 allow,user=root
disp-mgmt-debian-10 debian-10 allow,user=root
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect
## Please use a single # to start your custom comments
$anyvm $anyvm ask
Just a few days ago I’ve installed Windows 10 with QWT on Qubes 4.1 current-testing according to these guides:
The file copy works fine and I didn’t change any policies.
Also I didn’t build the QWT ISO by myself but got the ISO with latest version 4.1.67-1 from github as stated in the guide above.
Try to install the Windows HVM by following the guides above.
It is available latest qubes-windows-tools-4.1.68 in current-testing repository now.
[user@dom0 ~]$ qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
3 Likes
I don’t have such a policy on my 4.1?
In 4.1 this is found in 90-default.policy and it is by default set as
# File copy/move
qubes.Filecopy * @anyvm @anyvm ask
And if you are running fedora-33, it is EOL and you should upgrade it to at least fedora-34, although I’m using fedora-35 since last year and find it great.
Maybe it’s a problem somewhere around this?
I had already set up fedora-34, thanks for pointing that out! I directly deleted the policy, which was probably left over from 4.0. After that I updated QWT to dom0 and did the windows update, but nothing still gave me the same qubes.Filecopy error.
So I decided not to be stubborn and to reinstall a WinVM, this time installing QWT cross IMMEDIATELY BEFORE doing any other action (Activation, debloating, installing programs, changing qvm-features etc). As also written in the Windows installation instructions in qubes.
Now everything works as it should. Also, no appmenus command needed. Thanks to the tabita-pro team for their work and you all who advised me.