Windows USB integration with R4.1

Correct

1 Like

Holy smokes, I am indebted to you again. It works! :smiley:

1 Like

Any chance these updates work on 4.04?

Not a chance, sorry.

1 Like

I have numerous No Match for argument lines after entering sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing but I think this is a function of a bad 4.1 migration.

Thank you @jevank

I followed these instructions explicitly for Windows 7 stand-alone HVM. I understand that you donā€™t need QWT installed to make the USB integration work, but since mine has QWT 4.1.65 installed I wanted to report in that it works with QWT so others can benefit from your work

Iā€™m running latest 4.1 testing

Hello. Thanks jevank for this great contribution. I am Qubes newbie, and I can confirm that this works without QWT - I succesfully attached external usb sound card to Win 7 cube. The sound is ā€œchopyā€, or ā€œscratchyā€ but itā€™s the same with the integrated sound card. What I havenā€™t succeeded was to attach external usb HDD, nor any other kind of block device.
Is it not possible yet, or I am doing something wrong? Widget shows that the block device is attached (bold) to the cube, but it isnā€™t seen in WIn7 cube. I have tried from the cli with qvm-block and qvm-start --hddisk commands as well, but with no luck.

Estoner mentioned qwt 4.1.65, but where I can find it?

Thank you in advance for your help.

EDIT: all my usb devices are connected via sys-usb, and are seen in Linux cubes when attached.

In case USB connectivity you should use devices from ā€˜USB Devicesā€™ section in widget, nor ā€˜Block devicesā€™. To get block devices support with Windows it needs to install Xen virtual disk device drivers, but it might (would) be unstable with hot plugging

Look at github repository, it has instructions to build and this long topic might be useful.

Thanks jevank for clarification and hints for qwt. After testing for several days, here are my findings.

  1. Created standalone Win7 SP1 cube. Fully updated, Made a backup of it
  2. I have successfully built qwt 4.1.65 and installed it. When starting the Windows VM, a pop-up with the message Failed to execute qubes.NotifyTools from <VMname> to dom0 is displayed. No significant consequences noticed.
  3. I was able to attach internal and USB hddā€™s<2TB as block devices. Fully operational and functional.
  4. Inter-vm interactions worked flawlessly.
  5. Couldnā€™t manage to attach >2TB USB hdd as a block device.
  6. Successfully finished procedure for updating xen-hvm-stubdom-linux-full following your advices, coexisting with QWT.
  7. Successfully attached all non-storage and non-streaming devices.
  8. Couldnā€™t manage to attach any USB hdd. Win 7 sees it and it starts to find the drivers, and then just gives me the error ā€œdevice unpluggedā€?
  9. ā€œOK, letā€™s try to attach all hddā€™s via qwt and the rest of usb devices via jevankā€™s methodā€. I have read whole ā€œlong topicā€ and applied:
  • qvm-prefs --set win7 qrexec_timeout 600, no luck
  • qvm-features win7 gui-emulated 0, no luck
  • qvm-features win7 gui-emulated 1, no luck
  1. Even worse, now I canā€™t attach any hdd, either as a block device, or as an usb device. If I try as a block device, it starts to attach it, and the cube window just disappears, while Qubes manager shows cube is still running and the widget is showing hdd is attached as block device. After detach it via widget, cube shuts off with a pop-up notification it is halted.
  2. Deleted Win 7 cube, and restored the fresh one from the backup, but with the same result, which leads me to think that dom0 is somehow screwed. No Qubes OS restart helps. No other action than stated here was done, I have went through whole history of commands in dom0 terminal.
  3. At the end, I tried to restore dom0 cube from the earlier working backup, which was made weeks before I started with win 7. No luck - same results.

I am too desperate, so if you, or anyone else have any thoughts on this, Iā€™d be very grateful

Does it works with linux VMs? I know some problems with such devices, but it has same errors on Linux (USB cable is bad or USB streams unsupported).

What is this about? The ā€˜gui-emulatedā€™ feature enable window from emulated video card, that couldnā€™t break smth

Check VM settings to ensure that memory balancing is disabled (Advanced Tab).

Thanks for your response!

  1. Hddā€™s are fully operational both in fedora, whonix, or debian template based vmā€™s either via usb widget, or as block devices.
  2. Memory balancing was turned off from the very beginning.
  3. In despair, I tried emulated, because Win7 cube window disappeared when attaching >2TBB usb hdd in order to try to get it back somehow - no luck as I said.
  4. New findings: if I restart Win7 cube and first try to attach <2tb usb hdd, it succeeds and is fully operational. If in addition I try to attach >2TB usb hdd, it tries to attach it, then it unplugs itself, but also it unplugs already attached <2TB usb hddā€™s, as well as all other usb devices (sometimes all at once, sometimes one at a time, after additional manual retries to attach >2TB hdd).
  5. Once self-detached from win7 cube, >2TB usb hdd is shown in the list of usb devices widget as not bold, but disappears from the list of block devices, so I have to manually unplug-plug it in back in order to be visible in the block devices list.

It is undependable of the controllers. tried them all 2.0 or 3.0, as well as all usb portsā€¦

At this point Iā€™m experimenting only with your method, qwt isnā€™t installed in the clean win7 cube restored from the backup, in order to eliminate possibility of mixing two of them to cause unpredictable issues.

I canā€™t conclude anything else, but something is related to dom0, not win7 cubeā€¦

I got you, but this means that gui-agent or vm in common is broken. In that case you could force stubdomain window to catch BSOD screen if there is internal problem.
qvm-start-gui --force-stubdomain [windows-qube]

I guess problem is with stubdomain kernel. It is 5.4 version and USBIP might has issues with new devices. Iā€™m afraid you have to live with it some time.

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:

  1. It is possible to attach all devices via qvm-block to all AppVMs

  2. 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.

  3. 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).

  4. 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.

  5. 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):

  1. 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,

  1. 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?