Windows 11 in Qubes

General Discussion
101

Lets track it properly: HVM emulated display freezes, "Can't dump surface without grant refs allocation!" error in stubdomain log · Issue #9847 · QubesOS/qubes-issues · GitHub

BTW, you can see the issue on the video @alimirjamali linked above, the spinner during Windows startup stops spinning.

2 Likes
102

Several problems with the new graphics driver are connected to the values of the qvm-features parameters gui and gui-emulated. I did the previous tests in Qubes R4.2.4 with both parameters unset, as they had been during the creation of the W10 and W11 VMs. Setting and unsettling them changed the behavior of the VMs. The most stable behavior occurs if gui is set, i.e. 1, and gui-emulated is unset, i.e. blank. Then the graphics functions work, and seamless mode can be switched on and off from the Qube Manager. To avoid the problems described above, it may be advisable to set these parameters during QWT installation accordingly.

Still, several problems remain:

  • Booting the VM does not show the initial boot screen; only when Windows has started, the VM shows a window. This probably is to be expected, as no emulated graphics are available with this setting.
  • Functions may be extremely slow, especially for W11. For instance, starting the Explorer may take 10 seconds in W10 and even slightly more in W11.
  • In non-seamless mode, the VM starts with full-screen resolution, which is too much because of the Qubes task bar. The result is that the Windows task bar is not displayed.
  • In W11, screen refresh may work or not, having the funny effect that sometimes a rectangle containing parts of the screen background is shown instead of a context menu.
  • When pressing the Windows key in W11 in seamless mode, in order to display the Windows menu, two black rectangles are shown, one of them containing the menu or at least a part of it, and the menu may work or not.
  • Changing the VM’s screen resolution, either via the corresponding Windows function or by dragging the window borders, is somewhat dangerous. It may work, but it may lead to an unresponsive VM that only can be killed. Trying to switch such a broken VM from the Qube Manager will kill the Qube Manager, and trying to shut it down from the Qube Manager results in an error message. journalctl shows that a process qubes-qube-mana has crashed, the relevant part of the journal is here:
    journalctl.log (180.2 KB)
  • Changing the size of an application window in W11 in seamless mode may leave the application in its original size, but fill the rest of the window with parts of the screen background picture and leave the VM in the same broken state.
  • After several reboots, the broken VM may be working again.
  • When switching back from seamless mode to no-seamless mode, the VM’s window starts again at full-screen resolution and not at its previous resolution. So it has to be resized again
3 Likes
103

Thanks for testing!

This is exactly what is done during QWT installation already, no?

Yes, this is expected. If you want to access emulated graphics anyway (for example to see why VM takes a long time to start), you can with qvm-start-daemon --force-stubdomain VMNAME.

I have noticed this issue too. Interestingly, on 2256x1504 resolution, Windows 11 appears to max out at 1920x1200, so the task bar is visible.

I don’t think it’s just about refresh. Once I got an interesting effect when using search in the start menu - most of the menu was visible normally, but the search bar at the top had only text I entered, without any borders or other parts - it looked like text floating above the start menu. I’ll make a screenshot when I get this effect again.

1 Like
104

I checked now with a W11 system that originally had both parameters undefined. Installing QWT set gui to 1 and gui-emulated to blank.

But that’s only half the way: When trying to change the screen resolution, the VM again changed into a broken state. So, currently, it is best to do all that in clones of VMs, just to survive! But fortunately, Qubes has just the right tools to do that efficiently. :grinning:

105

If it is still happening (Qube Manager crashing), I appreciate if you could run in from terminal (qubes-qube-manager) and see if prints any error log after crashing.

106

This may be the same problem as the one described in issue #8647, which was fixed for R4.3. Possibly the fix has not made it to R4.2.4.

I have opened a new issue #9852 for R4.2.4 and included the log from the qubes-qube-manager command. Somehow the error handling the does not seem to work - but I don’t speak python.

1 Like
107

