Link moved, but warning persists: qemu/docs/system/devices/usb.rst at master · qemu/qemu · GitHub
Just FYI,
Brendan
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,
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.
Will that degrade performance of HDDs?
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.
Audio is indeed much, much more clearer, but very choppy and lagging while System Interrupts and audiodg.exe take 15-25% CPU.
Now:
- It is possible to attach all devices via qvm-block to all AppVMs
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.
I followed the tutorial to install @jevank
qubes-windows-tools-cross
Which tutorial and which version?
xen-hvm-stubdom-linux-full
Which version too?
I also installed the
xenbus
andxenvbd
drivers as suggested in another guide.
Which guide and why didn’t you use the ones provided with QWT?
The content of the policy is
$anyvm $anyvm ask
.
Which policy, and what is the whole content of it?
Modifications to it have not produced any results.
Which modifications?
Which tutorial and which version?
Sorry for my english, the tutorial is the readme file on github . It builded the versiom 4.1.67-1
Which version too?
Version 1.2.3-1fc32 enabling current-testing repo
Which guide and why didn’t you use the ones provided with QWT?
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.
Which policy, and what is the whole content of it?
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:
Installing a Windows VM
=======================
You can install Windows just like any other OS as an [HVM](https://www.qubes-os.org/doc/hvm/), if you just want something simple and you can live without some features. This works for Windows XP, 7, 10 and 11, and it may work for Windows 8 and 8.1, although this has not been tested.
You will get an environment in which basic functions are supported, but integration into the Qubes environment is rather restricted. The following functions will work right out of the box:
- display (1440x900 or 1280x1024 are a nice fit onto FHD hw display)
- keyboard (incl. correct mapping), pointing device
- network (emulated Realtek NIC)
- audio output and input (available even without QWT installation if `qvm-features audio-model` is set as `ich6`)
For better integration, a set of drivers and services, called Qubes Windows Tools (QWT) is available. Installation of these tools is straightforward and is described in a [separate document](https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-tools41.md). QWT’s main features are:
- copy/paste between qubes
- copy files between qubes
- attaching USB devices to the qube
- attaching block devices to the qube (XEN PV disk driver must be installed)
- automatically set up networking
- automatically set up time/clock synchronization
This file has been truncated. show original
Qubes Windows Tools
===================
Qubes Windows Tools (QWT) are a set of programs and drivers that provide integration of Windows 7, 10 and 11 Standalone, TemplateVMs and AppVMs with the rest of the Qubes system. They contain several components than can be enabled or disabled during installation:
- **Shared components (required)** - common libraries used by QWT components
- **Qubes Core Agent** - qrexec agent and services. Needed for proper integration with Qubes
- **Qubes GUI Agent** - video driver and GUI agent that enable the seamless GUI mode that integrates windows apps onto the common Qubes trusted desktop (currently only for Windows 7)
- **Disable UAC** - User Account Control may interfere with QWT and doesn't really provide any additional benefits in Qubes environment
- **Clipboard sender/receiver** - Support for [secure clipboard copy/paste](https://www.qubes-os.org/doc/copy-paste/) between the Windows VM and other AppVMs
- **File sender/receiver** - Support for [secure file exchange](https://www.qubes-os.org/doc/copying-files/) between the Windows VM and other AppVMs
- **Copy/Edit in Disposable VM** - Support for editing files in DisposableVMs as well as for `qvm-run` and generic `qrexec` for the Windows VM (e.g. ability to run custom service within/from the Windows VM)
- **Audio** - Audio support requires R4.1 and is available even without QWT installation if `qvm-features audio-model` is set as `ich6`
- **Xen PV drivers** - drivers for the virtual hardware exposed by Xen for Windows that increase performance compared to QEMU emulated devices and are required for attaching USB devices
- Base Xen PV Drivers (required): paravirtual bus and interface drivers
- Xen PV Disk Drivers: paravirtual storage drivers
- Xen PV Network Drivers: paravirtual network drivers
- Move user profiles: user profile directory (`C:\users`) is moved to VM's private disk backed by `private.img file` in `dom0` (useful mainly for HVM templates).
> **Note**: Xen PV disk drivers are not installed by default. This is because they seem to cause problems (BSOD = Blue Screen Of Death). We're working with upstream devs to fix this. *However*, the BSOD seems to only occur after the first boot and everything works fine after that. **Enable the drivers at your own risk** of course, but we welcome reports of success/failure in any case (backup your VM first!). With disk PV drivers absent `qvm-block` will not work for the VM, but you can still use standard Qubes inter-VM file copying mechanisms. On the other hand, the Xen PV drivers allow USB device access even without QWT installation if `qvm-features stubdom-qrexec` is set as `1`
This file has been truncated. show original
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.
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.
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
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
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?
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.
I checked to install QWT 4.1.68.1 over 4.1.67.1 on a Windows 7 system. The installation got stuck on trying to reinstall the PV Network Class Drivers Package. Installing without the PV Network drivers went fine, and afterward, this package could be installed without problems, by changing the QWT installation. Funny.
I’ll check with Windows 10 and 11 in the next few days.