Testing Windows and QWT in R4.1

For Windows 7, it seems that the standard SP1 disk is too old. Before installing QWT, the system has to be updated to the current (i.e. January 2020) level.

As for clipboard an file copy, these functions worked for me only if I installed the Xen PV disk and network drivers. During QWT installation, these drivers have to be explicitly selected, as they are disabled by default.

Good luck!

1 Like

Ok, That was the trick. I was using a SP1 iso and once I fully updated Windows 7 the QWT installed and I have all functions except seamless mode.

Thank you very much @GWeck for your patience and help.

1 Like

It’s good to hear.
Do you now you have:
-copy/paste working with right click on windows file manager
-attaching usb devices from sys-usb
-audio working
-mic working
-AppVMs or just a single VM with desktop environment(StandaloneVM)

I will address these one at a time:

-copy/paste working with right click on windows file manager
Yes copy/paste to and from appVM to win7vm works in the Qubes way of alt-ctrl-c and alt-clrl-v to move data to and from qubes clip-board then right-click copy and paste works to initiate or finalize the transfer in the target qubes

-attaching usb devices from sys-usb
No, not at this time. I have never been able to attach usb drive through qubes widget to a Windows Qube. Others have reported success, but it has eluded me. For my use case the file copy/move provided by Qubes makes a work-around and it is working fully.

-audio working
yes audio works but as @GWeck reported it can be a little “scratchy”

-mic working
yes mic works when attached to win7VM through the qubes widget. It is a little noisy but I rarely use my mic

-AppVMs or just a single VM with desktop environment(StandaloneVM)
I currently only have Windows 7 setup as a StandaloneVM with desktop environment. (no seamless-mode) I did not install the PV drivers to try to keep things simple for a baseline functionality . Now that I have this much working, (which is good for the minimal CAD work I do on Windows), I intend on trying another separate Template/AppVM install with PV drivers and the bells and whistles. Hopefully the PV drivers will solve the lack of seamless-mode and the USB connectivity issue. I will report back on that.

Thank you again @GWeck for this OP. The data it has generated and accumulated for the community and for 4.1 testers is very useful.

I am getting crashes when attempting to install xenbus to pave way for QWT on a freshly installed Windows 10 HVM. I am following this guide, which is excellent thank you for making it!

xenvdb seemed to install fine.

For xenbus, I tried both the suggested 9.0.0 version as well as (out of desperation) the development build. Both cause hard Windows crashes (reboot needed).

I’ve made sure I select “Run as administrator” on the installers and I also tried enabling test signing in Windows as suggested I should do in the Xenbus docs.

My Windows 10 is fully updated (I updated and ran both installers again).

This isn’t really a Qubes/QWT problem (directly) but if anyone else hits this issue I’d be curious.

I was able to get the 8.2.2 versions of xenbus and xenvdb installed, but I’m not sure this was a wise path. Though QWT seemed to install, and I eventually got the VM to boot again, I get this error when I try to right click and copy to vm from the win10 vm: “qrexec-client-vm.exe - System Error / The code execution cannot proceed because xencontrol.dll was not found. Reinstalling the program may fix this problem.” If you click OK it gives more popups about one other thing that cannot be found: libxenvchan.dll,

I did have some difficulties after installing QWT. First it would not shut down entirely from Windows even after ~20 minutes waiting so I had to do it from Qubes. Then I had some trouble on boot. The guide section I linked in my last message said to expect a boot that would not pop up a gui, but then you should be able to shut down and restart and it will work.

But it kept not coming back up, I tried several times to get it to boot. Also even trying to shut it down was not working, producing the error “Qube Status: / Domain has failed to shutdown: shutdown domain ‘59’ with libxenlight”. Another time it was domain “61”. Each time I killed the Qube with qvm-kill.

Finally I noticed a message in this thread that mentioned the “gui-emulated” qvm-prefs should be set to 1. This is not actually mentioned in the guide I linked maybe it should be added. When i set this pref, the next boot attempt succeeded. Or maybe this is pure coincidence.

Anyway now that the VM has booted I don’t think (?) QWT is working based on this one test of trying to right click copy a file to a VM. Maybe there are other tests to run? I suppose next step is to try and re-install QWT as suggested. But I wonder if the problem is I installed those old versions of xenbus and xvdb.

Ah I’m installing the wrong QWT, 4.0.1.3. I think I’m supposed to be building this QWT since on Qubes 4.1 GitHub - fepitre/qwt-crossbuild: Qubes Windows Tools crossbuild environment based on mingw, wine and docker

Those steps are failing on the last for me. I’m probably tired and missing something, will try again tomorrow, but the error is (and I did do the make install-deps step):