That is correct. The fix for #8647 was merged on 14th February 2025 and released to r4.3 testing repository on 16th February. It usually takes weeks to months for fixes to be back-ported to r4.2. For example the current version of qubes-manager in r4.2 stable should be 4.2.9-1 if I am not mistaken. And it dates back to September 2014 2024.

108

really so old???

109

Yes. The newest version of qubes-manager I can find for both stable and testing for r4.2 is from September.

110

I think he was surprised that you said 2014. Evidently a typo.

3 Likes
111

Well, I must admit that both QManager and qui-device more and more act like they are exactly from 2014.

5 Likes
112

There are chances …

(SCNR)

2 Likes
113

The fix is merged, package should be in current-testing soon.

3 Likes
114

I checked R4.3 now with a Windows 7 VM (including the old QWT 4.1.69-1, without graphics driver). It works now. :+1:

I’ll try W10 and W11 soon, including the new GitHub version of QWT (starting on March 5, I believe). See what happens; I’ll report on it.

3 Likes
115

In R4.2, I checked the new GitHub version of QWT with W10 and W11, which shows a lot of progress. Here are some findings:

  • In both W10 and W11, resizing the screen is now working. Dragging the screen border jumps to the next resolution defined in Windows.
  • Switching to and from seamless mode is working, too.
  • Restarting Windows in non-seamless mode uses the screen size that was in effect in the previous run.
  • The long delays until some applications started in seamless mode have been shortened considerably. In W11, it is still somewhat slower than in W10, but that system is terribly slow, anyhow, even on bare metal.)

There are still some problems remaining:

  • QWT is still installed in C:\QubesWindowsTools\, and not in C:\Program Files\InvisiblethingsLab\QubesWindowsTools\, where it should be.
  • When switching back from seamless to non-seamless mode, a large (1920 x 1200) Window is still created, but now it can be reduced manually to some smaller size, if necessary. If the previous size is not remembered, it may be preferable to set it explicitly to such a smaller value, like 1280 x 1024, which would be better for installations using a smaller screen.
  • Opening the Windows menu in seamless mode may have some funny effects:
    • In W10, a partial menu may be displayed, showing only a few commands. Somehow, the menu structure seems to be clobbered, because this partial menu still remains even after switching to non-seamless mode.
    • In W11, the VM seems to have switched back to non-seamless mode, dom0 complaining that it tried to create a huge window and that, for that reason, the override_redirect flag has been unset. Moving the cursor turns back to seamless mode, but just shows some background picture where the menu should be.

So, this new version of QWT is a huge improvement, but there is probably still a lot to do, like one always has to expect in the Windows environment! :rage:

4 Likes
116

I have checked now W10 and W11 under Qubes R4.3, both with the new Qubes Windows Tools. Both can be started and switched between seamless and non-seamless mode. So far, they behave similarly to the VMs under R4.2.4, but I’ll have to do more testing. Stay tuned!

4 Likes
117

I have been informed that as of today, Qubes Windows Tools 4.2.0-1 is packaged for r4.3 and is available in its (default testing) repository. It can be installed in dom0 via:

sudo qubes-dom0-update qubes-windows-tools`

It is not necessary to download the nightly builds anymore (it is still possible if anyone desires to do so).

In the meantime, the test results from the latest openQA run for Windows 11 installation with QWT is all green. Which is even more promising that the test results for Windows 10. Here is the video.

5 Likes
Qubes OS updates Weekly Review - Y2025-W15
118

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.

1 Like
119

When I tried this, the CD-ROM drive in the Win11 VM just had the README, which states “Qubes Windows Tools are currently unavailable due to security concerns”. I’m not sure if this is peculiar to just my install, or if the update has not propagated to the servers yet. Any input is greatly appreciated.

Command line inputs for troubleshooting.
In dom0:
sudo qubes-dom0-update qubes-windows-tools
It downloaded:
qubes-windows-tools-4.1.70-1.fc37.noarch
Then also from dom0 ran:
qvm-start <MySpecificWin11VMname> --install-windows-tools

1 Like
120

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

I was told that if there is enough demand and interest, the new QWT will be backported to R4.2 as well.

2 Likes