Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qubes Windows Tools (QWT) on R4 #3585

Open
taradiddles opened this Issue Feb 14, 2018 · 57 comments

Comments

Projects
None yet
@taradiddles
Copy link

taradiddles commented Feb 14, 2018

EDIT - Updated tools for R4 are in the current-testing repo

See Marek's comment (some issues remain); install with

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools

Note however that upgrading from QWT3 often fails (see below), and installing QWT4 in clean windows HVMs doesn't work for some users. Clone your VM before attempting anything !

  • 1st install: follow the official doc
  • upgrade from the 3.2 version: clone your vm first ! ; temporarily set debug to true and qrexec_timeout to a large value (eg. 600) or the vm will be killed before you'll be able to complete the setup (it takes a bit of point&click).
    • [FAILS] VM with SP1 and no other windows updates / upgrading over 3.2: at the following reboot, windows fails to boot and tries to repair files, which as usual doesn't fix anything (the VM might boot at some point, without the tools installed)
    • [TODO] VM with SP1 and no other windows updates / remove 3.2 version first and then install 4.0.0
    • [TODO] VM with latest windows updates / upgrade over 3.2
    • [TODO] VM with latest windows updates / remove 3.2 version first and then install 4.0.0

[The purpose of this issue is to gather user experience and document the installation of R3.2's QWT in Windows HVMs on R4, bugs found and workarounds until the tools are fixed (and hopefully have a new maintainer).]

Qubes OS version:

Qubes 4.0

Affected TemplateVMs:

Windows HVMs

Edits

  • Nov 13
    • add gateway network setting in issue 1
  • June 23
    • add @mossy-nw 's comment about properly checking the rpm sig
  • May 7
    • add note about VM qvm-prefs issue when creating a VM based on a windows template
  • Apr 23
    • add AppVM based on win TemplateVM issue
  • Mar 11
    • revert note about qvm-copy/move failing, it works fine (transient errors because of update mismatch on my system).
  • Mar 5
    • add note that since qsb #38 qvm-copy/move fails with 'request refused' because the tools aren't updated.
    • add qvm-prefs vmname default_user to fix copy location ; reference here
  • Feb 28
    • add rpm -K for rpm sig check (seen such questions in qubes-users ML)
    • add comment by @AJolly / QWT won't install with the 'move profiles' option disabled
  • Feb 18
    • more info on networking (DNS ips, ... + disabling the qubes net service)
    • copied some of the commands needed from the official QWT install guide
    • note about windows update + Xen VBD driver

QWT installation

Prerequisite: win7 x64 VM (see https://www.qubes-os.org/doc/windows-vm/).

Get the last QWT rpm here.

In order to check the rpm's signature you'll have to import Qubes Release 3 Signing Key in the VM where you are confirming the rpm signature. Get the key here .

Check the key fingerprint as follows:

gpg2 --fingerprint --import --import-options show-only --dry-run qubes-release-3-signing-key.asc

Or alternatively,

gpg2 --import qubes-release-3-signing-key.asc
gpg2 --fingerprint "Qubes OS Release 3"

And compare with the key's well-known fingerprint, which should be C522 61BE 0A82 3221 D94C A1D1 CB11 CA1D 03FA 5082

Import the key to the VM's rpm keyring:

sudo rpm --import qubes-release-3-signing-key.asc

You can now check the rpm's signature (more info on rpm signatures here):

rpm -K qubes-windows-tools-3.2.2-3.x86_64.rpm

You should get qubes-windows-tools-3.2.2-3.x86_64.rpm: digests signatures OK. If not, check that the rpm is properly downloaded, that the signing key is imported, ...

Extract the iso from the rpm:

rpm2cpio qubes-windows-tools-3.2.2-3.x86_64.rpm | cpio -idmv

And start the VM (assuming the iso is in the 'untrusted' VM):

qvm-start --cdrom=untrusted:/home/user/qubes-windows-tools.iso win7new

From the QWT install guide:

  • win cmd: bcdedit /set testsigning on
  • win cmd: netplwiz / uncheck 'Users must enter a user name and password...'
  • in dom0: qvm-prefs vmname qrexec_timeout 300

Note about Windows Update:

  • updating the machine is not required provided you don't enable the storage driver (disabled by default) in QWT' setup. QWT works on a bare SP1 install as well as in fully updated. See @dmoerner's comment below on how to install updates.
  • however, a fully updated Windows seems to be required in order to install xen's VBD (storage) PV driver:
    • on "stock" SP1, installing Xen's PV driver from either QWT or from Xen's official site results in either a BSOD or endless unfixable reboots.
    • after a full Windows Update (takes hours), installing Xen's official driver works flawlessly. Haven't tested when installing QWT with the storage PV driver after updates.

Note about QWT's 'move user profiles' options: @AJolly reports that QWT wouldn't install with the option disabled.

Issue 1 - Networking isn't set up properly

The PV adapter's status is stuck at "Identifying"; pinging an ip works but pinging a host fails, indicating a problem with DNS resolution. A tcpdump on sys-firewall indeed shows that DNS requests are sent to the gateway's ip and are rejected. The reason is that in R4 VMs are now using the exposed "/qubes-{primary,secondary}-dns" values, while R3.2's Windows Tools still use /qubes-gateway (whose IP in R4 is different from /qubes-primary-dns).

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

Issue 2 - Copy/Move functions

  • If the username you log on with in Windows is different than qvm-prefs vnname default_user (usually 'user'), then the 'QubesIncoming' folder is located in C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\ (and launching .exe's directly from this folder sometimes fail, in which case one has to copy the .exe somewhere else (eg. on the desktop) and run it from the new location). Fix it with qvm-prefs vnname default_user winusername where winusername is the username you log on with in windows.

  • In R4 the qvm-{copy,move} operations don't require the destination VM as argument: the destination VM is later typed by the user in a dom0 popup gui. When using R3.2 tools in R4 and copying/moving a file from/to a Windows VM, the user will be presented with a "destination VM" popup menu twice - once in the windows VM and once in dom0 (it is OK to leave the VM field blank in windows though).

Issue 3 - inter VM copy/paste doesn't work

Workaround: copy text in files and copy/move them accross VMs.

Issue 4 - creating Windows AppVMs based on a Windows TemplateVM

Problem: the private disk is present in the AppVM but QWT doesn't initialize it if it's empty (format + relocate user profiles). As a result user profiles aren't found at startup and the AppVM is stuck at "Preparing your desktop" for a 2-3 minutes until it timeouts. The vm is then barely usable because of the lack of user profiles.

Workaround (work in progress): copy the private disk of the TemplateVM to the AppVM - see this ML thread

Problem 2: Qubes doesn't copy a template VM's prefs when creating a VM so the new VM's prefs will be the "default" ones and won't be set properly for windows ; eg.

qvm-prefs winTemplate kernel -> ''
qvm-prefs winTemplate virt_mode -> 'hvm'
qvm-prefs winTemplate memory -> '2096'

qvm-create --template winTemplate --label red wintest
qvm-prefs wintest kernel -> '4.4.18-1'
qvm-prefs wintest virt_mode -> 'pvh'
qvm-prefs wintest memory -> '400'

Solution: set the preferences to match those of the templateVM.

Fixing QWT

See this message from Marek.

@andrewdavidwong andrewdavidwong added this to the Documentation/website milestone Feb 15, 2018

@awokd awokd referenced this issue Feb 15, 2018

Open

R4.0 User Documentation Tracking #3495

7 of 8 tasks complete
@dmoerner

This comment has been minimized.

Copy link

dmoerner commented Feb 17, 2018

Thanks for this as well. These 3 issues aside, have you had success installing QWT in a fresh Windows 7 VM on Qubes 4rc4? I've been able to install QWT, but after shutting down the VM after the successful install, the VM never boots again. It either crashes on the initial black Windows loading screen, or tries to fix the problem and tells me it can't fix the problem. (I've now experienced this twice.)

The error I get is:

Problem Signature 01: 6.1.7600.16385
Problem Signature 02: 6.1.7600.16385
Problem Signature 03: unknown
Problem Signature 04: 21198045
Problem Signature 05: AutoFailover
Problem Signature 06: 2
Problem Signature 07: BadPatch
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Feb 17, 2018

These 3 issues aside, have you had success installing QWT in a fresh Windows 7 VM on Qubes 4rc4?
I installed on 4rc3 before the update to rc4 but there shouldn't be any difference.

I remember having a lot of crashes when I was trying to install Windows, which is what led me to write the instructions here and in #3592. Windows will try to fix the install (always unsuccessfully) when it detects that the previous startup crashed (that's why cloning after each successful installation step is important - once you get a crash you have to begin from scratch).
I didn't encounter any crash like yours (BTW, where do you get the error ? In one of Qubes' log files ?).
You may want to try the following (please comment if it helps so that I update the doc):

  • have you followed QWT's README ? (IIRC you need to do something like bcdedit... in an admin command prompt to enable test signatures).
  • make sure you don't install the storage PV driver if you select 'custom installation' in QWT
  • Windows being Windows, try to reboot at least two times after a clean install before installing QWT.
@github74829

This comment has been minimized.

Copy link

github74829 commented Feb 17, 2018

I have had success installing the tools, thank you very much.

Would you be so kind and inform me how I can disable the Qubes Network Setup and setup the network manually? I have tried setting the Windows 7 IP address to the one shown in Qubes manager and the DNS/gateway to sys-net, but that does not work.

@awokd

This comment has been minimized.

Copy link

awokd commented Feb 17, 2018

@github74829 From https://mail-archive.com/qubes-devel@googlegroups.com/msg02800.html:

So you can simply disable the "Qubes Network Setup" service instead of renaming the .exe

@dmoerner

This comment has been minimized.

Copy link

dmoerner commented Feb 17, 2018

After a third attempt to carefully shepherd the Windows updates, I was able to get the VM into a stable state and install QWT, seemingly without problems. (I did need to set qrexec_timeout 300 as the wiki suggested.)

@github74829: You can disable it in msconfig.

(For reference: The relevant error I found earlier can be found in "Startup Repair" when Windows fails to boot, rather than a Qubes log.)

@github74829

This comment has been minimized.

Copy link

github74829 commented Feb 17, 2018

I have renamed the .exe and did a restart but still no connectivity.
Here's my Windows network adapter setting for IP4 (IP6 is disabled):
IP 10.137.0.15 (as shown in Qube manager under networking)
Subnet 255.255.255.255
Standard Gateway 10.137.0.5 (sys-net)
DNS Servier 10.137.0.5 (sys-net)
What am I doing wrong?

@dmoerner

This comment has been minimized.

Copy link

dmoerner commented Feb 17, 2018

@github74829
As mentioned in the mailing list post above, you need the DNS servers to be 10.139.1.1 and 10.139.1.2 (or something similar, just check /etc/resolv.conf in an arbitrary Linux VM).

@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Feb 17, 2018

@dmoerner : happy to read it worked. Do I understand correctly that you fully updated Windows before installing QWT ? I didn't run windows update in my VM - it always takes forever and my VM is network isolated so I simply disabled the service, but it will be nice to know so that I can update the doc. Also FWIW I didn't have to change the qrexec_timeout - maybe because my PC wasn't under heavy I/O when the VM was started.

@github74829 : I see a thumb up in the post above so I guess you managed to get networking up and running...

DNS servers: I was wondering whether their IPs were random or hardcoded when I posted to the ML; I now see they are hardcoded in /usr/lib/python3.5/site-packages/qubes/vm/mix/net.py in class "NetVMMixin" / def dns(). I'll update the doc with the IPs.

BTW this issue wasn't really meant to be a detailed guide like the instructions in #3495 but it looks like it would be helpful to people to have more detailed instructions. I'll try to update the doc tomorrow.

@dmoerner

This comment has been minimized.

Copy link

dmoerner commented Feb 17, 2018

@taradiddles Yes, I fully updated Windows before installing QWT. I find it doesn't take too long at all since they bundled SP2 into a single download.

I find it helpful to increase qrexec_timeout because in case you happen to get a BSOD or a similar crash in the VM, chkdsk won't complete on restart before qrexec_timeout automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher qrexec_timeout, chkdsk or the appropriate utility has plenty of time to fix the VM.

@github74829

This comment has been minimized.

Copy link

github74829 commented Feb 17, 2018

@taradiddles Yes I did, thank you very much.
Now I have to see what to do in order for Windows Update to run, it seems like it is stuck. I have already installed QWT, if they prevent Windows Update from functioning correctly, I might have to uninstall QWT, run the updates and re-install QWT again.

@dmoerner

This comment has been minimized.

Copy link

dmoerner commented Feb 17, 2018

@github74829
If you're trying to get Windows Update to run on a fresh install of Windows 7 Pro SP1, you need to manually install some updates by following steps 1-11 in this guide: https://plugable.com/2016/06/08/windows-7-wont-update-what-to-do/. Even after doing this, you may find you have trouble installing particular updates and may have to restore the VM from a backup made with qvm-clone; in that case, manually downloading the update and installing it is generally the easiest thing to do.

If your Windows Update appears to be in some sort of a broken state (determined by running Microsoft's diagnostic, here's a direct link: https://aka.ms/diag_wu), then follow this guide: https://support.microsoft.com/en-us/help/971058/how-do-i-reset-windows-update-components. Note that not all of the dll's will exist on Windows 7; that's fine.

I don't think that QWT in itself is likely to cause any problems with updating.

@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Feb 18, 2018

Thank you both for the feedback, I've updated the docs accordingly.

I don't think that QWT in itself is likely to cause any problems with updating.

It doesn't seem to, but I found out that with QWT installed you don't see the "updates in process" (or whatever it's called) when the VM is being shutdowned. Large updates can take a while and you're left wondering what's happening (I killed the VM too hastily the first time and it broke Windows. The second time I didn't do anything and the VM stopped by itself after a few minutes; during that time xentop showed the VM's CPU varying).

@AJolly

This comment has been minimized.

Copy link

AJolly commented Feb 23, 2018

I was also unable to get QWT installed if I unchecked the option to move user profiles.

@hugoncosta

This comment has been minimized.

Copy link

hugoncosta commented Jun 3, 2018

I'd like to chip in with my experience. Created a win7 x64 ultimate SP1 vm. Followed the instructions on this issue + doc/windows-vm. Doing the extend with 25g will net only 1.36gb of open space with 0 installations on the ultimate edition, so I increased it post installation. It'll really depend on the user, but I'd change it to at least 30GB as a conservative estimate.

Everything worked perfectly, thanks! I did notice a difference compared to R3.2. I had the memory set at 2048 and a maxmem of 4096, which worked fine, but on R4.0 it'd consistently crash my 2 imported vms. I only thought it'd be a nice idea to try it after I erased them and started building the new one. This is already stressed on the tutorial, just a fyi.

@evadogstar

This comment has been minimized.

Copy link

evadogstar commented Jun 5, 2018

Any progress with fixing this issues for Q4?

@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Jun 5, 2018

@hugoncosta : thanks for the feedback. I'll try to submit a PR to the win7 doc with more info about minimal volume sizes.

@evadogstar

Any progress with fixing this issues for Q4?

Unfortunately no, it's a community effort and nobody with visual studio experience has stepped in to help (IIRC at least one user tried to set up a build environment but it didn't work). I personally know nothing about building stuff on windows and don't have the time/will to learn it. Most of the issues seem pretty straightforward to fix though.

@mossy-nw

This comment has been minimized.

Copy link

mossy-nw commented Jun 22, 2018

hi @taradiddles thank you for compiling this helpful advice! Could you please add to " QWT Installation Check the rpm's signature... " something like the following?

Please import the Qubes Release 3 Signing Key in the VM where you are confirming the rpm signature (otherwise you will get the error qubes-windows-tools-3.2.2-3.x86_64.rpm: digests SIGNATURES NOT OK). Get the key here and import it to your rpm keyring using:

sudo rpm --import qubes-release-3-signing-key.asc

It is also a good idea to check the key fingerprint as follows:

gpg2 --import qubes-release-3-signing-key.asc
gpg2 --fingerprint "Qubes OS Release 3"

The correct fingerprint (I hope!) is C522 61BE 0A82 3221 D94C A1D1 CB11 CA1D 03FA 5082

@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Jun 23, 2018

Thanks, I've added your comment to the doc.

Interestingly, IIRC rpm -K was working without having to import the signing key when I wrote the doc (back in 4.0 rc something). Maybe the key was removed by 4.0 updates; or maybe I imported it for some other purposes and forgot about it.

@Polygonbugs

This comment has been minimized.

Copy link

Polygonbugs commented Jun 29, 2018

Thank you @taradiddles. I followed your tutorial QWT installation and finally made it successful. But after installing QWT, there is issue about two windows being opened in one Windows-OS VM. One seems to be freezed at Windows boot logo screen when booting is almost finished and the other one just normally show desktop of Windows-OS. Although OS is working well including shutdown of VM, could this be problematic (except visual experience)? I didn't yet test about seamless mode. Do anybody know how to set seamless mode? I can't see it on qvm-prefs command in R4.0.

@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Jun 29, 2018

two windows being opened in one Windows-OS VM. One seems to be freezed at Windows boot logo screen when booting is almost finished and the other one just normally show desktop of Windows-OS

That's likely because you didn't turn off the vm's debug property (run qvm-prefs <vmname> debug false)

@Polygonbugs

This comment has been minimized.

Copy link

Polygonbugs commented Jun 29, 2018

That's likely because you didn't turn off the vm's debug property (run qvm-prefs debug false)

Oh! Thanks. I forgot to disable debug property. Now it works charm! BTW, I'm wondering that seamless mode is dead option in Qubes-R4. I've searched a lot but I couldn't see how to do. If it is dead in R4, I think it should also be contained in as new issue.

@marmarek

This comment has been minimized.

Copy link
Member

marmarek commented Jul 8, 2018

@Polygonbugs the missing piece is a knob to switch it on/off. You can do it manually:

echo SEAMLESS | qvm-run -p --service VMNAME qubes.SetGuiMode

And to set it back to full desktop:

echo FULLSCREEN | qvm-run -p --service VMNAME qubes.SetGuiMode
@SvenSemmler

This comment has been minimized.

Copy link

SvenSemmler commented Sep 3, 2018

@tonsimple : Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz (Lenovo ThinkPad P51)

Since the majority obviously doesn't see this issue I am assuming that it must be something specific about my configuration ... however I have no idea what it could be or how to find out.

@Polygonbugs

This comment has been minimized.

Copy link

Polygonbugs commented Sep 5, 2018

@tonsimple @SvenSemmler
I'm currently using i7-6700K but my windows-7 is very slow as well. I'm pretty sure everyone using Windows-7 on qubes with QWT have similar problems(laggy and shadow problem). Though, I think it is more related to SSD performance rather than CPU. I've suffered similar issue on bare metal Windows OS on hardisk. It was very slow until I change to SSD. Really need any person to check if high end NVMe SSD can make performance difference. BTW, you won't be easy to see that lag and shadow effect on Windows-10 qube. It seems storage driver is more compatible on Windows 10.

@SvenSemmler

This comment has been minimized.

Copy link

SvenSemmler commented Sep 5, 2018

@Polygonbugs then you have a different problem. What I mean to report is that something in dom0 deadlocks. The easiest way to see it is to do a qvm-ls in dom0 which will be stuck at "please wait ..." until I either shutdown Windows 7 or the respective Qubes services in Windows 7.

This is so obvious and immediate that I have to assume only a small minority (or only I) see this behavior.

@telepath

This comment has been minimized.

Copy link

telepath commented Sep 12, 2018

* [TODO] VM with latest windows updates / **upgrade** over 3.2

I have an existing vm from 3.2 with QWT 3.2 installed, it's working ok as it is, but having the usual issues.
I tried upgrading the tools:

on dom0:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
[...]
qvm-start --install-windows-tools win7

but the cdrom drive does not show up in Windows.

If I try to attach the iso as cdrom, this is the result.

$ qvm-start --cdrom /usr/lib/qubes/qubes-windows-tools-4.0.1.3.iso win7
Traceback (most recent call last):
  File "/usr/bin/qvm-start", line 5, in <module>
    sys.exit(main())
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_start.py", line 172, in main
    drive_assignment = get_drive_assignment(args.app, args.drive)
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_start.py", line 100, in get_drive_assignment
    backend_domain_name, ident = drive_str.split(':', 1)
ValueError: not enough values to unpack (expected 2, got 1)

So I tried this:

on dom0:

sudo mkdir /mnt/iso
sudo mount -o loop /usr/lib/qubes/qubes-windows-tools-4.0.1.3.iso /mnt/iso
cd /mnt/iso
qvm-copy-to-vm win7 qubes-tools-4.0.1.3.exe

Then launching the exe file on the windows vm. I can run the installation, but after the required reboot, the machine won't start anymore. This is how far I've come for now.

@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Sep 12, 2018

qvm-start --cdrom /usr/lib/qubes/qubes-windows-tools-4.0.1.3.iso win7

should be:

qvm-start --cdrom dom0:/usr/lib/qubes/qubes-windows-tools-4.0.1.3.iso win7

By the way, to everyone tracking this issue: it'd be nice to get some feedback about what works and what doesn't so that I update the post (I'm the OP).

@hugoncosta

This comment has been minimized.

Copy link

hugoncosta commented Sep 12, 2018

@taradiddles, freshly installed Windows following your tutorial. Can confirm:

  • Sending files works but cannot find (or cannot receive) any files from other VMs.
  • Copy and paste works (wasn't working a couple of days ago, but using the exe to repair it seemed to have fixed it)
  • USB devices are not detected

Anything else I should test?

@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Sep 12, 2018

@hugoncosta : thanks for the feedback. If I understand correctly, you did a fresh install of windows and then installed QWT 4.x (ie. without installing QWT 3.2 and then upgrading to 4.x), am I right ?

Sending files works but cannot find (or cannot receive) any files from other VMs

Just to make sure:

  • is your VM's default_user property set to your windows' user name ? (see "Issue 2" in the OP).
  • can you send files from you windows VM to other VMs ?

Anything else I should test?

If you happen to have cloned your fresh windows VM before installing QWT, it'd be interesting to install QWT 3.2 first and then try to upgrade to QWT 4.x. Last time I tried it didn't work at all, but I noticed there was a newer version of QWT, maybe it'll work now.
However you'll loose a bit of time testing that, so don't bother if you don't have time, maybe someone else will report about it...

@telepath

This comment has been minimized.

Copy link

telepath commented Sep 12, 2018

qvm-start --cdrom /usr/lib/qubes/qubes-windows-tools-4.0.1.3.iso win7

should be:

qvm-start --cdrom dom0:/usr/lib/qubes/qubes-windows-tools-4.0.1.3.iso win7

same result, though. The drive does not show up in windows.

@airelemental

This comment has been minimized.

Copy link

airelemental commented Sep 14, 2018

@telepath If the iso doesn't show up, you can try copying the iso in as a file

qvm-copy-to-vm windows-7 /usr/lib/qubes/qubes-windows-tools-4.0.1.3.iso

and then mounting the iso file to D:/ (using for example WinCDEmu).

@telepath

This comment has been minimized.

Copy link

telepath commented Sep 14, 2018

@telepath If the iso doesn't show up, you can try copying the iso in as a file

qvm-copy-to-vm windows-7 /usr/lib/qubes/qubes-windows-tools-4.0.1.3.iso

and then mounting the iso file to D:/ (using for example WinCDEmu).

I like my variant better, as described above:

So I tried this:

on dom0:

sudo mkdir /mnt/iso
sudo mount -o loop /usr/lib/qubes/qubes-windows-tools-4.0.1.3.iso /mnt/iso
cd /mnt/iso
qvm-copy-to-vm win7 qubes-tools-4.0.1.3.exe
@telepath

This comment has been minimized.

Copy link

telepath commented Sep 14, 2018

I have set up a new Windows machine now, installing QWT worked fine, although I'm missing the explorer integration to send files. I could not find the correct call for that, is that documented somewhere?
Seamless mode also works when manually enabled, I've tried setting the reg entry on the template, but that had no effect.

Also I noticed that Windows EasyTransfer seems to ignore user data in non-standard locations, at least it did not detect any of my user data on the QWT 3.2 machine when I tested it. I don't think that is limited to Qubes, though ;)

@hugoncosta

This comment has been minimized.

Copy link

hugoncosta commented Sep 16, 2018

 is your VM's `default_user` property set to your windows' user name ? (see "Issue 2" in the OP).

Solved it, thanks. I remembered having problems finding the folder on Qubes 3.2, but I forgot how I found it. Anyway, everything is working, sending to and from the VM, copy/paste. You were speaking about QWT 4.x, I'm using the latest rpm from the OP, which is 3.2.2-3, where is QWT 4.x?

@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Sep 17, 2018

You were speaking about QWT 4.x, I'm using the latest rpm from the OP, which is 3.2.2-3, where is QWT 4.x?

qubes-windows-tools-4.0.1-3.noarch.rpm is available in the current-testing repository.

If you try to upgrade, don't forget to clone your VM because there are quite a few reports that the VM is left in an unfixable broken state on reboot. It'd be interesting to know if it works for you.
Otherwhise, QWT 3.x works pretty fine, save for the few minor issues described in the post.

marmarek pushed a commit to marmarek/qubes-manager that referenced this issue Nov 21, 2018

Added GUI for toggling of seamless mode for windows
Added two buttons to enable/disable seamless mode
for windows qubes.

references QubesOS/qubes-issues#3585
references QubesOS/qubes-issues#4342
@Geblaat

This comment has been minimized.

Copy link

Geblaat commented Dec 26, 2018

I have imported a Windows 7 VM with QWT 3.2.2.3 from R3.2(On R3.2: Windows first fully updated, then QWT installed incl Xen disk driver). It does work on R4(apart from the known issues.)
However, when I try to upgrade QWT to 4.0.1.3, it crashes during install and the VM will not boot anymore(hangs). If I try to uninstall the old QWT first, it also crashes during uninstall and won't boot anymore(hangs). I tried booting into Safe Mode afterwards as well, but that doesn't work. In fact Safe Mode doesn't work at all on R4, because I tried to uninstall QWT or upgrade directly from Safe Mode, but it hangs during boot.
I already increased qrexec_timout to 600 seconds in all cases.
Btw, this is on a fresh R4 install from 4.0.1-rc2. I have no 4.0 install.

@Geblaat

This comment has been minimized.

Copy link

Geblaat commented Jan 9, 2019

I was able to install QWT 4.0.1.3 on a new, clean, up to date Windows 7 VM, and features like inter-VM clipboard are working. However, when I actually start using the VM, it crashes quickly.
(Disk PV driver was also installed.)

@taradiddles

This comment has been minimized.

Copy link
Author

taradiddles commented Jan 10, 2019

@Geblaat , thanks for the feedback.

@ all: I haven't heard of people with a working windows VM with QWT 4.x yet - wondering if someone managed to get a working, non-crashing install. If yes, it'd be helpful for other users to describe how he/she got there...

As a side note it seems that QWT 4.x can be installed on Win10 but has stability issues too.

@brendanhoar

This comment has been minimized.

Copy link

brendanhoar commented Jan 10, 2019

I was able to install QWT 4.0.1.3 on a new, clean, up to date Windows 7 VM, and features like inter-VM clipboard are working. However, when I actually start using the VM, it crashes quickly.
(Disk PV driver was also installed.)

Everything I've seen so far indicates that the PV driver isn't working correctly in R4.0 and should be disabled during QWT installation.

@tonsimple

This comment has been minimized.

Copy link

tonsimple commented Jan 10, 2019

I really need a step-by-step of upgrading QWT to 4.x in an imported windows-VM template.
Installing fresh is not an option (the template has been tweaked multiple times to suit my typical windows-related work routines and I must, with great shame, admit, that I have not documented the tweaks well. Starting fresh would be quite hellish)

PV driver is not currently installed and I can live without it for a long while.

@Geblaat

This comment has been minimized.

Copy link

Geblaat commented Jan 10, 2019

It seems to be working for me now, though I haven't used the VM much yet. I haven't installed the disk PV driver because it crashes regularly.
Here's how to get it working(hopefully):

-Install Windows 7 SP1 64 bit (make sure to add expand maximum System storage for the VM before installing so you don’t run out of space)
-Don’t use Windows update yet, first install A: April 2015 servicing stack update(prerequisite for B) and B: Convenience Rollup for Windows 7 SP1.
-Use windows update to install security updates, reboot, repeat until done.
-Disable Windows Defender to minimize resource usage
-win cmd: bcdedit /set testsigning on
-win cmd: netplwiz / uncheck 'Users must enter a user name and password…' (I skipped this because I didn’t enter a password during Windows installation)
-in dom0: qvm-prefs vmname qrexec_timeout 300

-Reboot
-Install QWT 4
-During installation Xen PV drivers will ask for reboot, but installation has not finished yet, so click No.
-I also clicked No when windows wanted to format a new disk.
-Reboot when it is completely done. User profiles will be moved to Private Storage during boot and then you can use the VM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.