My question is, can the same full window size and single mouse pointer objectives be achieved when using a Linux-based HVM, such as one in which Ubuntu for example is installed? As far as I know, there is no equivalent "Qubes Ubuntu Tools" which facilitates this.
I know of course that regular Fedora/Debian/Whonix type PVM's based upon templates already do this perfectly, and I use them frequently for almost everything. I am asking specifically about an HVM for a special usage case. It doesn't have to be Ubuntu specifically, but it does have to be a Linux distro capable of running within an HVM under Qubes R3.1.
Does any such option exist?
> There's also a more general workaround for the screen resolution issue
Thanks Andrew. I was able to use the instructions on that linked page to fix the screen resolution as desired. Much appreciated.
> (as well as a pointer regarding Qubes agents)
I'm not currently familiar enough with the inner workings or code underlying Qubes Agents to take a casual shot at customising them, but it's good to know for future reference what would need to be tweaked in order to modify mouse pointer behavior. For now I'll just live with the dual pointers in standard Linux HVM's.
> I think you (or someone else) would have to put in the coding work in
> order to make this work in the desired way. However, a lot of work
> has already been done on the Archlinux Template (which, I assume,
> can be run as an HVM if desired, though I haven't tried it myself):
> Some work has also been done on an Ubuntu template:
Generally speaking, is it the case that running apps directly from a TemplateVM (whether it's Debian, Fedora, Arch, Ubuntu) is functionally equivalent and identical to operating that template/distro as a self-contained standalone HVM? Meaning if I wanted a Debian HVM, it's just as easy to clone my Debian TemplateVM and treat it as an HVM, instead of creating an actual new HVM the classic way and then installing a Debian ISO?
Is there any fundamental intrinsic difference between how a Template behaves if used in this fashion, and how a normal HVM would behave?
It's called an AppVM.
But my non-standalone HVM is used and intended for running software, as you say.
My HVM is a template based VM, it even has Qubes extensions in it and more.
It runs the same as any other AppVM.
It is PV and HVM.
So they should then be AppHVM?
Your interpretation is correct, I am mainly interested in the practical differences between running either a TemplateVM or a StandaloneHVM as a self-contained VM that doesn't depend on another VM's root filesystem.
As in my example, if I want a self-contained, non-dependent Debian VM it's far easier to just clone a Debian TemplateVM and use it independently as such, and thus get the single mouse-pointer desired, as opposed to creating an HVM and installing Debian there, and getting dual mouse pointers instead. If the two solutions are functionally the same, the first is more optimal.
However one reason I ask is that I seem to have in fact noticed some behavioral differences I wouldn't have expected, based on the descriptions above. The example case is unfortunately too unique to be likely duplicable by others for testing, but here it is nonetheless.
I purchased a Linux game that needs no installation, you just download it from the vendor website, unpack the tar.gz archive and run it from shell. At first run it asks you to input the license code received at the time of purchase, which is easy to do. After that, all future launches don't ask you to input the code again, as it's already saved and stored by the game.
On normal standalone Linux systems (whether an HVM within Qubes or a truly separate bare-metal installation on another computer/drive) this works as expected. Enter the code once, game works smoothly forevermore.
But on a TemplateVM, the code works for that session, but doesn't seem to "stick" or get saved next time around, and it has to be entered again each time the game is launched. While I'd understand and perhaps expect this if running from a TemplateBasedAppVM, since maybe the location where the game records the registration is on the rootFS and isn't remembered next time, I'm perplexed to see it occurring on a TemplateVM, which shouldn't have this issue saving data to rootFS if necessary - which isn't of course even the logical place for game data to be stored, as it should use a local directory like Home I would think.
I've even made sure to run the game's launch command as sudo in case elevated permissions are needed to write the registration data permanently, but without any luck.
As I said, this specific game issue is outside the scope of Qubes or its dev team to attempt to solve, but it does illustrate at least one behavioral difference between the two VM types. On a StandaloneHVM, the game registration is saved successfully as expected. On a TemplateVM, the registration is forgotten each time. To make things even more confusing, the registration is forgotten each and every time even within the *same session* of the TemplateVM being run. Shutdown and restart isn't necessary to trigger the problem. Launch game, enter code, proceed with game. Exit game, launch it again, and code is requested again, even though TemplateVM is still running continuously without interruption or restart. Thus, anything saved during session should still be preserved, and yet isn't.
Again, not asking for a solution here, just describing the scenario that precipitated the issue. Could just be some odd quirk of the game itself. Who knows.
Thanks again. Just to clarify, there is no actual step required to create a StandaloneVM "from" a TemplateVM, correct? All I am doing is cloning the standard Debian 8 TemplateVM and then operating that TemplateVM independently, treating effectively it as a StandaloneVM. Meaning, installing software in it and then then running that software directly in/from it, instead of creating AppVM's based on it and running the software from those.
If there is an extra step needed to transform a TemplateVM into a true StandaloneVM (not a full HVM) I am not aware of it, or doing it.