Testing Windows and QWT in R4.1

It’s not good for every day work on real job.
I mean win7 hvm + proxy vm.
Too sluggish.
Recommend use qubes as network server and route traffic from proxy vm to another baremetal PC host with Windows 10 and graphical card.

https://github.com/0rb677/dotfiles/raw/master/qubes-windows-tools-4.1-65.noarch.rpm

build instructions here :

remember, its not official

1 Like

I checked now the new version 4.1-65 of QWT under Qubes R4.1, and the results are very promising:

  • Installation works for both Windows 7 and 10 without problems. I tested just using the default configuration, i.e. all options without Xen disk and network drivers.

  • Both templates and newly created AppVMs based on these templates work, allowing file and clipboard copy to/from other VMs, for both Windows 7 and 10.

  • Private storage for templates and AppVMs is correctly separated for both Windows 7 and 10.

  • Audio (microphone and speaker) work (most of the time - see below) in both Windows 7 and 10, although the sound is somewhat scratchy.

  • For Windows 7, seamless mode works and can be enabled/disabled while the VM is running.

There are some caveats, still:

  • If Windows 7 is run in seamless mode, the start button is not displayed, like it was under Qubes R4.0 with QWT 4.0.1.3. Apllications can be started via the XFCE menu, and show their windows on the desktop. If focus is set in one of these windows, the Windows menu can be displayed by hitting the Windows key on the keyboard.

  • Under Windows 7, audio sometimes did not work, and the control panel showed a message that no audio devices did exist. Sometimes this was accompanied by an error message that the audio driver were not signed - although it is a Microsoft driver and testsigning is on.

  • For Windows 7, screen resolution is resticted to 1920 x 1200 (my physical screen size) and 800 x 600. For Windows 10, the supported resolutions are 1920 x 1080 (HD), 1024 x 768 and 800 x 600. Changing the screen resolution is possible, but has some funny effects if the VM is running in seamless mode.

  • Selecting or deselecting seamless mode for Windows 10 crashes the Qube manager, but leaves the VM in its previous state.

  • AppVMs work as expected if they are created after QWT is installed in the template. AppVMs created before mess up their devices, as the template uses drive letter Q: for the private volume, which has the consequence that these earlier created AppVMs do not find their user profiles and thus cannet be really used. Trying to repair this situation is more or less impossible, since Winows makes a terrible mess in its drive letter assignments. This, however, is no problem of Qubes or QWT, but stems from the “superior” Microsft software quality. (They should have learned this around 1990, and their efforts with Vista and later only made it worse!)

To sum it up: QWT 4.1-65 is already very good and can be used with faith in Qubes R4.1. So, there is a lot of hope that Qubes can remain a valid and stable basis for running Windows in a trustwothy way.

2 Likes

If Windows can be / has to used under Qubes, as usually, depends on the requirements and the environment. Putting Windows in a separate machine protected by a Qubes network proxy is o.k. for a stationary environment, where you can have several computers. In a mobile situation, where you have just one laptop, running Windows as Qubes VM(s) is, in my opinion, the only option to run this system safely.

No discussion: running Windows natively without some protective shield and accessing the internet is somewhat an information suicide!

I repeated the tests of QWT 4.1-65 on Qubes R4.0.3, with similar, but in several aspects differing results:

  • The option Move user profiles does not work for both Windows 7 and 10, such that using templates and AppVMs is not possible, at least not without much effort.

  • Audio does not work for both Windows 7 and 10.

  • Windows 7 behaves similarly to the installation under R4.1, including functioning file and clipboard copy. The full screen resolution is a bit lower, 1920 x 1142.

  • Windows 10 at first seems to work, allowing, like Windows 7, file and clipboard copy. So, the qrexec communication seems to be set up correctly. A full range of different screen resolutions is available. But: After the next reboot, Windows 10 does not start anymore, but stays in the starting state and is killed after qrexec timeout.

So, for Qubes R4.0.3, it is currently better to stick to QWT 4.0.1.3.

1 Like

