[WIP] Windows/QWT user reports

Community Guides
1

:warning: Please note This is a work in progress guide (WIP) created to crowdsource user experience about using Windows in Qubes, optionally with Qubes Windows Tools (“QWT”), following up on this github issue.

Please contribute too ! It’s easy: edit this wiki page (the edit/‘pen’ icon at the bottom of the post), copy the content of the user report template at the end of this post and paste it in the relevant “Contributed user reports” Windows sections. Even is someone has already added a report with the same version of Windows (and optionally QWT) it’s perfectly fine to add another report as your use case (/features you use) might differ.

General resources

Please read the Windows qube documentation (thanks to @GWeck the community documentation is now updated for Qubes OS R4.1 so this section’s content is deleted).

Contributed user reports

Windows 7

R4.1 / Windows 7 Pro SP1 updated until Oct 2020 / QWT 4.1.67 of 2022-02-14

@GWeck; date: 23 Feb 2022, updated 26 March 2022

Windows:

  • installed from scratch as template VM
  • build/iso: Windows7ProfSP1.iso of 2016-05-28, downloaded from Microsoft
  • updated using WinFuture Patch kit “WinFuture_7SP1_x64_UpdatePack_2.107_Januar_2020-Vollversion.exe” and manual updates after that
  • ram used when installing: 4GB
  • ram usage after install: 4GB
  • disk space usage after install: 27GB

QWT:

  • first installation

  • installed just after completing the update horror to get the system current

  • features selected during installation:

    • Base Xen PV drivers
    • Network and Disk drivers
    • Move User Profiles

  • features that were tested to work:

    • build / use AppVM based on that template
    • seamless mode (dynamic via Qube Manager and static via registry)
    • audio output (needs to activate Windows Audio Endpoint Builder service)
    • copy/paste between qubes (both directions in and out)
    • copy files between qubes (both directions in and out)
    • attaching USB devices to the qube
    • networking (for AppVM based on that template)
    • time/clock synchronization using qvm-features VMname timezone localtime
    • setting decent screen resolution for non-seamless mode using Alt-F8 key
    • user migration from C: to the qube’s private volume (needs to rename drive D: to Q: before QWT installation)

  • features that don’t work:

    • attaching SATA and NVME devices to the qube (crashes the qube)

Xen disk and network drivers can be installed during installation or after completing the previous steps. This will probably cause Windows activation to become invalid, but the activation can be restored using the Microsoft telephone activation method. After this, USB devices can be attached and used, and booting is about two thirds faster.

Summary / notes: can be reasonably used in seamless mode; access to functions via XFCE menu or by hitting Windows keyboard key in a VM’s window and thus displaying the Windows menu

Windows 10

R4.1 / Windows 21H2 / QWT 4.1.67 - Feb. 2022

@taradiddles; date: 20 Feb 2022

Windows:

  • installed from scratch
  • build/iso: 21H2, downloaded from Microsoft
  • ram used when installing: 4GB
  • ram usage after install: 1.1GB
  • disk space usage after install: 12GB

QWT:

  • first installation
  • installed just after windows’ first boot
  • features selected during installation: Xen PV drivers
  • features that were tested to work:
    • copy/paste between qubes
    • copy files between qubes
    • attaching usb devices to the qube
    • networking
    • time/clock synchronization
    • XEN PV disk driver
    • XEN PV network driver
  • features that don’t work:
    • user migration from c: to the qubes’ private volume

Summary / notes: “vanilla” windows really feels sluggish, it then takes a lot of time and patience to remove bloatware and optimize the vm to make it usable.

R4.1 / Windows AME 21H1 / QWT 4.1.67 - Feb. 2022)

@taradiddles / 12 Feb 2022

Windows:

  • installed from scratch
  • build/iso: ameliorated 21H1 (downloaded ISO).
  • disk space required by the installer: min is 16GB, I’ve set it to 20GB
  • ram usage after install: <1GB
  • windows update status: disabled

