Testing Windows and QWT in R4.1

I prefer not to use block device hot attaching with Windows VM. Instead of it could be used persistent attach (qvm-block with -p option) or USB device attach.

After incorrect shutdown Windows usually tries to run safe mode or recovery console which doesn’t start Qubes GUI agent and qrexec services, so you can’t see VM screen. You could make this boot system screen visible with debug check option in VM settings tab or by setting ‘gui-emulated’ feature to 1:
qvm-features [windows] gui-emulated 1

That might be Windows kernel exception aka BSOD because of hot block plugging.

Stop hot attaching block devices to Windows :slight_smile:

Thanks for the response.
I have no choice; block device I want to attach is simply not USB, but internal SATA HDD, so it’s not possible to attach it as USB device.
That leaves me with --persistent option.
I couldn’t find if it’s enough to start only for the first time as:
qvm-block attach --persistent wincube dom0:sdXXXX

or I have to use this command every time I start win cibe?

If I have to start it every time, is there any automation procedure so when I start win cube from Qube Manager, it will be started with these parameters (I couldn’t find any “starting parameters” or such an option in Qubes->Settings).

Thanks in advance for your time.

EDIT: OK, I tried it and it seems to work. It looks like it is enough to use -p option only for the first time. Started cube, everything works flawlessly. Shut down the cube, started it again form Qube Manager without extra steps, only by clicking Start/Resume and it attached internal HDD again, and everything works.
Now it’s time to test your procedure for attaching USB device without qwt.
Thank you so much jevank!

Here are my findings.
My win7+qwt-4.1.65 standalone HVM on Q4.1 works flawlessly so far.

In order to enable seamless mode, there are 2 keys containing “SeamlessMode” DWORD in the registry:

  1. HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools
  2. HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools\qga

it is not enough to set the first one to “1” in order to get seamless mode. After restart, this value is reset to “0”.
If I set only the other one to “1”, I’m getting into seamless mode, and it turns out that the first one is also automatically set to “1”.
Therefore, it is not necessary to set both entries to “1”, but only the second entry.

The resolution of a seamless window is automatically set to dom0 native resolution (at least for me) no matter how big seamless window is, so simple maximize, or alt+f11 works flawlessly. So neat! I have checked this via calling “Win” key → Control panel → “Display resolution” .

In a non-seamless win7 qube, it is not possible to set resolution to dom0’s native resolution. It looks like it’s max height is lower for the height of a dom0 panel height + reserved space on it’s borders + the height of a top win7 cube window title bar. If the dom0 panel is set always to be hidden, then the resolution is automatically set to dom0 minus the height of a top win7 cube window title bar. In a fullscreen mode (alt+F11) the resolution is automatically set to dom0 native resolution.

WARNING: If you have set some startup items/apps in your win 7 cube (like I did), beside chosen app started in seamless mode, all other startup apps will also start in their own seamless windows, and you might run into unexpected/unknown issues (to me). If startup apps are set as minimized to tray / hidden, their windows will not be visible but they can be called via their keyboard hotkeys if there were ones.
If you don’t run into issues with this (like I didn’t) just close all startup apps seamless windows and you can continue to work in a desired/chosen app seamless window without an issue.

I tested now the new version 4.1-65.1, provided this week by @jevank. What was working in the previous build is still working. Additionally, now all Windows versions including 7 allow programs to be started from the XFCE menu and from starter icons placed on the desktop. So now there is a way to start applications in Windows 7 seamless mode, if no window of this VM is displayed. Still, it would be helpful if the Windows Start button was displayed in seamless mode, like it was with QWT (sometimes, not always).

In seamless mode for Windows 7, graphics are displayed very slowly: When the frame of a window is dragged around the screen, the contents of this frame, i.e. the real window, follows sluggishly, and sometimes a “ghost window” consisting of an empty black rectangle remains on the screen. Starting a Windows menu by hitting the Windows keyboard key is also really slow. It may take some 5 to 10 seconds until the contents of this menu are displayed, and submenus are shown even more slowly. The previous version QWT 4.1-65 (from October or so) did not show this behaviour.


Thank you for your feedback.

Still, it would be helpful if the Windows Start button was displayed in seamless mode, like it was with QWT (sometimes, not always).

I don’t remember seeing Start button displayed ever, need to check it.

No special changes in GUI components, so it might be by another reasons.

I’m planning couple more changes and will write a changelog.

I found a possible reason for the slow menu display: I had a flickering screen after an update and corrected this by setting

$ xfwm4 --replace --vblank=off &

as @kommuni recommended in Flickering screen after 4.1 update. This seems to be the cause for the slow menus. Changing the vblank_mode to xpresent corrected this problem for the main menu and somewhat for the submenus. I have updated my post on this.