Hello:)
I tested the new QWT 4.1-65 on Qubes 4.1 and tried to install Windows 7 and Windows 10 as a template VM. My problem is that the template vm has no nettwork at both systems. If I set up an AppVM there networking is working. Of course I selected sys-firewall as an netvm ,before starting windows:) It will be very nice and helpful to tell me how I can fix that:)
I found that descritpion ,but I don’t know where to find that “qubes network” in msconfig:
Workaround: disable the “Qubes Network Setup” service (with gui/ msconfig , or sc config "QubesNetworkSetup" start= disabled in a command prompt) and configure the network manually.
Settings:

  • DNS{1,2}: 10.139.1.1, 10.139.1.2
  • Subnet: 255.255.255.0
  • IP: to find the VM’s ip, run qvm-prefs vmname visible_ip in dom0. Caveat: a cloned/restored/… VM will likely have its IP changed so you’ll have to remember to update your network settings.
  • Gateway: to find the ip, run qvm-prefs vmname visible_gateway in dom0.
    I installed qwt without any changes, maybe I should try it with these network drivers?
    And another question: If I install qwt at Windows 10 I don’t need to install the xen storgage 9.00 drivers like I have to do in Qubes 4.0 before, or?

Thank you in advance for ur help and stay healthy
Much greetings Rasta

I checked my installation and had network access from both Windows 7 and 10 templates if and only if their NetVM is set to sys-firewall before starting them.If, as is default for templates, their NetVM is set to none / deafult (n/a), they start without a network interface, i.e. they have no network hardware.

I installed QWT without the PV network driver, because I had already some trouble in the previous version of QWT (see above), as the PV driver does not seem to work with Qubes DHCP. Maybe it behaves differently from my installation.

I’ll try with msconfig later on , so stay tuned …

So, I did a few mistakes in configuring network in win7 manual and uses 255.255.255.0 as mask ,but it has to be 255.255.255.255. Now it is working.
And I reinstalled the template vm with xen disk and network drivers this time and a own build win7 ultimate.iso including sp1 and updates. It seems that everything is working. Qwt 4.1 and qubes 4.1 is really good for the first days!:slight_smile: I am doing my Home-Schooling with that settings, running teams on fed32 and sometimes at win7 vm and did not have much problems:)
You can send a file to the win7 vm and the other way around. And secure clipboard copy is working,too. The qubes private is q: and the move of the user data was correct. Audio is working so far, too:) A template based appvm ist working,too. U just have to change the Ip in the windows network settings corresponding to the VM and network is working,too:)
I will try a few things more and update as soon I got some more informations and set up and Windows 10 VM,too and look what errors I will get there.
But in a nutshell many things are already working and that is a big hope for a stable secure win vm in the next years!

Just an other question: Is there any doc about how to link and windows desktop file to a qubes starmenu shortcut like the tool qvm-create-windows-qube ist doing it after installing the packages via cocolately?
Thank you again and stay blessed!

Lovely greetings

Rasta

1 Like

Just an other question: Is there any doc about how to link and windows desktop file to a qubes starmenu shortcut like the tool qvm-create-windows-qube ist doing it after installing the packages via cocolately?

You may create a destop starter symbol like for any Linux-based VM, by rightclicking on an empty desktop location and then tryping <your-Windows-VM-name> and selecting one of the programs offered in a list. This starter works as expected, starting the VM if it is not yet running, and then starting the application, in seamless or non-seamless mode as spefied for the VM. You may even drag the icon to the task bar and start it from there.

1 Like

The Windows 10 VM may crash after qrexec timeout. This can be avoided by setting qvm-features <VMname> qrexec "", i.e. setting this paramter to blank. Still, qrexec communication seems to work, because file copy is operational.

If the Windows 10 VM does not start visibly, its gui can be started manually via qvm-start-gui <VMname>. Alternatively the parameter gui and gui-emulated may be set to 1, i.e. qvm-features VMname> gui 1 and qvm-festures gui-emulated 1.

Still, this is not quite reproducible and needs further testing.

1 Like