QWT:

  • first installation
  • installed just after windows’ first boot (windows AME has windows update disabled anyway).
  • features selected during installation: Xen PV drivers
  • features that were tested to work:
    • copy/paste between qubes
    • copy files between qubes
    • attaching block devices to the qube (no ‘eject’ functionality)
    • attaching usb devices to the qube
    • networking
    • time/clock synchronization
    • XEN PV drivers
  • features that don’t work:
    • user migration: the profile on c: wasn’t migrated (again, maybe because of AME tweaks).

Summary: windows AME is really snappy and works well so far but it lacks features like appx (windows store) that could make it a no-go for some.

Windows 11

R4.1 / Windows 11 Pro 21H2 / QWT 4.1.67 of 2022-02-14

@GWeck; date: 23 Feb 2022, updated 26 March 2022

Windows:

  • installed from scratch as template VM, using TPM-disable patch during installation
  • build/iso: 21H2, downloaded from Microsoft
  • ram used when installing: 4GB
  • ram usage after install: 4GB
  • disk space usage after install: 15GB

QWT:

  • first installation
  • features selected during installation:
    • Base Xen PV drivers
    • Network and Disk drivers
    • Move User Profiles
  • features that were tested to work:
    • build / use AppVM based on that template
    • setting decent screen resolution for non-seamless mode
    • copy/paste between qubes (both directions in and out)
    • copy files between qubes (both directions in and out)
    • attaching USB devices to the qube
    • audio output (somewhat scratchy)
    • user migration from C: to the qubes’ private volume Q:
    • networking (for AppVM based on that template)
    • time/clock synchronization using qvm-features VMname timezone localtime
  • features that don’t work:
    • attaching SATA and NVME devices to the qube (crashes the qube)
    • seamless mode

Xen disk and network drivers can be installed during installation or after completing the previous steps. Contrary to Windows 7, activation did not become invalid. After this, USB devices can be attached and used, and booting is about one third faster.

Summary / notes: rather slow, as well on booting and shutdown as on using; installation requires disabling the check for TPM 2.0, using the trick described in Windows 11 in Qubes - using Windows 11 is a good motivation for migrating to Linux :slight_smile:

User report template

The template below is meant to be improved ! It isn’t exhaustive by any means and most of the fields aren’t mandatory.

More detailed notes about a given Windows/QWT combination (eg. very detailed installation instructions, workarounds, hints/tips, user workflow, …) should be posted to a separate post with a “Guide” tag and linked to this wiki page in the user report: that way the post’s author is free to use whatever layout and amount of information he/she sees fit, and this keeps relevant questions/answers threads contained in a post rather than in the more “generic” comments here. That said it’s OK to add a bit more “free text” to the template when contributing a report to avoid having to create a dedicated post with only a few lines.

(In case you want to change the template’s text itself, please discuss any major changes in this post’s comments).

:warning: Copy the text in the text area below including the [details=...] and [/details] tags

[details="R4.x / Windows XXX / QWT XXX"]
@userxyz ; date: xx month year

