Windows 11 in Qubes

[alimirjamali]

@tempmail

I apologize if I missed it, but are we still talking here about Win HVMs only, or about Win templates too? Has anyone tested the speed of external storage devices attached (block or attached as USB)? For me, the latter is the most important, because at the moment with v4.1.6x it remains on USB 3.0 speed, which is painful.

Windows 11 could only run as HVM (regardless of being Standalone, TemplateVM or AppVM). Based on what I have seen in the commit messages and notes, having it as TemplateVM/AppVM is a target.

I have no opinion on the speed of attached devices at this moment, but I will be reviewing the PRs once more next week during writing the weekly newsletter. If I find a clue on it, I will mention it.

[aronowski]

@tempmail

Has anyone tested the speed of external storage devices attached (block or attached as USB)?

Result with whole USB device attached:

------------------------------------------------------------------------------
CrystalDiskMark 8.0.5 x64 (C) 2007-2024 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):    74.037 MB/s [     70.6 IOPS] <111925.45 us>
  SEQ    1MiB (Q=  1, T= 1):    81.787 MB/s [     78.0 IOPS] < 12788.69 us>
  RND    4KiB (Q= 32, T= 1):     1.961 MB/s [    478.8 IOPS] < 66226.17 us>
  RND    4KiB (Q=  1, T= 1):     2.175 MB/s [    531.0 IOPS] <  1866.71 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):    35.231 MB/s [     33.6 IOPS] <232878.52 us>
  SEQ    1MiB (Q=  1, T= 1):    34.603 MB/s [     33.0 IOPS] < 30156.04 us>
  RND    4KiB (Q= 32, T= 1):     1.639 MB/s [    400.1 IOPS] < 79182.50 us>
  RND    4KiB (Q=  1, T= 1):     1.214 MB/s [    296.4 IOPS] <  3346.13 us>

Profile: Default
   Test: 128 MiB (x5) [D: 88% (13/15GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2025/04/08 14:07:50
     OS: Windows 10 Enterprise LTSC 1809 [10.0 Build 17763] (x64)

Result with the sda1 block device attached:

------------------------------------------------------------------------------
CrystalDiskMark 8.0.5 x64 (C) 2007-2024 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):   105.063 MB/s [    100.2 IOPS] < 79189.56 us>
  SEQ    1MiB (Q=  1, T= 1):   105.473 MB/s [    100.6 IOPS] <  9919.55 us>
  RND    4KiB (Q= 32, T= 1):     3.821 MB/s [    932.9 IOPS] < 34165.54 us>
  RND    4KiB (Q=  1, T= 1):     3.968 MB/s [    968.8 IOPS] <  1022.07 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):    37.120 MB/s [     35.4 IOPS] <220265.55 us>
  SEQ    1MiB (Q=  1, T= 1):    36.280 MB/s [     34.6 IOPS] < 28657.21 us>
  RND    4KiB (Q= 32, T= 1):     1.781 MB/s [    434.8 IOPS] < 73066.82 us>
  RND    4KiB (Q=  1, T= 1):     1.710 MB/s [    417.5 IOPS] <  2383.09 us>