[user@dev qubes-builder]$ make qubes-dom0 COMPONENTS="qwt-crossbuild"
Currently installed dependencies:
createrepo_c-0.17.2-1.fc33.x86_64
no package provides debootstrap
no package provides devscripts
no package provides dpkg-dev
git-2.31.1-3.fc33.x86_64
perl-Digest-MD5-2.58-1.fc33.x86_64
perl-Digest-SHA-6.02-458.fc33.x86_64
python3-pyyaml-5.4.1-1.fc33.x86_64
python3-sh-1.13.1-2.fc33.noarch
rpm-build-4.16.1.3-1.fc33.x86_64
rpmdevtools-9.3-3.fc33.noarch
wget-1.21.1-2.fc33.x86_64
ERROR: call 'make install-deps' to install missing dependencies
make: *** [Makefile:229: check-depend.rpm] Error 1
[user@dev qubes-builder]$

I have an issue with sound in a Standalone Win10 VM with QWT 4.1-65.
When I activate it with qvm-features vm_name audio-model ich6, it works only for the first time, but if I reboot the VM, it shows the sound as working and you can select it, however there is no more sound.
Deactivating and reactivating the ich6 or ich9 audio model result in the same issue.
So I can’t have a “persistant sound” working.

I’ve been testing a Windows 10 LTSC VM for a few days now on qubes 4.1 beta. The only problem I have left to solve is network IO causes massive lag.

For example, when downloading something. windows task manager shows ~30% cpu usage coming from “system interrupts”. The whole os becomes very choppy.

I believe this is due to XEN Windows PV drivers not being correctly installed. In particular, I noticed the XEN Network Class (VIF) driver was not installed. I’ve attempted to install it using the latest release, but didn’t seem to work.

I noticed that the other installed XEN PV drivers were using a 8.2 version (I think they were installed using a QWT built from QWT-cross, so I figured I should manually update those as well.

After doing that, the VM will not boot, and qvm-kill doesn’t work either when used on it, the command just waits blankly in CLI and freezes up GUI. Thankfully, I cloned the vm before so I will continue troubleshooting this.

My questions are:

  • Which XEN PV drivers should I install? There are 8 listed on the 9.0.0 page for example, should I install all of them?
  • IIRC, then latest version 9 drivers are recommended for Windows 10 VM, is that correct?
  • Has anyone else also faced network IO or VIF driver problems and could share any insights?
  • Is there a way to force kill a vm, if qvm-kill doesn’t work? ATM I am restarting the whole system to “get rid of it”.

Edit:
Another strange behaviour on my troubleshooting list is that the Windows qube vm sometimes doesn’t show up. It seems to have this issue on the first boot after a system restart and then the second boot works, although I’m not 100% sure. I’m using GPU passthrough so it perhaps is related to that.

So looking at the vm clone I had made prior, it appears that the Network Class driver was installed correctly (v8.2.2), but there also appears to be an additional unrecognized/not-installed VIF driver. I think this unrecognized driver is the v9.0.0 one, which is probably broken because I think it relies on the other drivers to also be on v9.0.0? But trying that leads the problems outlined above, and is time consuming to troubleshoot unfortunately. Maybe 8.2.2 drivers are okay to use?

I’ve tried removing and using only the one, but still no luck.

Besides the driver, any ideas what else could possibly be causing the network io to create this issue?

We didn’t enable PV network drivers by default because it has an issue with DHCP. You can reinstall them from QWT setup and try to setup network with script
C:\Program Files\Invisible Things Lab\Qubes Tools\bin\qnetwork_setup.bat

AFAIK version 9+ drivers are incompatible with PV Xen drivers v8 (xeniface), so should not mix them.

1 Like

Thank you so much for this advice.
I re-installed the drivers through QWT and it now works perfect!

1 Like

Thanks for everybody sharing information in this thread!

Did anybody figure out a way to use a higher resolution in Windows 10 then 1920x1080.
I’ve tried the Custom Resolution Utility, but that only seems to work with AMD / NVIDIA / INTEL drivers, not the Basic Microsoft VGA driver.

It is defined by seabios/tiano firmware. With R4.1 seabios default I see max 2560x1600. To get 4k I think it needs to patch/rebuild.

@elliotkillick has some collected some patches for SeaBIOS for the video modes, looks like he’s submitting a patch:

https://news.ycombinator.com/item?id=28900125

scrolldown to first mention of SeaBIOS.

1 Like

Thanks a lot guys!
I was successfull in patching the vgabioses with custom resolutions and patching the stubdom with them.

I had to patch both stubdom-rootfs’s for the patches to take effect:
/usr/libexec/xen/boot/qemu-stubdom-linux-rootfs
/usr/libexec/xen/boot/qemu-stubdom-linux-full-rootfs

2 Likes