With regard to the start button: As far as I can reconstruct it, QWT cannot display the round Windows 7 default start button. But if this button is changed to a rectangular button, as can be selected by Classic Shell, it could be displayed.

1 Like

I had applications in Applications menu even with QWT 4.1.65. All I did was to enabled administrator account, then refreshed applications in win7 qubes settings and voila - they were all there.

Beside this, I set strong password for administrator, put user "user’ in users group, removed write/execute permissions for user “user” for drive Q - private storage, as well as removed “Authenticated Users” for drive Q, created another standard user “userx” regarding permissions for Q, so If I want to write files or install some persistence apps on drive Q, I can do it only via shift + context menu as userx, while logged in as “user”. All strong passwords set.

Never too much security :nerd_face:

The problems with the slow menu display seem to be connected with using an Nvidia grphics card and the workaround against the flickering screen. On another machine with Intel graphics, window and menu update behave normally.

1 Like

i have deleted this post to avoid confusing others

1 Like
  • 5b - don’t do it
  • disable Windows hibernation
    powercfg -H off
  • enable audio support
    [user@dom0 ~] qvm-features win10 audio-model ich6
  • enable USB support
    [user@dom0 ~] qvm-features win10 stubdom-qrexec 1

Thanks for helping me troubleshoot this. I will start over fresh and incorporate your recommendations and report back soon.

@jevank for the enable audio / usb support do i set those parameters in step 2, 5 or 7?

In step 2 is fine. It doesn’t require QWT or smth special with windows 10.

1 Like

Thanks to @jevank I have been able to get Windows 10 standalone VM working on Qubes 4.1rc2 with QWT. I have identified a few problems but only one is critical:

  • The first and only major issue is the win10 VM clock does not stay in sync between reboots. I will manually perform a successful internet time sync in the Wiin10 VM (settings> date & time > sync now) then reboot and the clock will revert back to what appears to be UTC (although my timezone will remain EST). This happens with the “set time automatically” option both ON and OFF.

  • The second issue is everytime you boot the win10 VM Qubes/Dom0 notification banner will pop up “Failed: qubes.NotifyTools - Failed to execute qubes.NotifyTools from win10 to dom0”

Is anyone else experiencing the clock issue?

I have documented all the steps I took to install a working Windows w/ QWT in Q4.1rc2 below to help others. If anyone has any suggestions on how to improve it before I publish it in the main forum please let me know.


STEP 1: Download Windows ISO (the latest as of writing is 21H2 Build 19044.1288)

My Windows 10 iso is stored in the vm “windows-iso”

STEP 2: Execute commands in Dom0 to setup Windows VM called "win10"

qvm-create --class StandaloneVM --label red --property virt_mode=hvm win10
qvm-prefs win10 vcpus 2
qvm-prefs win10 memory 4096
qvm-prefs win10 maxmem 4096
qvm-prefs win10 kernel ''
qvm-volume extend win10:root 50G
qvm-volume extend win10:private 40G 
qvm-prefs win10 netvm sys-firewall
qvm-features win10 audio-model ich6
qvm-features win10 stubdom-qrexec 1
qvm-start --cdrom=windowsiso:/home/user/win10pro.iso win10

STEP 3: Install Windows 10

Set default username to “user”
Set default password to “password”
Run windows update and install all available updates
Turn on automatic logon using registry editor
Turn off hibernation. Open windows terminal with admin rights:
powercfg -H off

Note, the VM will shutdown several times during installation and you will need to manually start again to continue installation.

STEP 4: Build latest QWT Source: @jevank

Install Fedora 33 template VM:
dom0: sudo qubes-dom0-update qubes-template-fedora-33

Create standalone fedora 33 VM “qwt-builder” with 15G private storage space

In qwt-builder VM terminal execute commands to build QWT: 
cd ~
sudo dnf -y install git make mock
git clone https://github.com/QubesOS/qubes-builder
cd qubes-builder
make install-deps
make remount
make BUILDERCONF=example-configs/qubes-os-r4.1.conf COMPONENTS=builder-rpm get-sources
make BUILDERCONF=example-configs/qubes-os-r4.1.conf BASEURL=https://github.com GIT_PREFIX=tabit-pro/qubes- INSECURE_SKIP_CHECKING=windows-tools-cross COMPONENTS=windows-tools-cross get-sources
make BUILDERCONF=example-configs/qubes-os-r4.1.conf COMPONENTS=windows-tools-cross windows-tools-cross-dom0
sudo rpm -Uhv qubes-packages-mirror-repo/dom0-fc32/rpm/qubes-windows-tools*.noarch.rpm
sudo losetup -f /usr/lib/qubes/qubes-windows-tools.iso

STEP 5: Install QWT in Win10 VM