Profile: Default
   Test: 128 MiB (x5) [D: 88% (13/15GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2025/04/08 14:20:45
     OS: Windows 10 Enterprise LTSC 1809 [10.0 Build 17763] (x64)

@tempmail

about Win templates

That’s how the tests above have been made, i.e. installing Windows as a template, installing the brand-new QWT, creating an AppVM from that template and running CrystalDiskMark from the user directories on the Q: drive. The attached screenshot shows, that this drive is visible in that AppVM from Windows Explorer, the Users folder holding, among others, the user’s data.

[GWeck]

I have checked now for Windows 10 under Qubes R4.3 and R4.2, as well as for Windows 11 under Qubes R4.2. The results are quite promising, but I will continue testing.

Making the new version of QWT available under Qubes R4.2 should not prove to be too difficult. I tried it in two ways.

• Just extracting the file qubes-tools-4.2.0.exe from the ISO located in /usr/lib/qubes/ in Qubes R4.3 and then copying it to a Windows 10 or 11 VM under Qubes R4.2 allows to install QWT there, and, so far, it is working.
• Otherwise, the ISO file itself can be copied from R4.3 to R4.2 into the same location, and a symbolic link qubes-windows-tools.iso pointing to it can be created. It works, even if you change the name of the ISO from qubes-windows-tools-4.2.0.1.fc41.iso to qubes-windows-tools-4.2.0.1.fc37.iso. Afterwards, the ISO is mounted in the Windows VM if it is started with --install-windows-tools, just like in the good old times.

So it would be probably enough just to recreate the installation RPM file for dom0.

[pypy]

Ah. My mistake. Thanks for the quick reply! It is much appreciated <3

[tempmail]

@aronowski

Result with…

Thanks for the tests. This still seems not promising though…? I wonder why the speed is so poor… Does it have anything with qrexec maybe and with its possible limitations?

[pypy]

Hi GWeck,

How does one extract /usr/lib/qubes/qubes-tools-4.2.0.exe from the R4.3 .iso? I burned the QUBES-4-3-202504082200-X86-64.iso to a usb drive (using dd). I can explore that usb drive using xarchiver. I can locate /usr/lib but there doesn’t appear to be /usr/lib/qubes in it.

[tze]

I just downloaded the 4.3 rpm file from the repo: https://yum.qubes-os.org/r4.3/current-testing/dom0/fc41/rpm/qubes-windows-tools-4.2.0-1.fc41.noarch.rpm
And was able to successfully install it in 4.2 dom0

[aronowski]

I’d be up to performing more tests with different hardware, both computers and USB sticks or disks, to compare with mine - I didn’t have high expectations, considering these tests were performed on a laptop from 2012, and a pretty worn-out USB stick.

[GWeck]

There is probably no QWT yet in the R4.3 Qubes ISO. You’ll have to install this Qubes version and then perform an update of dom0, which will install the QWT ISO /usr/lib/qubes/qubes-windows-tools-4.2.0.fc41.iso. This ISO contains the qubes-tools-4.2.0.exe in its main directory.

[alimirjamali]

Download the RPM files mentioned in the post after yours. Then extract it with:

rpm2cpio filename.rpm | cpio -idmv

And you will have the ISO. Follow GWeck’s guidelines on where to put the iso file. Or you could mount the iso file and copy the .exe file.

[GWeck]

Some results on using the new version of Qubes-Windows Tools, tested with Windows 10 22H2 and Windows 11 24H2 in Qubes R4.2.4 and R4.3 Alpha, both with templates and AppVMs and having the qvm-features parameters gui and gui-emulated both set to 1:

• QWT can be installed, using the default of enabling all options, including the optional Xen PV drivers.
• So far, the full functionality seems to be available, including switching to and from seamless mode.
• Switching an AppVM from a Windows 10 to a Windows 11 template or vice versa does not work, because the other Windows version cannot access the users profile and fails to log in.
• Changing the screen resolution to some sensible value is necessary after the installation, as the VM changes the initial window size to one using the full screen width. If the VM is shut down in non-seamless mode and then restarted, it comes up with is previously used windows size.
• After switching to seamless mode, the window menu may be called by typing the keyboard Windows key. The menu comes up with the correct contents, but its border is wider than the real menu size.
• Switching back from seamless to non-seamless mode again sets the window size to the large value and not to the previously used size. In Qubes R4.3, changing the window size now by dragging the window border may result in a partially clobbered (W11) or flickering (W10) window. In this case, the VM becomes unresponsive, can no longer be switched to seamless mode or shut down; it has to be killed.
• The Windows device manager shows two inactive devices:
  • XP0001 XENVIF 0 as a subdevice of the Xen PV network class
  • XP0001 XENBUS CONS as a subdevice of the Xen PV Bus (0001)
    The cause of the inactivity is told as " no compatible drivers for this device were found". But the network is running!

So, again, the new version is much better than the previous one, but not yet complete.

[marmarek]

@GWeck

Switching an AppVM from a Windows 10 to a Windows 11 template or vice versa does not work, because the other Windows version cannot access the users profile and fails to log in.

That’s probably not going to work, at least not without explicit support for such case (which may involve some startup service adjusting file permissions).

@GWeck

The menu comes up with the correct contents, but its border is wider than the real menu size.

Yeah, Omeg spent quite some time trying to fix that, without success so far. The windows menu is a very weird window…

@GWeck

Changing the screen resolution to some sensible value is necessary after the installation, as the VM changes the initial window size to one using the full screen width.

Do you have some suggestion what a “sensible value” could be? A full screen IMO is not very bad, if only taskbar wouldn’t hide outside of the screen due to window being too tall (with default xfce panel being on top).

@GWeck

The Windows device manager shows two inactive devices:

• XP0001 XENVIF 0 as a subdevice of the Xen PV network class
• XP0001 XENBUS CONS as a subdevice of the Xen PV Bus (0001)
  The cause of the inactivity is told as " no compatible drivers for this device were found". But the network is running!

Not sure about XENVIF one, but CONS one is I think expected to have no driver.

@GWeck

Switching back from seamless to non-seamless mode again sets the window size to the large value and not to the previously used size. In Qubes R4.3, changing the window size now by dragging the window border may result in a partially clobbered (W11) or flickering (W10) window. In this case, the VM becomes unresponsive, can no longer be switched to seamless mode or shut down; it has to be killed.

Do you see some errors in QWT logs? See Qubes Windows Tools (QWT) | Qubes OS

[alimirjamali]

@marmarek

Do you have some suggestion what a “sensible value” could be? A full screen IMO is not very bad, if only taskbar wouldn’t hide outside of the screen due to window being too tall (with default xfce panel being on top).

May I suggest the official minimum system requirement (i.e. 720p). If users want a higher resolution, they could readjust later?

[GWeck]

720p should work on most Monitors.

[pypy]

It worked! And I learned some things about .rpm files maybe too. Thank you for your help.

[GWeck]

@marmarek

That’s probably not going to work, at least not without explicit support for such case (which may involve some startup service adjusting file permissions).

The AppVM contains the files NTUSER.DAT etc., i.e., the registry part HKCU, and if that or something dependent on it is different across Windows versions, then there is little chance to switch AppVMs so easily. On the other hand, just creating a new empty AppVM and then copying the Documents folder and possibly some parts of the AppData folder from the old to the new AppVM might be enough. So I doubt if it is worthwhile to follow this any further.

@marmarek

Not sure about XENVIF one, but CONS one is I think expected to have no driver.

Tested with W10 on R4.3: Using the drivers from the Xen website, the console driver can be installed and then shows as a working device Xen PV Console #0. The VIF driver fails to install from the device manager, but can be installed manually - but the device manager still claims that there is no driver for this device. What the hell is this?

@marmarek

Do you have some suggestion what a “sensible value” could be? A full screen IMO is not very bad, if only taskbar wouldn’t hide outside of the screen due to window being too tall (with default xfce panel being on top).

Many systems, including Windows, come up with an initial screen size of 1024 x 768, which should be o.k. even for ancient notebooks - even those that probably would not be fit for Qubes. So an initial setting of 1024 x 720, which is slightly less than 720p, could be a sensible value, leaving even some space for the Qubes task bar.

Just an idea …

@marmarek

Do you see some errors in QWT logs?

Here are two logs, both from W10 on R4.3, but probably from working resize events:
gui-agent-20250411-124544-4136.log (1.5 KB)
gui-agent-20250411-124545-4300.log (7.6 KB)
In the case of the resizing after the switching to and from seamless mode, there are also some logs from the gui-agent, but they are all empty. Maybe the agent is dead at that time and can no longer write logs? By the way, at one of these tests, the VM died only after the second resizing after the seamless switch.

[SteveC]

I know this is slightly off topic but will windows 7 be affected by any of this?

[alimirjamali]

There are some posts in the thread which (almost) rolls-out the possibility of official Windows 7 support (sadly)

Windows 11 in Qubes

Ok, so it looks like there is some API change in Windows between 7 and 10 that makes drivers built for 10 incompatible with 7. Given Windows 7 is not supported by MS for a long time already, how important is to keep QWT compatible with Windows 7?

Windows 11 in Qubes

The “video driver” from new QWT cannot work on W7, for similar reasons why the driver from W7 in old QWT didn’t work in W10. Windows completely changed graphics driver interface between those versions (XPDM vs WDDM). And in fact the new gui-agent-windows doesn’t use custom video driver at all, it uses native APIs present in W10 that aren’t available in W7.

Windows 11 in Qubes

I’m not excluding a possibility for publishing community W7 QWT build. But unlikely to be signed with official cert (when that will happen), as that will implicitly take responsibility for this build - not part of community-supported packages. Shouldn’t be worse than the previous QWT for W7 though.

[tanky0u]

I just skimmed through ~30 or so messages in this thread.

@alimirjamali

It is only available for Qubes OS R4.3 Alpha at this moment.

Just to verify, having this installed on my QubesOS 4.3 will allow me to qvm-copy files to the Windows 11 HVM’s. is this right? Will it also allow me to plug USB devices to the Windows 11 HVM’s from sys-usb?

Edit: wait, I noticed that I am on QubesOS 4.2.4, so this tool is inaccessible to me?

[alimirjamali]

@tanky0u

having this installed on my QubesOS 4.3 will allow me to qvm-copy files to the Windows 11 HVM’s. is this right?

I have not tested it personally but the answer should be yes. And the other way:

@tanky0u

Will it also allow me to plug USB devices to the Windows 11 HVM’s from sys-usb?

Again, the answer should be yes.