I tried installing the new qubes windows tools at a Windows 10HVM,too. But there I am not able to get a stable working vm. Sometimes copy between other vm*s is working sometimes not. I am always creating an template vm first and then try appvm’s. Seamlessmode of course is not working, too and qubes manager chrashed. but I will try what will be if I change it in the registry to value 1,if then system will boot or not the next days.
And I tried to install the xen 9.00 pv storage drivers and bus before installing qwt. So win10 will boot, but if u install new qwt the template vm will not boot anymore and hang up at booting.
The best option was just to install qwt with standart settings in a fresh create hvm with the known settings for an win10 vm:) mostly copy file betwenn the vm is working on this way. but I will try some more trial and errors this weekend:)

but for the win7 vm, seamless mode persistently via win registry is working, memory balance not,but no problem usually, the template and appvm are working. audio,too. Just sometmes it will be a bit laggy if u open a big app like adobe photoshop in it ,but that is stressfull for ur cpu and else and must not work perfectly and is good enough to use it:)

stay healthy!

That is exactly what I observed! (Just shows how reliable W10 is, and they always tell us to switch from W7 to W10 - Grrr!) :unamused:

No I reinstalled my Windows 7 template VM, and have exactly the same problem as the last time but now I cannot get i working again. Just in the appvm the network is working and not in the template vm. I tried it with the xen network drivers and without. Maybe u can tell me what I can try. The right gateway and else is need is that from the Win7 template vm or?
I don*t know why, but that is annoying. I need a solution to get networking working faster and not after many days of work:D I try to reinstall it later and set the netvm soon before the first start

For Windows 7, I have the following behaviour:

  • If the template VM is connected to sys-firewall on startup, i.e. the Qube manager shows sys-firewall as NetVM before starting the template VM, it will have a network device and will be connected to the internet.

  • If the template has no NetVM, i.e. the Qube manager shows default (n/a) as NetVM before starting the template VM, it wil have not network adapter (shown in the Windows network manager). Setting the NetVM in the Qube manager after starting the VM will have no effect until the next boot of the VM.

  • The AppVM, which normally is connected to sys-firewall, behaves the same way as the template VM, if it is connected to sys-firewall.

  • Starting both template VM and AppVM with network enabled is likely to cause trouble, because they may come up with the same IP address.

Windows 10 may behave the same way, but after the next boot may not work at all. It is more or less erratical.

So , I finally know the fix, but don*t know what exactly the problem was. Now I reinstalled it (always with xen network and pv drivers, the other way I will not have much effort) and before I update qubes 4.1 from the current testing repo. I think there is a driver or anything else new, which makes sys-firewall working in my win. Of course I need to set up the network at the adapter section in win manualy, but then it FINALLY will work. But of course I had to try thsi one more to be sure for 100 % :wink:

And at this qubes install I missed to enable that sys-net should handle all my usb controllers, too. Do u know if there is a a way to enable this after instaling?

So, I try a fesh Qubes installation at my 2nd laptop to figure out if that is the problem. I installed 4.1 with sys-net ,sys-usb everything dispvm and a custom storage pool. I installed a win7 vm and hat the same network problems and cannot get it working. then I run a update of the current testiing repo and it is working with manual setup,xen drivers and else… hm?!

According to Windows 10, I tried a few more installs ,but with the xen drivers it is not running. maybe file copy is working one time. For me the stablest is to use a Windows 10 pro.iso , update it completely and install net 4.8 , maybe 5, too. Do a restart everytime its necessary and at the last step install the qwt 4.1 with move of user data enabled and standart installation settings. So u will get a working Windows 10 HVM ,like in qubes 4.0 without the xen drivers, but that did not matter much.

I saw that ur using ly display manager for logging? I tried it with sddm kde and lightdm xfce and both. Sometimes I think that sddm and kde have a better performance in the windows hvms, especially in win7 seamless mode. But I like to have the ly display manager like u can the at the gihub page in this posts. But if I download the file and run make the I am always getting 1 error. Do u have an compiled rpm file that I can use to install or tell me the steps to get it running? Because sometimes I am using i3 desktop, and with the other managers I cannot logout and login to a plasma or xfce session . Then it will not load in completely and I have to reboot. I can imagine that with the ly manager it is working and I have good perfomance,too cause it is a small one. Soon it is weekend and I will do some trial and error again. Have to get more space in my dom0 root volume and a few things to do :smiley:

So after I am trying a few several updates with new kernel 5.1x ,sys net and sys-firewall are working again and starts, but only my my wlan is working like with kernel 5.9.14-1 and I don’t know how to get my wired connection working again. The network card is detected, but that is a bit off topic for here, but I noticed problems with my windows Hvm and the new kernel…It don’t start anymore and I am alyways getting an qrexec error and the vm halted. I think that is a problem with qwt and the new kernels?!
I definitely need to get working my dual boot from a ssd again or I have to buy a second ssd if that is not working for some work until I got the vm running again and stable that it will not crash again after the next updates;) I will try it what u told me in the other topic @GWeck . Thank you for ur help. U have got a big knowledge about such things!

fix: okay that problem was fixed easily and I just need to run again qvm-prefs VM qrexec_timeout 300- It seems that this was overwritten at the last update, but now the win vm*s are working like before.

stay healthy

I am attempting to install Windows 7 with QWT as a Stand alone VM on Qubes 4.1. I originally attempted to restore my stable win7 VM from Qubes 4.0.3 and it would not run as in the OP.

I created my VM with this command:

qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new

Since I’m not familiar with the build process I have downloaded the QWT 4.1-65 rpm from here

https://github.com/0rb677/dotfiles/raw/master/qubes-windows-tools-4.1-65.noarch.rpm

and I am following the instructions here

sudo dnf install mock
sudo groupmems -a user -g mock
sudo mount -o remount,dev /dev/xvdb /home
git clone https://github.com/tabit-pro/qway-qubes-repo
mock -n -r qway-qubes-repo/fedora-qbs.cfg --rootdir /home/user/temp --resultdir \
/home/user/rpms --sources qway-qubes-repo/qubes-windows-tools/ --spec \
qway-qubes-repo/qubes-windows-tools/qubes-windows-tools.spec
rpm -i qubes-windows-tools-4.1-65.noarch.rpm 
qvm-prefs win7new memory 4096
qvm-prefs win7new maxmem 4096
qvm-prefs win7new kernel ''
qvm-volume extend win7new:root 30g
qvm-prefs win7new qrexec_timeout 300
bcdedit /set testsigning on
netplwiz (disable password)
qvm-start win7new --instal-windows-tools
set network manualy
qvm-features win7new audio-model ich6
qvm-prefs win7new memory 2048
qvm-prefs win7new maxmem 2048

I have some questions:

  1. Is using this QWT 4.1-65 rpm going to be reasonably safe /secure
  2. I am unfamiliar with “mock” , please inform what it does and if those command lines are pertinent to my use case.
  3. I assume that since I have the rpm, I should copy that into Dom0 before executing the command . Correct?
rpm -i qubes-windows-tools-4.1-65.noarch.rpm 

on edit: Of course I have read the information on “mock” at
https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
so I have an idea what it does, but I am specifically trying to decipher its use in this case

Thank you very much for your assistance.

Hi @estoner, the rpm file already contains QWT 4.1-65 in a form that can be directly used. The first group of commands seems just to be the build process for the rpm file. I did not try this, and I suppose it would not have worked in my environment. I just downloaded the rpm file and copied it via qvm-run --pass-io to dom0. Installing it there via sudo dnf install makes the Windows installer qubes-tools-x64.msi available in the Windows VM for the qvm-start --install-windows-tools command later on.

To your questions:

  1. For a test environment, the rpm is suffiently secure. I have been using it now for about 3 months, without problems. For a production environment, I would like to havean official QWT kit, but that seems somewhere in the future for Qubes R4.1.

  2. The mock command builds the rpm, but, to me, it is unclear, which resources (on the Fedora and on the Windows side) are needed to perform this.

  3. The rpm has to be installed in dom0 in order to make the iso available in the Windows VM. For further tests, I prefer to extract the QWT Windows installer qubes-tools-x64.msi from that iso, which appears as a CDROM in the Windows VM, and use it afterwards, without referring to the iso subsequently.

I hope I could somewhat clarify this and not make the cofusion worse!

@GWeck