5a) execute this command in dom0 to attach QWT iso to win10 VM and boot
qvm-start win10 --cdrom qwt-builder:loop0

5b) In win10 file explorer find mounted iso and install QWT. Accept default options. if asked to reboot deny.

5c) Before restarting verify Win10 VM CPU is idle and reboot. after the vm powersoff do not restart.

5d) execute these two commands in dom0 with win10 powered off:

qvm-features win10 gui 1
qvm-prefs win10 qrexec_timeout 300

5e) start win10 VM. A GUI may not appear. Use Dom0 GUI to initiate an additional reboot BUT before you do wait until win10 CPU is idle (~5min). I am not 100% the logic of this step but i think some configuring is going on so let it run just in case. If anyone confirms this unecessary let me know. once your GUI is up check and confirm QWT is running correctly. poweroff.

5f) dom0: qvm-prefs win10 default_user user


Glad it helps. Welcome to the club :slight_smile:

try this
qvm-features win10 timezone localtime

Will be fixed in 4.1.66, it is almost ready

1 Like

couple words to your tutorial:

  • no necessary to install fedora-33, with fedora-34 build is ok
  • 5b - you can use other options too, but carefully with PV disk drivers and hot block attaching and network requires workaround to get IP.
  • 5d still actual, but might be fixes soon.
  • 5e if no gui appears try qvm-start-gui --force-stubdomain win10

Trying to attach a block device crashes my Windows VMs with the error SYSTEM THREAD EXCEPTION NOT HANDLED, no matter if qrexec-stubdom is set or not.

Maybe qvm-block attach --persistent win-cube dom0:sdx makes diffrenece?
Also, attaching whole hdd, not only partition. Other than that, I am out of ideas, sorry.

For one use case, I have both an eSATA port and a ejectable bay SATA port on the mainboards.

I use a one-line script to scan either SATA port for a newly attached drive (in dom0). E.g., essentially:

echo "0 0 0" | sudo dd of=/sys/class/scsi_host/host3/scan 2> /dev/null > /dev/null

Attaching that entire drive’s block device (via the GUI) to a Windows VM has generally been without incident, using the 8.xx Xen PV disk driver for Windows. For a couple of years, I think.


1 Like

Windows VM Clock Sync Issue

The issue is the OS seems to completely disregard whatever specific time zone you have configured in settings. By default it will always reset the clock to UTC at boot. If you execute the command above qvm-features win10 timezone localtime it will always reset after reboot to the local timezone set in Dom0 (dom0: timedatactl) which may or may not be the timezone in the Windows VM. My dom0 local timezone is EST America’New_york.

For example my Windows VM “persona” is based in Chicago and all settings in the OS reflect this. It’s netVM is sys-vpn-chicago. The Windows OS time zone is set to match the timezone of the egress IP address in sys-vpn-chicago. It’s important if you do not wish to stand out that your IP address timezone matches the clock/timezone on your OS. By default, OS clock will reset to UTC time (or localtime if qvm-features win10 timezone locatime is set). It’s even more problematic because after reboot the user selected timezone stays intact but the clock skews back to UTC (or dom0 localtime).

How can fix it so the time shows in the Windows VM honors the user set timezone ?

As a workaround I tried setting qvm-features win10 timezone America/Chicago but that did not do anything (it reverts WinOS clock back to localtime). Ideally, the clock will just show the correct time for whatever timezone the WinOS is configured for.

#WindowsVM & Whonix Timesync Bugs

Problem: When netVM of a Windows VM set to sys-whonix Windows OS internet time sync will not work (settings > date & time > sync now). I have tested this both with microsoft timeserver and nist gov. It just times out it can not connect to server. All other networking works fine.

thanks for this tip i will update the guide

By default QWT only installs “Base Xen PV Drivers”. I will add a note you can optionally enable PV disk drivers during install but add a note that it can cause stability issues if you are hot block attaching. I have two questions:

  1. What is the advantages of installing Xen PV Drivers? From what I can see everything seems to work without it. The reason I ask is I want to be able to explain in the guide so other noobs like me understand :grin:
  2. Check my understanding is correct: Hot block attaching means for example assigning from sys-usb to the WindowsVM a storage device? If that is right I will write it in the tutorial in easy to understand noob language as:

> if you wish to assign block devices such as USB drives from sys-usb to the WindowsVM do not install Xen PV Drivers because stability issues

is my explanation/understanding correct?

I am really sorry to waste your time asking stupid questions I feel like an idiot but again I have two questions:

  1. Similar to PV Drivers what is the benefit of installing Xen PV Network Drivers? Everything seems to work without it. Under what scenarios would an end user find it preferable to install this driver?
  2. You said that if you do install Xen PV Network Drivers that you need to do some “workaround” to get an IP. Can you describe what those steps are so I can include it in my tutorial?