Testing Windows and QWT in R4.1

User Support General
101

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
102

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:

103

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
104

i have deleted this post to avoid confusing others

1 Like
105
  • 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
4 Likes
106

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

107

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

108

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

1 Like
109

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.

EDIT: TO ANYONE READING DO NOT FOLLOW THE GUIDE BELOW IT IS NOT YET FINALIZED AND HAS SOME ERRORS I AM CLARIFYING IN DISCUSSIONS BELOW

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
Shutdown

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

3 Likes
110

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
111

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
2 Likes
112

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.

113

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.

114

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:

#!/bin/bash
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.

B

1 Like
115

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?
116

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?

IP has to be manually set then, not via dhcp, and as seen in Qube manager’s correspondent column, for example.

117

That looks like an issue with PV disk drivers and isn’t related with stubdomain USB support. Persistent block device attach looks more stable.

118

That’s plausible: My Windows VMs come from Qubes R4.0 and so are using the Xen PV disk drivers, see the diskussion in Migrate backups of Windows VMs created under Qubes R4.0 to R4.1.

I’ll check with a VM without the PV drivers.

119

PV Drivers improve virtual device performance - disk or network. Hot attaching means attaching device to working VM. You can attach USB storage device as block in persistent mode (VM is shutdown), in my experience no issues with that, or to the working VM as USB or block device. The last one may lead to hang.

Network PV drivers do not get configuration from DHCP, so you need to assign IP manual. This is easy for StandaloneVM, but requires workaround for AppVM. QWT-cross contains script qnetwork_setup.bat to make it easily.

The timezone VM feature could be localtime to make VM timezone same as dom0 or numeric offset in seconds from UTC. As I see there is no ability to make offset negative, it needs to fix libvirt template.

120

In the latest update of 4.1rc2, full-screen mode (ALT-F11) is broken for windows HVM’s. The window just disappears. This has been working since 4.0 until recently.