-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2016-09-22 07:45, Otto Kratik wrote: > On Wednesday, September 21, 2016 at 9:03:30 PM UTC-4, Andrew David Wong wrote: >> Since your question is about the functional or behavior differences >> between TemplateVMs and HVMs, I take it that what you're really >> interested in is the practical difference between using TemplateVMs and >> StandaloneVMs as VMs which do not depend on any other VM for their root >> filesystems. >> >> The only significant difference I'm aware of is that using a TemplateVM >> allows you to retain the option of creating TemplateBasedVMs based on >> this TemplateVM in the future, whereas a StandaloneVM does not. If you >> one day decide that you'd like to have a TemplateBasedVMs based on your >> StandaloneVM, you'll have to re-create it as a TemplateVM. There's no >> (easy) way to turn a StandaloneVM into a TemplateVM. > > > 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. >
There are certainly Qubes-specific customizations that will cause a Debian TemplateVM (or StandaloneVM created from the Qubes Debian TemplateVM) to be different from a Debian HVM. (Some differences are beneficial, like fixing the double-cursor issue.) You may want to try running the game in a StandaloneVM rather than a TemplateVM, just to see if there's any difference. I afraid I don't know the solution to your issue, but it sounds like it might be some kind of file permission issue. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJX5G8WAAoJENtN07w5UDAwiakQAJ/csEo/MAqdRAXf+Q29lkS1 SG28LJJpvCfUiY07wwR8bu57CWCFIvMuR5l8QrnJOCWy0xLhMOeqR5H2LdIjp56W TFcEAgm9OC5v3LKTuvBcgHhiQOY8a+yMucOOjr59Xq9FzLD2v+mCDcbhKTrDxT/i e3p1dWNdj+0pzb70+adoU9s2jG6i7u7qxJXV5B534Dq0zES4LU002P+IBCnXM9bP xWGm+fsjkHfLM3ZlmYICzoW8s5Bsh0vZEmueMfxsI+pjaFLzqYMbv59CTbIQDKbs bwjDCa70mshPrLm+U3MA4btLMOowZYuCD2DhGvrpgXKOn9bJHwPL6ynwgfoFydA2 kJUpRL9tvVxsatmR36fWmTrjp/WJsVIWByTdJ+/eSH1IJ0guP1Qd5b1vUKvQcEMk bKzIMuezeWaZN80Miy4ug1m5GTUAWExz5I4YHEWLbeOamn03V0dqXOsdUkXhshiW v3e/aSt9xWArQDgTfav/Lh/69236dS2/+jMNVXQ/zMrtqeZgMQLXDe4EZzcqdhrU P07GohyBQQewrK/KcsoRctSO6lrLEyRRlCYgD85CqmUWLW0JUUQ0ESTjpPnn9iUE sxwV0yjDaSRUUaGA/AwQ+ZfdJQBljy77PgmtBYznb/nBRLyKPPGR8V/pSvfAFIc0 ZUfoGBRP7Ty+49d18avw =vfl6 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5c62fa40-08b9-ae79-bd96-6ffacb9120bf%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