Windows
- installed from scratch, or migrated from an older Qubes OS release ?
- build/iso [eg. '21H1', 'ameliorated 20H1', ...]
- disk space required by the installer [if known]
- ram used when installing [doesn't mean it is the required amount]
- ram usage after install [if known]
- disk space usage after install [if known]
- if display resolution was changed, does it work ?
- if audio was tested, does it work ?
- problems running the VM ?

QWT [optional]
- first installation or migration/re-installation over an older version ?
- installed just after windows' first boot, or after a full windows update ?
- features selected during installation if not the default choice [eg. Xen PV drivers].
- features removed during installation if not the default choice [eg. UAC].
- features that were tested to work [delete line that aren't relevant/not tested]:
  - copy/paste between qubes
  - copy files between qubes
  - attaching *block* devices to the qube [with widget under "Data (Block) devices" or with `qvm-block`]
  - attaching *usb* devices to the qube [with widget under "USB devices" or with `qvm-usb`]
  - attaching audio input devices to the qube [with widget under "Audio Input"]
  - networking
  - time/clock synchronization
  - XEN PV disk driver
  - XEN PV network driver
  - user migration from `c:` to the qubes' private volume to be able use the qubes as a TemplateVM).
- features that don't work [possibly with workarounds]: ...

Summary / notes [if any]:

Link to a specific post [if any - it could contain detailed instructions, known issues, workarounds, hints/tips, description of the author's workflow, productivity tips, ...]

[/details]
5 Likes
2

initial post ; imo it’ll quickly become unscrollable if more than a few people paste the template, so it would make more sense to have a dedicated user post for each setup (with the template at the top of their post), and only have a link to the post in this page. If so - should a new post category be created ?
thoughts ?

[edit: thinking about it, there could be a more general “xyz in HVM” category for such dedicated user reports, ie. not only restricted to Windows]

[edit2:I haven’t found a way to remove this post’s “user support” tag as it’s not a bug/issue]

3

I have now converted this into a wiki post. Not sure if that’s what you wanted, but basically now people can edit it to make contributions.

However you prefer. If you want to create more things, just create other posts in #user-support:guides and I’ll make them wiki-posts. You can then use this on as sort of an index.

My suggestion would be to keep it all in the same place for now. It’ll make it easier to collaborate as some stuff will need to be copy-pasted, probably.

I have also added now a table of contents, so on the right-hand side, you should see it. This should make it simpler to navigate.

4

Also, is the content of this supposed to replace the guides in the following doc?

5

Thank you @deeplow

My idea is that there’s only one wiki page - the one we’re commenting on now - that has basic info about installing windows+qwt, and user reports, potentially with links to dedicated user posts (not wiki pages - more on that below).

I have no idea how many people would create dedicated posts about their setup though - if there’s more than a dozen posts it may clutter the existing “guides” category so I was wondering if another tag should be used (your call).

Note: I took the liberty to go ahead with the content of this wiki page, but really, there’s zero problem if people more involved than me change it upside-down or scrap it altogether !

Either way the template will end up being copy/pasted: in my original suggestion/idea, the template is duplicated for each setup in the wiki page so depending on the number of user contributions the page could grow to the point of becoming difficult to read/parse. It might thus make more sense to ask people to create a dedicated post where they’d copy/paste the template + add whatever they see fit and find helfpul for other users. In that case the “user reports” section of the wiki page would then simply become:

Windows 10

(as said the links above would point to dedicated posts owned by their respective authors - but may also point to an external resource like a blog post).

BTW if that approach is chosen there could also be colors in front of each link, indicating whether it works OK, passably, or is broken ; but that would require more user/admin work.

Given the above, do you confirm that you prefer to have everything on the same page - if that’s what you meant by “keep it all in the same place” ? (users may still create dedicated posts with more info though).

Maybe down the road ? TBH windows docs are scattered all over the place (given that I’ve written a few of them I’m also at fault here). The purpose of this wiki page is to avoid the “you-must-learn-git-and-send-a-PR” approach which imho prevents people from making 1st time contributions. In that regard the forum is much, much easier to use (thank you for your work !).

6

Please forget the second part of my reply above, I’ve updated the template’s code to use collapse/hide tags and it’s working pretty well (except if you have an issue with those of course).

7

Followed this. Worked like a charm, execept for this. Only tested inter-vm copy so far.

8
9

(I’ve updated the page to mention the cdrom issue).

pinging @deeplow @GWeck, @jevank, @brendanhoar, @adw + anyone interested of course: any remarks/fixes you’d like to see on that page ? I think I’ve contributed what I could, but happy to help further if needed. You guys also feel free to change whatever you want (and correct my English - I’m not a native speaker).

@adw: should I send a PR to add this link to the official doc, or should we wait that this page gains a bit more traction ?

btw some instructions are outdated here and there (like what works and what doesn’t in the doc mentioned in this wiki) but I don’t have much time to fix them - anyone willing to do that ?

lastly: the forum doesn’t send notifications when there’s an edit, so are contributors expected to both post a comment (to send a notification) + edit the page when documenting solutions to issues like the cdrom issue above, or should they just edit the page ?

10

@adw: should we update the docs on creating Windows VMs and installing QWT that are existing for Qubes R4.0, or shoukld we create two new sections? The first possibility would probably make the existing text even longer and more convoluted, so maybe a new text based on the QWT provided by @jevank might be easier to understand.

To all of you: Who could create empty templates for these two issues? I’ll gladly help with filling them up.

11

I added two reports on Windows 7 and 11. From earlier tests, I saw that Windows 10 behaves exactly like Windows 11, just a bit faster. After all, it is basically the same system, just with a slightly modified desktop.

3 Likes
12

I’ve just re-read the QWT community doc: there’s a lot of info there - which is great - but it will take a significant amount of work/time to find out what content is still relevant for R4.1 together with the updated QWT tools, vs. what part is outdated.

Having spent a considerable amount of time writing detailed guides/doc a few years ago, and seeing how most of their content hasn’t aged well, maybe there are a few important things to agree upon before you - or anyone - spend a lot of time too:

  • Should content known to be outdated/non-relevant to the current Qubes OS releases be deleted ? In a perfect world with unlimited resources it’d be nice to have docs for each release but it’ll be much easier to just stick to the current version and scrap old stuff - IMHO.

  • Should content that isn’t known to work with the current release be preceded by a “This content is untested for R4.1” banner ? (that could be because the instructions didn’t mention what release they applied to and testing to see if they’re still relevant would take time)

  • Should new content always mention the release they apply to - eg. “Those instructions are for Qubes OS Rx.y” ? (I think it should, rather than trying to find out later on what release the original author used).

  • Content specific to QWT: since it’s a “fast moving target”, at least for now, decide what to do with the QWT doc; eg.

    • Add a “banner” at the top of the doc that content might be outdated, and redirect to this wiki page ?
    • Add banners to sections that are known to be outdated, or unknown to work with R4.1 ?
    • Temporarily replace the link to the QWT doc with the wiki page, until the doc’s content is fully updated to reflect the current qubes release / QWT version ?

  • More generally, favour the forum’s wiki functionality over community/official docs to publish community guides and only put links in the community/official docs ? The you-must-send-git-PRs approach proved/proves to be too much of a hurdle for people to contribute stuff ; compare to how easy it is to create a post here for posterity with a “fyi that’s how I solved that, hopes this helps others” (which can then be improved upon and transformed into a wiki guide). It doesn’t help either that even the github qubes-community project, which ought to be much more “relaxed” than the official docs, seems too curated.

@adw - that’s your area here - thoughts ?

1 Like
13

Some additional information on my QWT installation in Windows 7 and 11: I transferred the rpm installation file to dom0 and installed it there with
sudo dnf install ~/Downloads/qubes-windows-tools-4.1.67-1.noarch.rpm
(no security problem with that, as it is a test system.). The installation of QWT itself could then be started via
qvm-start <VMname> --install-windows-tools
The Windows VM then had an additional drive containing the msi installation kit, which could be started and installed QWT.
So the standard way of QWT installation is working without problems for both Windows versions (and probably also for Windows 10, which I did not test).

1 Like
14

I would suggest waiting until it’s likely to be more helpful than harmful to regular users. I don’t know whether it’s reached that point already, but sometimes outdated information can be a trap for unsuspecting users.

If I understand correctly, these are all community docs, so it’s not my place to decide, though I’m happy to offer my advice and thoughts. Ultimately, it’s up to the community to decide, though, as the official Qubes documentation policies do not govern the community docs.

If you’re curious how this would be handled if it were in the official docs, here’s our current policy on release-specific documentation:

This isn’t strictly enforced to the “letter of the law.” None of the documentation policies are. We strive to follow the principle of merging PRs that are net improvements, even if they fail to comply with some policies, because the docs are still better off. (This is an instance of not allowing the perfect to be the enemy of the good.) PR #1190 is an example where an exception to the usual release-specific doc policy was made.

We don’t expect to have a new documentation system with support for release-specific docs for a while. (It’s being worked on.) I’m not sure how the community docs are handling release-specific docs. Might be in the same boat.

At any rate, my main piece of advice on this point is that Qubes 4.0 will still be supported until 2022-08-04, so it’d be wise to consider how replacing any 4.0 content (as opposed to merely adding 4.1 content while preserving 4.0 content) might affect users who are still on 4.0 and who might still be relying on that documentation.

One point worth considering is that, with Git-based documentation, nothing is ever truly deleted. It’s always possible to recover previous states of the documentation via the Git history. Granted, this is less accessible to less technical users, but GitHub makes it fairly easy for others to just provide them with a link. PR #1190 is an example where this was used as a quick-and-dirty “poor man’s release-specific docs” solution, which was fine because it’s only temporary until 4.0 reaches EOL.

Also, I would again advise caution about what is considered “outdated/non-relevant to the current Qubes OS releases.” Sometimes, after people upgrade to the new release (in this case, 4.1), they mentally consider all older releases (in this case, 4.0) no longer “current,” even though they are officially still current and supported. I see this happen a lot in the official docs, where people try to replace/delete content that stable users are still relying upon, and I have to actively work to prevent it from happening.

These are the sorts of considerations that we’ve been struggling with for a long time now as we try to figure out the best way to manage release-specific docs. I won’t recapitulate the lengthy discussions here. (Feel free to search them out in the mailing list archives and in qubes-issues if interested.) Where we’ve landed is: status quo policy for now while working toward migrating to Read the Docs.

The community docs are a bit different, though, so the same plan may not apply. It might be easier for the community docs to get away with “lighter” methods of release-specific organization.

I mean, this is really a matter of how the community docs are managed, which is just as much up to you as it is to anyone else. Such is the nature of community-run things. But whatever works best is fine. I don’t think anyone knows a priori whether the forum or GitHub will work better for this. It’s probably best to experiment a bit and just try your best. It also helps to be adaptable. The hard part is producing the content. After that, there’s little risk associated with posting it in the “wrong” place, since that can easily be changed with minimal additional time and work required. (For example, if you try the forum first, but that turns out to be a bad idea for some unforeseen reason, you can probably just copy/paste whatever you have at that point into the GitHub community docs, post a link to the new place in the old thread, and ask the mods to lock the old thread.)

1 Like
15

The windows documentation is probably not “harmful” but it doesn’t seem really helfpul either.

I’ll add that “suboptimal” is better than nothing: well-formatted, typo-free, detailed instructions like most of the official/qubes-community docs take a very large amount of time to write (been there); in comparison the forum makes it easy to contribute quick-and-dirty instructions, which could potentially make their way into a qubes-comunnity or official doc after a few rounds of refining. But an issue with forum posts/guides is visibility - ie. how to search/find them (for instance in hindsight the title I’ve picked for this windows post could be improved). IMHO that’s where it would make sense to link forum posts that are deemed helfpul in the official/qubes-community docs (obviously with a “work in progress / use at your own risks” header); for seemingly such popular tasks as creating a windows qube this will definitely save people some time, rather than loosing time following outdated instructions.

[offtopic - here’s an illustration: the current rpc policy doc isn’t relevant to 4.1; this article describes the new format but it’s not easily found (at least it wasn’t for me) and being almost 2 years old it isn’t clear if something changed while coding 4.1’s policies. A “suboptimal rather than nothing” approach would be to add a quick-and-dirty note at the top of the current doc with a link to the article, until somebody spends much more time reformatting the whole document and dealing with PRs back-and-forth (the “good”/“perfect” but time-consuming approach). I considered sending a short PR but there’s always this idea that official qubes docs are too well written to allow that kind of “kludge” ; what’s your position ?]

Ah, nice - I’ve just read related posts/issues, good to see there’s some progress in that area !

(and thanks for your detailed reply btw).

1 Like
16

Agreed. Hence our policy of merging net-beneficial PRs even when they fail to conform to the doc style guide.

By all means, feel free to submit PRs to add good links in the “External” section of the doc table of contents. We have always welcomed and encouraged this, though precious few contributors take the time to do it.

I say do it! Again, our position has always been: Don’t allow the perfect to be the enemy of the good. Any PR that is a net improvement to the docs is likely to be merged, even if it makes some things worse, and even if it doesn’t follow all the guidelines. (We have to use our judgement, because some things would be too extreme to allow, but this is the general principle we strive to follow in most cases.)

Also, if this is what you’re going for, please try to communicate that in the PR message. It can be hard to tell the difference between these two types of situations:

Type A: Person never bothered to read any of the doc contribution guidelines, style guide, the rest of the docs, etc. Submitted a bad PR out of ignorance and/or laziness.

Type B: Person knows full well that there are problems with the PR but believes, nonetheless, that it would be a net benefit. Doesn’t have time to do more right now.

Often, people submit PRs with zero commentary or explanation. Just a commit that changes a bunch of stuff, where it’s frequently unclear why anyone would want to make such changes. It would really help if the Type B folks could say a few words to differentiate themselves from the Type A folks so that I don’t reject their PRs due to misaligned expectations and misunderstanding.

1 Like
17

I’m stuck by trying to install the new qubes tools.
I startet a disp.VM and made there all the steps from jevank (1-3).
The 4th step stucks and show me: file not found by glob: qubes-packages-mirror-repo/dom0-fc32/rpm/qubes-windows-tools*.noarch.rpm

the rpm folder is empty

best regards
qun

18

I’ve just rebuilt QWT and it works fine (although on a fedora-35 build vm, not fedora-34). Are you sure there was no error during building and that you pasted the right instructions ? (it’s easy to mess up copy/pasting - maybe you pasted the same instructions twice ?).
If you’re sure you did everything right, maybe file an issue ?

19

Ok, I just did not look at the errors after the step 3 :smiley:

[MIRROR] wine-core-6.3-1.fc32.x86_64.rpm: Curl error (23): Failed writing received data to disk/application for https://mirrors.xtom.de/fedora/updates/32/Everything/x86_64/Packages/w/wine-core-6.3-1.fc32.x86_64.rpm [Failure writing output to destination] [FAILED] wine-core-6.3-1.fc32.x86_64.rpm: Curl error (23): Failed writing received data to disk/application for https://mirrors.xtom.de/fedora/updates/32/Everything/x86_64/Packages/w/wine-core-6.3-1.fc32.x86_64.rpm [Failure writing output to destination] Error: Error downloading packages:   Curl error (23): Failed writing received data to disk/application for https://mirrors.xtom.de/fedora/updates/32/Everything/x86_64/Packages/w/wine-core-6.3-1.fc32.x86_64.rpm [Failure writing output to destination]   make[2]: *** [/home/user/qubes-builder/qubes-src/builder-rpm/Makefile-mock.rpmbuilder:93: dist-package-build] Error 30 make[2]: Leaving directory '/home/user/qubes-builder' make[1]: *** [Makefile.generic:197: packages] Error 1 make[1]: Leaving directory '/home/user/qubes-builder' make: *** [Makefile:273: windows-tools-cross-dom0] Error 1
20

You need to increase VM private volume size I guess.

1 Like