Thank you very much for your detailed response. Unfortunately I don’t seem to have fully functional QWT after 2 attempts.
Working : Audio, Internet
Not Working: clipboard copy and file transfer to/from other VMs, USB connect through devices widget, enable/disable seamless mode buttons grayed out . Probably other features.

Here is an outline of the process I followed. If you or any other members @rasta @wind.gmbh @ooooooooo @fepitre can comment on where I went wrong it will be greatly appreciated

Install QWT in dom0

  • copy all files to untrusted/Downloads
  • from untrusted/Downloads copy the QWT-rpm to Dom0 Downloads directory via :
    qvm-run --pass-io untrusted 'cat /home/user/Downloads/qubes-windows-tools-4.1-65.noarch.rpm > /home/user/Downloads/qubes-windows-tools-4.1-65.noarch.rpm
  • list the directory to verify the file was moved to dom0 Downloads directory
    ls
  • while in dom0 Downloads directory install the QWT with the following command:
    sudo dnf install qubes-windows-tools-4.1-65.noarch.rpm
  • check to see that the package is installed in dom0
    dnf history userinstalled

Install Windows 7 stand alone VM (win7)

  • open dom0 terminal
  • enter the following commands one at a time:
    qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7
    qvm-prefs win7 memory 4096
    qvm-prefs win7 maxmem 4096
    qvm-prefs win7 kernel ‘’
    qvm-prefs win7 debug true
    qvm-volume extend win7:root 30g
    qvm-start --cdrom=untrusted:/home/user/Downloads/Win7_Pro_SP1_English_COEM_x64.iso win7
  • restart after the first part of the windows installation process ends (make sure its completely stopped)
    qvm-start win7
  • set auto-login,from within win7: open administrator cmd prompt and enter the following command:
    netplwiz
  • follow the wizard
  • once Windows is installed and working shut down win7
  • restart win7 to test auto login
  • in dom0 terminal
    qvm-prefs win7 qrexec_timeout 300

Install QWT in Windows 7 stand alone VM (win7)

qvm-start win7

  • in windows open cmd prompt administrator and enter the following command:
    bcdedit /set testsigning on
  • restart win7 to make sure testsigning took (mine shows Testing in lower right of desktop)
  • shutdown win7
  • in dom0 terminal
    qvm-start win7 --install-windows-tools
  • in windows set network manually (need to determine what this entails)
  • open windows explore (folder icon)
  • open computer
  • open cd drive
  • double click on qubes-tools-x64 (icon) and follow setup wizard at warnings choose install drivers anyway
  • restart win7
  • in dom0 terminal
    qvm-features win7 audio-model ich6
    qvm-prefs win7 memory 2048
    qvm-prefs win7 maxmem 2048
    qvm-prefs win7 debug false

NOTE: I had fully functional windows 7 with QWT on this hardware under Q4.0 using 3rd party qvm-create-windows-qube so I’m encouraged that its just my shortcoming, not a hardware incompatibility

After a 3rd attempt , Windows 7 Qube does not have functional QWT clip board or file transfer between other AppVM.

Here are the symptoms:

on reboot after qvm-start win7 --install-windows-tools
a start-up repair diagog box appears and after some time i get a box “restart to complete repairs”. If I dig into the details of the repair, there is this message:
Boot critical file e:\windows\system32\drivers\xenbus.sys is corrupt
repair action: file repair
result:failed, error code 0x2
time taken 3323 ms
The system does a forced reboot and everything seems good, but that is a trick because upon further investigation when looking at the win7 Device Manager - System Devices there are no Xen related devices installed . My installed devices are identical to this image, I FOUND ONLINE , less the Xen related devices

Maybe this information will help the community

Hi,
you are not the only one testing the qubes windows tools.
I followed your previous steps and all I get is just audio to work, no copy and past and no usb devices.
Windows 10 or 7 makes no difference.
Also I can’t have the “appVMs” it’s just a standalone VM with audio working.

Thank you @xewere5109 for verifying my results.

It seems that my steps are flawed because others are getting more fully functioning results. My hope is that one of those members who achieved better results might scrutinize my efforts and point out where I went wrong. Once I get a more functional standaloneVM working I intend to test a win7 templateVM and associated AppVM