I did some testing which came out to a pretty complicated situation, which I described in issue #8328 and which, so far, is not solved.
The situation can be roughly described as follows:
If a Windows qube from R4.1.2 with QWT - no matter whether standalone or template - is backed up and then restored to R4.2, the Qubes menu entries for that qube are destroyed, but otherwise it works with QWT from 4.1.2.
The situation is a little bit better if QWT is uninstalled before backing up the qube under R4.1.2. (If you do that, be sure to clone the qube before uninstallation, as this may break it !!! ) Installing QWT .69 to the restored qube under R4.2 will lead to a working Windows and QWT, if neither the optional PV network and disk drivers nor the Qubes GUI agent for Windows 7 are installed.
So, if you can do without seamless mode for Windows 7, which is not available for W10 or W11 anyhow, you can work with Windows and QWT under R4.2. (For me, unfortunately, this is no real help, because I need Windows 7 in seamless mode. )
Broken menus may be restored manually, if the contents of /home/user/.local/share/qubes-appmenus/VMNAME/apps/ in dom0 are copied from the R4.1.2 installation to the R4.2 installaition, and the same is done within the Windows qube’s registry with the contents of HKLM\SOFTWARE\Invisible Things Lab\Qubes Tools\AppMap.
Caution: Applying qvm-sync-appmenus or the Refresh applications function from the Qube Manager will break the menus again!
After this post I tested attaching my usb drive to both win7 and win10 and both connect and are completely functional as drive D:. Windows Disk Management tool works as well.
I was able to get all my AppMenu elements working on both win7 and win10 with Qube Manager, Settings, Applications, Reset Applications.
For grins I cloned my win7 qube to test seamless mode. I was able to activate it from Qube Manager, Settings, Advanced, Enable seamless mode. Note : the win7 HVM had to be started for the enable button to be active. Seamless mode would initiate and remain active for that session but upon shut down and restart seamless mode was disabled and not persistent.
When I built these HVM it was QWT 4.1-65 on win7 and QWT 4.1-66 on win10. Not sure if this matters but I have not updated QWT since
If you have a “powerfull” computer you can install on external SSD like example Fedora or Kicksecure then on it install virtualbox and there windows system .
The mode in which Windows 7 starts depends on the DWORD value SeamlessMode in the registry key HKLM\SOFTWARE\Invisible Things Lab\Qubes Tools\qga (and possibly also in HKLM\SOFTWARE\Invisible Things Lab\Qubes Tools too - I am not sure): 0 means start in non-seamless mode, 1 start in seamless mode.
Interestingly, I have a working seamless mode. Which is a good thing, because windows will cover my entire screen without it…including the KDE menu, and I haven’t figured out how to get around it without shutting windows down. (This is not an issue on a two monitor system…provided you disable seamless mode with the qubes settings window on the desktop that doesn’t have the KDE menu on it. Non-seamless windows can cover that without blocking your access to the menu.)
On the other hand, I now don’t have “alt key opens the windows menu in seamless mode” any more, so I have to go to non-seamless mode to shut windows down!
As for my issue mounting things…apparently in spite of the fact that I formatted my veracrypt container as FAT, I still had to format it in windows disk manager. (Fortunately it was an empty container I created as a test) This implies that I might not be able to use other, pre-existing containers. I can’t test that readily, unfortunately.
Once the format is good, though, it mounds properly as drive D:
I think some people are confused. Windows VMs still work perfectly fine in Qubes OS with no security problems. It’s only Qubes Windows Tools (QWT) that currently have a problem. If you can live without the special features QWT provides (e.g., easy copy/paste and file transfer), you can simply use Windows like any other HVM with no problem, just as you have always been able to. (For example, to work around the file transfer part, you could simply use your own encrypted file transfer method to transfer files over the internet to yourself instead, like 7zip-encrypted files on cloud storage or something.)
I am used to giving Windows a dedicated KDE workspace and having it running full screen. I can switch to other workspaces to gain access to the KDE menu.
If can do it on any computer, even not powerful. But what’s the point, it will be running without Qubes OS. We are talking about Qubes OS users, that have to run Windows VM as it was possible since like R1.0 or something.
Alt+Tab should work. Also I advice to use something like devilspie2 or own bash script to remove Windows window decoration and put to a desired place. I use it with fixed placement, without decorations and with smaller resolution (smaller width, by the same height). So I have no issues with changing VM to other apps even with 1 display.
It is true. But other ways of running Windows, like VirtualBox provide both file sharing and clipboard copying, even without internet and even network access for Windows at all.
It was also a case for Qubes OS for many-many years. So, nowadays everyone considers this to be a bare minimum of proper Windows support (even without video acceleration).
Without it developing something in Windows on Qubes OS is a huge pain. When user wants to copy clipboard, they should paste it in text file, 7z it with password, upload on the Internet, download, unpack, open, copy? Would be insane to do that more that a couple of times
RDP/VNC connection is an interesting of workaround, but still a pain.
The long story short: the problem that QWT kind of does not exist for now, should be addressed sooner. With higher priority.
P.S. I am talking from users behalf (as I see it), not myself, because I have working QWT and no intention to recreate Windows VMs, so for me personally the situation is tolerable.
Windows of after version Windows 10 are spyware(This is not slander, they send user data to Microsoft server without user permission), why and what are you worried?
QWT is working perfectly on only Windows 7, don’t works fully in other versions.
But Windows 7 is EOL, so if Windows 7 Qube is online, it is very danger, it must not.
But if Windows 7 Qube uses only offline, it is safely, this is following to separation concept of Qubes os, this reason is same to safety of dom0.
Unfortunately running only on Windows apps are existing, if user must use them for work or game, user must run them on Windows Qube.
If user must use Windows app as online, user must use after Windows 10, but they are not safely.
Concept of Qubes os is security as separation, so user must pay cost of accessibility, if user don’t worry to security and privacy, this one is not need to use Qubes os(Using multiple os at the same time is concept too, but Windows can not install to template vm as Linux, this is nothing with there is QWT or not).
If user uses Windows app only offline, if QWT installs in Windows Qube, it is not much danger.
If user runs Windows Qube as online, if Windows Qube is not installed QWT, it is separate from Qubes os, it can not access to other Qube, so it is more safely(But Microsoft is doing privacy violation).
Qubes os designs as user privacy, so if user hope to run Windows on Qubes os, user must use alternative approach.
I use onionshare-cli --receive -public command on one of my linux qubes. And then from inside the windows HVM, visit the .onion URL that the onionshare-cli spits out. And then upload my files like a dropbox to my own onionshare box. Tested it with files up to 100 MB. Works good enough.
There are workarounds, definitely. The one might use LocalSend, for example, probably, but is that the point? I really can’t remember resolvable QSB hasn’t been resolved…
What works for me :
I had a windows 10 HVM on 4.1 with ‘‘half QWT’’ (because stopped at the compromised warning while install, could not go further). Then backed it up. Them fresh installed 4.2 and restored the VMs. All worked directly. To the Windows, I can connect a USB device (after a line of code to permit it, once), audio, internet. I am using it everyday.
A couple of updates on this earlier comment of mine.
And I never did. What I was remembering was getting the windows menu to pop up (even in seamless mode) when pressing the windows key. My laptop, as it happens, has no windows key, so I could bang on other keys until I was blue in the face and get no windows menu and then think the feature is broken. My desktop, of course, does have this key. (Is there a generic key combo that simulates the windows key?)
I still haven’t solved this, but it seems to be a veracrypt issue, not a Windows issue. I was attempting to attach decrypted veracrypt containers to the Windows VM. I know a thumbdrive works fine (as long as it’s not one I’ve reformatted for ext4). Veracrypt doesn’t seem to offer FAT32 (just FAT, which won’t attach), and just chokes on things that it, itself, formatted as NTFS–immediate fail to decrypt (or that might be something I did in my scripts).
)