Windows + QWT 3.2 on Qubes R3.1 Test Notes

[3n7r...@gmail.com]

On Sunday, September 11, 2016 at 12:30:42 PM UTC, Marek Marczykowski-Górecki wrote:
> I haven't tested this version on 3.1, but I think it should work. Just
> uploaded to current-testing.

Thanks!

Everything I tested is flawless **until the #updates stage**.

=================================

installation: no issues (up to #updates - see below)

multi-monitor: not tested
tested resolution: 4 megapixels
seamless mode: working
full desktop mode: working

secure clipboard: working
private storage: working
qvm-block: working
qvm-run: working
qvm-open-in-vm: working
qvm-copy-to-vm: working
auto-networking: working

=================================

Test Procedure

#install windows

QubesVMM: create templateHVM: "win-7"
netVM: none; vCPU: 4; RAM: 4GB
Private Storage: 10GB; System Storage: 40GB

qvm-start win-7 --cdrom=appVM:/path/to/iso
iso=en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso

disable UAC
disable updates
enable auto-logon
bcdedit /set testsigning on
shutdown

#install QWT

qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
clone win-7 to win-7-qwt-1, win-7-qwt-2

for each qwt clone:
qvm-prefs -s win-7-qwt-? qrexec_timeout 600
qvm-start win-7-qwt-? --install-windows-tools

[note re: PV disk drivers. For my first test (with just 1 vm), I disabled PV disk drivers and experienced 5-6 bsod's and/or permanent yellow hangs. No idea if there is any causality there. Reason for enabling PV disk is that installing .Net package required 30 minutes just to see any movement in the progress bar. (Might not all be due to PV disk - slowness might be causing other things to timeout?) With PV disk enabled, the update took less than 10 secs. I might guess that many bug reports are due to the INSANELY slow non-PV disk ops being mistaken for system hangs... To be fair, Virtualbox similarly has bad disk performance prior to installing Guest Additions. Surprisingly, no issues at all installing PV disk.]

#update Windows **Problems here**

wsusoffline update

[future steps:
enable netVM
windows activation
windows update
]

=================================

Made it to the end of the offline update process with 2 identical clones following the exact same procedure. One boots and is ready to go. The other received dom0 notice about outdated GUI protocol. Will not complete boot after repeated attempts. I can't make any sense of the logs - can't even figure out which ones are relevant. Just to rule out any difference in procedure that I might have overlooked, I have trashed both clones and brought 2 fresh clones to just prior to the update process. Please let me know how to proceed, ie which logs to collect.

One oddity that I noticed was that the Qubes VM Window name doesn't appear to be consistent. For example, with a Windows TemplateHVM named "win-7" and a user/domain of user@host; the name of the Windows window will alternate? between "[win-7] win-7" and "[win-7] host". Is this noteworthy at all?

I don't envy you Rafał. Thanks for working on this.

[3n7r...@gmail.com]

So currently, I have 2 Windows HVM Templates, named win7-qwt1 & win7-qwt2. They were installed with networking off so they should be identical. QWT (complete install) was installed without any errors.

I've been starting and shutting down each of them repeatedly with these results (Qubes logs attached):

win7-qwt1-1-fail: no desktop loaded; hanging on yellow state
win7-qwt1-2-success: successful boot to desktop
win7-qwt1-3-fail: no desktop; qrexec error
win7-qwt1-4 success: successful boot to desktop
(no logs) #5: success; bsod on shutdown (max cpu) (named "win7-qwt1")
(no logs) #6: success (named "host")
(no logs) #7: success (named "host")

win7-qwt2-1-success
win7-qwt2-2-fail: hanging yellow
win7-qwt2-3-success
(no logs) #4: fail
(no logs) #5: fail
(no logs) #6: success (named "host")
(no logs) #7: fail
(no logs) #8: fail
(no logs) #9: success (named "win7-qwt2")

As stated before, the VM window title is unpredictable - sometimes, the window is named "[win7-qwt1] win7-qwt1" and sometimes it's "[win7-qwt1] host". This is true of both vm's. A race condition? I am inclined to suggest that the VMs function more properly when they are named "host". Also, after all the starts and stops, I've got a leftover VM window that wasn't cleaned up properly and can't be closed.

[3n7r...@gmail.com]

[3n7r...@gmail.com]

2 more VMs installed with downgraded QWT 3.04

win7 + qwt 3.04 + pv disk enabled:
unstable; random crashes even after successful boot

win7 + qwt 3.04 + pv disk disabled:
6/11 successful boots
window title is [win-7-qwt-3.0] win-7-qwt-3.0 for all successful boots.
can't see window title for fails.

1 success
2 success
3 success
4 cannot execute qrexec-daemon; boot aborted
5 success
6 success
7 no error message; boot aborted
8 cannot execute qrexec-daemon; yellow / no desktop
9 success
10 no error message; boot aborted
11 cannot execute qrexec-daemon; yellow / no desktop