Windows USB integration with R4.1

It is now available to test ability to attach USB devices to Windows. It works without QWT installation via QEMU emulation. To get it works make this steps:

  • update with current-testing repos
    sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
  • install advanced variant linux stubdomain (now available only in current-testing repos):
    sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing xen-hvm-stubdom-linux-full
  • update and restart sys-usb with current-testing repos too
  • enable feature to windows qube
    qvm-features [windows qube] stubdom-qrexec 1

Few words about our experience how it works.

First need to quote warning from QEMU docs: “This is an experimental feature. QEMU will slow down when using it. USB devices requiring real time streaming (i.e. USB Video Cameras) are not supported yet.”

We saw cameras that work quite well and other that work with lags and some that don’t work at all. Sometime it requires additional memory to stubdomain over default 128M (qvm-prefs stubdom_mem).

For windows 7 it needs to install drivers, we was successful with these ones. Windows 10 works out of the box.

Sometime it requires to detach and attach device to get it works.

For some devices you have to re-plug it physically after safely removing in Windows.

Log messages could be found in files

bash: qvm-feature: command not found

still trying to get it to work

fixed typo, thanks.

I’m getting an error:

No match for argument: xen-hvm-stubdom-linux-full

try --refresh flag.

Can you give me the full command-line? I don’t know where to put the --refresh flag.

sudo qubes-dom0-update --refresh --enablerepo=qubes-dom0-current-testing xen-hvm-stubdom-linux-full
Returns the same error: “No match for argument: xen-hvm-stubdom-linux-full”

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --refresh xen-hvm-stubdom-linux-full

Same error:
No match for argument: xen-hvm-stubdom-linux-full

can you place full output

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --show-output --console xen-hvm-stubdom-linux-full

I’m doing this on dom0:

$ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --show-output --console xen-hvm-stubdom-linux-full
[long list of parameters]
dnf install: error: unrecognized arguments: --show-output --console

Are you sure you on r4.1?
rpm -qi qubes-release ?

1 Like


Version: 4.0
Release: 10

Source RPM: qubes-release-4.0.10.src.rpm

How do I update to 4.1?

1 Like

Thank you. Downloading now. Since it’s a clean install, I should be able to test by Wednesday.

1 Like

More progress, but still hitting a stumbling block.

  1. Downloaded and installed (Painless.)
  2. Tried to install windows.iso. Fails to install. I’m using the exact same steps I used to install it under Qubes 4.0.x, but I never even see the desktop starting.
  3. Installed updates on dom0: sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
  4. Installed new stub (it installed!) on dom0: sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing xen-hvm-stubdom-linux-full
  5. With the Win10 cube created, ran on dom0:
    qvm-features Win10 stubdom-qrexec 1
  6. Re-tried the install from iso. Still failed the same way (no display)
  7. Since I’m not seeing a display, tried to force one on dom0:
    qvm-features Win10 gui 1
    Still fails.

Looking at the logs, /var/log/xen/console/guest-Win10.log ends with:
[timestamp] Debian GNU/Linux 10 Win10 hvc0
[timestamp] (blank line)
[timestamp] [press ENTER to login]
[timestamp] (blank line)

This is a new twist… I’ve never seen a Windows HVM boot-from-ISO ask for me to press enter to login. Also, there is no console window for pressing enter. Help?

More info about failing to install Windows.iso on Qubes 4.1(Beta).

  1. My configuration:
    I downloaded the Windows 10, English, 64-bit ISO from Microsoft.
    Renamed it to “windows.iso”.

  2. Copied it to a USB and mounted the USB in Red.
    sudo mkdir /mnt/usb; sudo mount /dev/xvdi /mnt/usb
    ls of /mnt/usb shows the file windows.iso

  3. Create new Qube: Win10, color Blue
    Private Storage 8G
    System Storage 60G
    Initial memory: 4096 MB
    Include in memory balancing: UNCHECKED
    Mode: HVM
    Click “Apply”

  4. Boot from CDROM
    Specified Red /mnt/usb/windows.iso
    It sees it, tries to boot, then either aborts (shuts down) or hangs (waiting to press ENTER).

Looks like you created vm based on debian 10 with Win10 name. Try this way:
dom0: qvm-create --standalone --property virt_mode=hvm --property memory=4096 --property maxmem=0 --label blue win10


  1. My create-qube definitely says Fedora as kernel. Not sure why the error says Debian. Nothing in the settings says Debian is selected. Even the template default says Fedora.

  2. Ran your command-line. It created the qube. HOWEVER, the settings for that qube says initial memory “400 MB” (not 4096). VM templates still say Fedora. I changed the RAM to 4096 and Apply.

  3. Told it to boot from CDROM, Red /mnt/usb/windows.iso. This time, a text window popped up briefly, then vanished.

  • guest-win10-dm.log ends with a segfault right after “br0: port 1(eth0) entered disabled state”.

There is a button “Boot qube from CDROM” in Advanced tab of Qubes Settings

  1. I rebooted the box (just to start with everything fresh).
  2. Deleted all windows qubes.
  3. Re-ran your command to create the cube on dom0: qvm-create --standalone --property virt_mode=hvm --property memory=4096 --property maxmem=0 --label blue win10
  4. Mounted the usb drive into Red as /mnt/usb/
  5. In qube manager, went to settings, increased system disk space to 60G. (It defaults to 10G, which is too small for a Windows installation.)
  6. In the advanced tab, selected “Boot qube from CDROM”. Selected Red and /mnt/usb/windows.iso. Then it boots.
    Notification says the iso is available.
    Notification says the qube is starting.
    Text window briefly pops up (less than 2 seconds, not long enough to read).
    Then nothing. It appears to hang.

Looking at the logs:

  • guest-win10.log: Shows expected startup sequence. No issues.
  • guest-win10-dm.log: Long file. there’s a part that says === Press enter for shell ===. Then it allocates the gui and socket. Then br0: port 2 entered disabled state, vif7.0-emu left promiscuous mode, and br0 port 2 entered disabled state. This then repeats with br0: port 1 (entered disabled, left promiscuous, entered disabled). Then comes:
    qemu[230]: segfault at 0 ip [hex] sp [hex] error 4 in qemu[hex] Code: [long hex bytes]

At that point, the win10 qube is left running, but it’s dead. No gui, no installation, the USB isn’t being accessed (because it’s LED isn’t blinking).

1 Like