Testing Windows and QWT in R4.1

The whole point is command line program to be started first, and everything else works then. Logical choice is cmd.exe.

So in a win-template is to be put in a ProgramData/Startup folder shortcut to cmd.exe and to shut down the template. Then , and only then to create win-dvm-template in a standard way, not before that.

[user@dom0 ~]$ qvm-create --template win-template --label red win-dvm-template
[user@dom0 ~]$ qvm-prefs win-dvm-template template_for_dispvms True
[user@dom0 ~]$ qvm-features win-dvm-template appmenus-dispvm 1

Open its Settings again then choose Default disposable template - itself. Back to win-template and choose win-dvm-template for Default disposable template, too (the latter is not mandatory, but naturally).

Now we should get Disposable: win-dvm-template entry in the Apllication menu.

If applications aren’t listed there, they’re neither listed in win-dvm-template, so we need to Refresh applications in win-dvm-template, so we could get list in Disposable: win-dvm-template too.

If this doesn’t work for some reason, we can try to create correspondent desktop file in dom0’s /home/user/.local/share/qubes-appmenus/win-dvm-template/apps.templates/Accessories-cmd.desktop:

[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
X-Qubes-VmName=%VMNAME%
X-Qubes-AppName=Accessories-cmd
Icon=%VMDIR%/apps.icons/Accessories-cmd.png
Name=%VMNAME%: Accessories cmd
Comment=
Categories=X-Qubes-VM;
Exec=qvm-run -q -a --service – %VMNAME% qubes.StartApp+Accessories-cmd
X-Qubes-DispvmExec=qvm-run -q -a --service --dispvm=%VMNAME% – qubes.StartApp+Accessories-cmd

and/or (didn’t test neither because Refresh worked for me out of a box)

[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
X-Qubes-VmName=win-dvm-template
X-Qubes-AppName=Accessories-cmd
Icon=/home/user/.local/share/qubes-appmenus/win-dvm-template/apps.icons/Accessories-cmd.png
Name=win-dvm-template: Accessories cmd
Comment=
Categories=X-Qubes-VM;
X-Qubes-NonDispvmExec=qvm-run -q -a --service – win-dvm-template qubes.StartApp+Accessories-cmd
Exec=qvm-run -q -a --service --dispvm=win-dvm-template – qubes.StartApp+Accessories-cmd

in /home/user/.local/share/qubes-appmenus/win-dvm-template/apps/org.qubes-os.dispvm.win-dvm-template.Accessories-cmd.desktop

Either way, we want to assure to get an entry in application menu for cmd.exe.

Now, there are 2 use cases of such dispxxxVMs:

  1. If we want to start dispVM directly from the Application menu, we have to choose command line program there - cmd.exe. When started, such dispVM will have 2 cmd windows opened: one from the startup folder and the other one from our choice on start up. If we try to start any GUI program, it will not work regardless of the fact cmd.exe is in startup folder. We can now close one instance of cmd.exe. Annoyance a bit, but it works. From here, WIN key and the menu opens and we can use DVM as needed.
  2. If we are in some other win or any other Linux based VM for which we choose win-dvm-template as default disposable VM, viewing/copying/editing works well and only one instance of cmd.exe will be opened prior to GUI editing/viewing program - the one from the Startup folder ensuring win-dispxxxVM will be started and functional.

Final remark: such win based dispxxxVMs will not be shutdown automatically by closing first opened program (meaning cmd.exe) like Linux based disposables would be and I didn’t investigate the possibility to overcome this yet. Hopefully, someone might be able to help with this. Until then, and instead, these disposables have to be shutdown via WIN key -> Shutdown regular Windows procedure.

I’ll be glad to further clarify, being aware that my English is far from good.

1 Like

I agree, but then again why we couldn’t just bold it with font size 36: Warning, experimental feature. There’s no documentation about sys-audi/gui at all and someone has to be first. So, why us “Windowers” wouldn’t be the first ones, hahah.
I assure you that it’s more than easy to create sys-audio and it works out of a box, beautifully and fluently.

Please do not consider this post as insisting or forcing, it just tends to clarify and demystify things. I am absolutely aware from psychology that the first reaction on any innovation is resistance, at least for a split second, but it’s unavoidably always the first one (I guess @adw would confirm this, :slight_smile: ).

It is important that it works and that we have a resource to reference to for now - quoted topic from my post above.

The sys-audio theme is still rather unclear to me. I tried to create an audio VM using qubesctl top.enable qvm.sys-audio and got a qube with my audio device attached to it. Is that the new audio VM?

Setting qvm-prefs <VMname> audiovm sys-audio for some Linux-based VM works, but not for a Windows-based VM, as is to be expected. In order to make it work, the stubdomain patch is obviously needed, or, preferrably, the method suggested by @marmarek:

You can use qemu cmdline (like we do for IP config already), which makes libvirt/libxl patching not needed.

But was has to be done exactly? For me, with about zero Linux knowledge, this is somewhat confusing…

I am still experimenting on this. So far, a Windows 7 dispvm can be used from Windows and Linux qubes. There was no need to create the .desktop files - the menu entries were created alright on entering qvm-sync-appmenus <VMname> - trying to refresh the menus from the GUI once crashed the Qube Manager. Afterward, I could refresh the menus from the Qube Manager, too.

The Disposable: menu currently shows only one entry (for the IrfanView application !???), while the other entries only show in the Template (disp): menu. When I start this entry, the application starts well in a dispvm, and when I close this application, the dispvm shuts down. On using the dispvm from some other (Windows or Linux) VM, the dispvm does not shut down after closing its application.

sys-audio is still not reliable at my system: after reboot, audio was completely disabled for all VMs. Only after disabling sys-audio via qubesctl top.disable qvm.sys-audio, deleting the audio VM and rebooting, I got audio working again.

This still needs some exploration.

1 Like

Exactly

This

First run qvm-prefs sys-audio | grep -w xid
You should get something like

xid D 2

Number 2 is what we need.
Then continue to follow procedure from the quote post.
If you prefer GUI text editor, the whole point after is to copy that file to some temp location, to extract it, to make changes to init file by simply putting that number 2 instead 0 in a given line and to compress again and to put it back to original location by overwriting file there. Instead vim editor, you can use sudo gedit/mouspead/kate. geany (whichever gui text editor you have installed in dom0) to edit init file. Then reboot just in case and set sys-audio as deafult audiovm for win qubes with qvm-prefs win-qube-nam-here audiovm sys-audio. Start win qube and it should work flawlessly
If you’re still stuck at some point, please let me know at which point that happened.

Sure.

I now described using Windows-based disposables in the new QWT documentation (tested for Windows 7 and 10 - 11 will behave hopefully the same) and just added a pull request.

The tests showed once more how ugly Windows has become. Adding something to the start menu is more or less a nightmare.

A serious problem is here that you cannot enter something in the user-specific Autostart folder because that’s still on drive C: and so will be removed on AppVM shutdown. (Still a problem with the Move user profiles function of QWT in Windows 10 n).

I filed an issue Incomplete “Move user profiles” option in Windows 10 #7413on this).

1 Like

Thank you @GWeck. Really nice and helpful work there!

1 Like

Sorry for copy/pasting here, I just don’t have a Github account

@jevank jevank commented 4 days ago

In my environment the sound became perfect :slight_smile:

I thought first of all about the USB webcam, but there alas without much progress on Win10

@brendanhoar brendanhoar commented 4 days ago

Hmm

R4.1 win 10 still crackly after the just-released stubdomain update as well and in stubdomain I see currentclocksource=tsc.

It gets less crackly (but not perfect) if I busybox renice -n -30 $pulseaudio_pid in the stubdomain.

I haven’t rebuilt QWT since December 2021 tabit-pro repo content, so perhaps I need to do so for improved audio as well?

Unfortunately, adding tsc to kernelopts didn’t help to me too, as it seems it didn’t help Brendan.

@jevank, @brendanhoar, any updates on this meanwhile?

None yet: not much spare time with young kids and the added excitement of colds/etc. during a pandemic.

I do wonder at the output of busybox top - the virtual size of both QEMU and pulseaudio together is almost 4x allocated stubdomain RAM, but I’m not really familiar with the limited output of busybox top to know if that is worrisome or not.

Also found it hard to get stubdomain console working via sudo xl console $stubdom_id until I found that hitting ctrl-j after connecting got me to the shell and only then would Enter work. Weird.

Edit: Oops I meant xenstore, not pulseaudio above.

Edit edit: oops I was right the first time, just got confused when I checked stubdom under 4.0. Pretend I made no edits!

B

1 Like

Ah, sorry to hear, exactly the same here. Hope to find you all well soon. Thanks for taking the time to respond, though.

Meanwhile, it looks I got the winner (at least for me on Win7 x64)!
This is what I did:

  • I’m running kernel latest but I didn’t update it to x.17.x due to issues you are already aware of, so I’m on 16.
  • As already wrote, set all qubes to clocksource=tsc (that finding of yours was exceptional!)
  • I’ve upgraded, not updated to xen-hvm-stubdom-linux-1.2.4-1.fc32.x86_64 (sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade xen-hvm-stubdom-linux, for others less in the know)
  • updated sys-usb template to testing and restarted sys-usb (not of an importance in this my specific case, because I’m deplying sys-audio, but because of this case of mine)
  • I’ve decreased vCPUs to 1 (could try to half as well) for the win qube
  • set audio-model ac97 for the qube
  • started qube, downloaded and installed drivers from here
  • even without restarting anything - I got beautiful sound from Windows, finally!

Just, please, don’t ask why I did what I did. Basically searched a lot on stuttering in Windows guest virtual machines. The next step should be to try to switch from pulseaudio to alsa (if that is even possible and if makes sense anyway), but thankfully, it finished here.

Hopefully, some of these would help to at least some of you.

Wait, I have to play that song once again in a win qube…

2 Likes

Hmm getting an ac97 driver working in win10 looks headache-inducing.

I also wonder if we’re using all of the performance capabilities of Xen/QEMU under R4.1 for Windows HVMs.

Does Xen 4.14 support any of the viridian/hyperv options to allow the Windows VM and/or QEMU to elect to use lower-impact non-emulated hardware access?

Looking at the qemu command line given to the stubdomain, it looks like we are neither using viridian nor hyperv enlightenments even though my read of xen.cfg is that viridian might be available in the current config, but I don’t see it constructed onto the command line.

Hmm, under R4.1 in /var/log/libvirt/libxl/win_vm_name.log, I see “viridian”: “false” for the windows HVMs. This may be non-optimal.

I also see references to PIT, APIC and HEPT timers, but not TSC in that file, and viridian would allow non-emulated tsc…I think.

Are either the viridian capabilities or hyperv enlightenment options usable from Xen 4.14 (directly or via QEMU) in such a way as to give the Windows HVMs a performance advantage?

If so, can this be done without losing the PV drivers? Concern is that at least the second set of capabilities, hyperv options, may conflict with the MSR masking that Xen PV drivers expect?

B

Probably you will have bad luck there: I tried to find drivers for AC97 on Windows 10 / 11, and there are several offered on the net.But: None of those that I found could be installed. Either the installation terminated with error, or the drivers were simply not recognized by Windows, which complained that there was no suitable driver where I downloaded them.

On Windows 7, a rather old driver from RealTek could be installed and worked. The sound is quite o.k., but not really different from the standard ich6 driver. On Windows 10 and 11, the ich6 driver works, but the sound is somewhat scratchy, no matter whether you use 1 or 2 VCPUs.

According to the documentation, ich6 emulates ac97. So this may explain that, on Windows 7, both behave identically. On Windows 10 and 11, using the (practically non-existent) ac97 driver would probably not change much in terms of scratchiness. But these systems are scratchy in other respects, too. :stuck_out_tongue_winking_eye:

2 Likes

I have installed QWT in Dom0 from the testing repo (4.1.68.1), and I start the Windows qube with --install-windows-tools. The ISO is shown in the Qubes devices widget, but it never appears as CD-ROM in the Windows qube.
It is a fully up to date Windows 10 installation(imported backup from Qubes R4.0, but as QWT was never installed before, that shouldn’t matter afaik.)

I installed yesterday Win11 as a template. I think one more thing should be mentioned in documentation. Win 11 not let You to install it on VM without internet connection. So if You want to install it in template You have to shift+F10 again when it shows You that You have to connect to internet, start taskmgr and kill Network Connection Flow.

Also I have a question since I’m not install QWT on that template yet. Is QWT setting proxy for windows updates?

I checked with a native Windows 10 Template VM (QWT never before installed) with stubdom-qrexec on and off. Both times, the CDROM appeared in the explorer.

@jevank Any ideas?

Can you try to attach any other ISO to your Windows qube and check if it’ll appear in your system?

This looks like incomplete shutdown issue. @Szewcu did you try to disable hibernation? powercfg -H off

1 Like