Fullscreen mode and/or single mouse pointer with Linux HVM?

[Otto Kratik]

With a Windows 7 HVM, initially upon creation it is a fixed small window size and shows two mouse pointers chasing each other within that HVM window. By installing Qubes Windows Tools, both of these limitations are removed. One single mouse pointer and full screen resolution are achieved - as well as seamless mode becoming available.

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?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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):

https://www.qubes-os.org/doc/templates/archlinux/

Some work has also been done on an Ubuntu template:

https://www.qubes-os.org/doc/templates/ubuntu/

There's also a more general workaround for the screen resolution issue
(as well as a pointer regarding Qubes agents):

https://www.qubes-os.org/doc/linux-hvm-tips/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX3FmBAAoJENtN07w5UDAwUzYP/iitko2uLYmpHkn5TQ+Li1b4
PuZTJvQPgx7WBwXMcBFD9W2/Zznx7AlA21WgDCw3Zr98e2qeg1zOZkjVgrk2yP1X
L3O28V2SIGqFos7ii/BcAb3mpmX6IohkQWb+EEoUZs4l9vVwFMisG54P8tPvDBEa
uICZVlPHPQnfVTUhUd4wQ6fZn6a0ENUO08prHhF9cMGy02/tx6vz+CC/ZmjwFnau
mHByFGczxAXkZlWZLuSUaNpu3kqj5gxufkno/Wo1GWVbVAj6V7oXIelkud6EjL44
RVUwb3jPXP0dFh5eoBZ7SZNckcjAadbHc9r0WhbfPnMH2AFFlZbT4zKQEhqs3RMA
11lK1anzIMTfXeiflTvy1meUyqVWCwVTDY2AU278N4LMkw+Mw7AJfrK2Qdbq7+PA
MyNzrjCoBo58wDhOwHwU0Y72qruT4sXkEMQsuI+fvT3sVgih3rBzNnQ+wzk0Iw0X
nXJek620iKvWn1CcQjE3j5EyMHzlZ46be+M+mutZVr0JNecaS73un5SblR+eGIf9
RHQXPIQZzEF70+K+1FPC2NQe5Ag8RTVBQKTy/iQ8pgIyeUnogHRHWk19npyJVWHV
jRs5hQmJUqkyKpFHBNrhzp+e2e9oP2exlsV6vIGjQ8cg9rYjs1+b5IbXQ8PyeIWw
X0qPTT7NTjcSsmXXmnI8
=exLY
-----END PGP SIGNATURE-----

[Otto Kratik]

On Friday, September 16, 2016 at 4:44:10 PM UTC-4, Andrew David Wong wrote:

> There's also a more general workaround for the screen resolution issue

> https://www.qubes-os.org/doc/linux-hvm-tips/

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):
> https://www.qubes-os.org/doc/templates/archlinux/
> Some work has also been done on an Ubuntu template:
> https://www.qubes-os.org/doc/templates/ubuntu/

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?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

The term "TemplateVM" describes any VM that supplies its root
filesystem to another VM. TemplateVMs are distinct from
TemplateBasedVMs, which depend on other VMs for their rootfilesystems,
and StandaloneVMs, which do neither. By contrast, the term "HVM"
(Hardware Virtual Machine) refers to any "fully virtualized," or
hardware-assisted, VM that utilizes the virtualization extensions of
the host CPU (e.g., VT-x). HVMs are distinct from PV (paravirtualized)
VMs, which do not require virtualization extensions from the host CPU,
and other variants such as PVHVM (PV-on-HVM).

So, TemplateVMs and HVMs are categorically different. The former refers
to the VM's degree of (in)dependence relative to other VMs in the
system, whereas the latter refers to the manner in which a VM is
virtualized. An HVM itself can be a TemplateVM (in which case it's
called a "TemplateHVM"), a TemplateBasedVM (in which case it's
typically just called an "HVM"), or a StandaloneVM (in which case it's
called a "StandaloneHVM").

For more on Qubes terminology, see the glossary:
https://www.qubes-os.org/doc/glossary/

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.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX4y3SAAoJENtN07w5UDAw2KMP/1q1m4hg+g60+vs+PgdMcVxI
BYOeVzVCO8E6RTIboRhMpoXMAxnbeAZC0LCdG8a2tzMMpkBJToI/xGCYkNcXsAGk
F0tAeDW2WTvQ+uaA3kOcrrWJr4FyCjLzZXfrKZAz+O2fGnFJmRaqGMbmTiZwggBi
o1ZakBbXszk557fKdN9u9P8TRZhZw/aAkawFr8iT8pTaPug5DYSggtjEt0JSIczk
skkTiGAvGbiQL6t4Zjq43eskRViKT09Dmuo6cjg4tS4oSctbuFn89qrrtavZ/Y6Y
ZaVryreIDBJgQ1Xy5Mk23Duw9mWAYg3Cgsw7EKNa9rlh9JsbZ9e36oarc/qJq16Z
PeADXaiRrpzYzeb26ju6ibEnp0QaU6f2AZAtECIM+Lej2h6cpZiW4BVHx4KsuA+Z
hfZYPHqwusH6pdROW6naGyjkv10ZmsK3eDyBg5335LrPon19Ak/X5exRIh3va86g
eQaCMlHKQpXCm+9b7k7HnkhvnAjMXi9+Y0cqBfJHi1BuhtE4iH6wiAr1I6cE5ndr
lgtTfRt5oyOsEKgv1YUaR60UOwyeVFOXCS+Cxlrp5TYXGcPUehEgcrsFj2YiymZu
py1HmSmTLuVDtCSQhAr5PGGLBIYdRvGXt1avv8/PKob6PUGnfiiGI7GEVKWheE8Y
lkpuRNNZd8nSyYEViczY
=YSee
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Correction: "HVM" usually refers to a StandaloneHVM, not a
TemplateBasedHVM. We don't actually have a term for a TemplateBasedHVM
(so I'm adding that to the glossary now).

> For more on Qubes terminology, see the glossary:
> https://www.qubes-os.org/doc/glossary/
>
> 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.
>
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX4y7LAAoJENtN07w5UDAwu6sQAKW+Sw3Wj78yBUjjilB3pJgX
H2nFazvp7S9/UONmwPCDkNcYIKG1cqi6GxYepB4JPBhSZrzf9M0iJoYo+8xSHF7m
ZrieNE1Po2Bn2i8dtz6iFeyqQmyEvRe8n1q4LAysnOohJc8jdm6War5Zt97aSc+j
u9mb7haC1RDCJ5dByB9mhNxwELfbtzEYIgiVNP143eUNj+e3fhRGG/itAV+YQ02r
XY7gtPoYJ9Y24g58eklH4z0EYjMUAJHX83uEEDnEi82ocdtfrM1sS2V9OIv8951L
f1rsfebJpRZU8uTaOe/lFePqdi1JMOk80T54eJahOnIKZ7lH10olRQJKidDAdyLG
KsD3o5R6bn2gDvW/D9QVV0L7nx/Sn7nSa7CO4QnutOHEH9V52Pwa+eQsNa7OXBmu
v4R5D9spLRAl0RqAy3zdtzfuXAGu2PH5FQbn0U1Xwc40picpePigf6Ci6RfKtX2H
S5JqKqc4YeaCrmIZJMsQCgkJdSeABxfBVq34QFr3FvoFgIDqYRPMgzR/JVLUgIAl
Nz4j1euUZHhdYcP5uLIdAdHYoHhCFvdlh1nEyvMRbeCgDdb07Jo8GFDR4pxGP7TQ
ichAJoRGeq358JMIetQNgXqBtB370Lh4nUkPl63tKhvdYnzxzKl2bqRZqvPO5BUT
MrXkXwhiXlUA8jwkaOqt
=lv67
-----END PGP SIGNATURE-----

[Drew White]

On Thursday, 22 September 2016 11:07:39 UTC+10, Andrew David Wong wrote:
> Correction: "HVM" usually refers to a StandaloneHVM, not a
> TemplateBasedHVM. We don't actually have a term for a TemplateBasedHVM
> (so I'm adding that to the glossary now).
>

It's called an AppVM.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

No, the term "AppVM" (Application Virtual Machine) is a functional term.
It simply refers to any VM that is intended for running software
applications. AppVMs can be either TemplateBasedVMs or StandaloneVMs
(but never TemplateVMs), and the designation is independent of the
underlying virtualization method (PV, HVM, etc.).

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX4zMeAAoJENtN07w5UDAwKLMQAJSmyhEU8JhY/HChWRDdPW1d
CE5wnu99/N+oeEkF+Ltd9Tov6rx3jnU9lvamsCI5Ugd+5lPxg/TQfM5pfxaJwipU
ImKIPbI03hZf48df66o/BisNi3y0ZMGgWgitHSLo83HZ0CFnEXCxzDdoi3ycJpHf
3JNbr/IrROl7X0JOgsl3uztnhFhRJpY+HBI1nrQOEyYt8tdioScXP4BXP8WTY6G4
3vCCVtHO93ikOXjseKj0IJ/lyiCqGMmviFFcdQhrKk90nvmDdv8O2eGhGzn0CBU/
RBvHFKAOxOpL6gl7oNma2p/chfjIhIkhRp527bMKUTiIcKpTwsw2Dh0GgBgHe5Aw
BTZWswlmbB6gxQ5KeCahdcWkOQqEcoJ9qCYK00TcIqP6hBYgMxFk0gkAN9PuMteI
6JxbllDHKl9b0gKF2v7nzKu7rIlvloYrol9rVwtMRkwDmHTvMgjo26SETuGR5HrE
LGiL3Kb1hz+wzLPOsrr+kOD02cuk15kFnnbdqC0PHp25ZFEbSW++fdCE8FLO6+Dl
U9zsRZi9yJcBWKGNW1bgK2tUbB6IM9qVLTWHFmPW6IZS9S+1m5LSbS6BN1gUoIpd
vlPabda+6eziGREKS/UdtAY9g4Ry9MVY7G/BDjz3HPGCbccLYE/DI2ePldNnUKVj
wfWqAVFO3bddwcipgWvb
=9YoD
-----END PGP SIGNATURE-----

[Drew White]

On Thursday, 22 September 2016 11:26:12 UTC+10, Andrew David Wong wrote:
> No, the term "AppVM" (Application Virtual Machine) is a functional term.
> It simply refers to any VM that is intended for running software
> applications. AppVMs can be either TemplateBasedVMs or StandaloneVMs
> (but never TemplateVMs), and the designation is independent of the
> underlying virtualization method (PV, HVM, etc.).

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.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Then your TemplateBasedHVM is an AppVM. But it doesn't follow from that
fact that TemplateBasedHVMs should be called "AppVMs" rather than
"TemplateBasedHVMs." The reason is simple: Some TemplateBasedHVMs are
AppVMs, but not all AppVMs are TemplateBasedHVMs.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX40CRAAoJENtN07w5UDAwdWgP/R7absnrk8OvF/uEQMAEpREF
X//TLoSdToVNjlQdIzI/iQQswInZQotNwKE0I/ix1zmdhPpjOPtMmOJX7JJiPxHD
hJlQYAG/ROEFsQVkGfLZck1bdKerHsciXvsaDaULZ7wK9+3FSeN2a9LT/fkyRWdJ
K9x6ydnTjd74nHVavKJ9BzxgpC5sOAHWhu2iMdN9rxzWSF12d35X5J5C4WAdGgDY
Xq6ZnaEUMrWcjTJ6lWaa37k9AY/vtQKYjnzXyORv1mbB7DxNEd1VLSp0oo75lx46
HkoqeKwvq0G/rmCr/pU02Snv8c855/VVPLRPYgNwgq7/slH/mSf5RlOOKdNKfn/P
GbVj1tk+C2NXpqVLnU+RqC2cGuCgVznxUYsGuvWuaAvvweo5S74cHd5oad1HrPdO
B6nlv7tbrX7EqB6SzhE3K/+EcV1+lVhhodU54ou3/evYG9NTa4RQOzp5WSQazSvx
g8/xi4YghWPgo71lPELEehW117F8yBp5ldNCdJ61k+OV5ulwiviNW0JkFhtaKoS2
+dc33YxpBJn3w1EXODFZ0N+dSv/okd/FX1FgCAMP246o3iIOSwrct1cTMmauKuud
owC6yZSwMD2UugaLMr2usMDjSatDnGoDVu+NknN+U+taDmElh5RMwjB5UKPscRxy
RnRn4FOdoMfHpnk4n4z/
=FFdO
-----END PGP SIGNATURE-----

[Drew White]

On Thursday, 22 September 2016 12:23:31 UTC+10, Andrew David Wong wrote:
> Then your TemplateBasedHVM is an AppVM. But it doesn't follow from that
> fact that TemplateBasedHVMs should be called "AppVMs" rather than
> "TemplateBasedHVMs." The reason is simple: Some TemplateBasedHVMs are
> AppVMs, but not all AppVMs are TemplateBasedHVMs.
>

So they should then be AppHVM?

[Otto Kratik]

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.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

No, because not every HVM used for running applications is based
on a template. Some are standalone.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX5GsjAAoJENtN07w5UDAwHX4P/3aRDgRFrZWdJ0c/ephpF97j
h/GR9IlzY/QGRO4azSn2+dNCMgz93pXCb08qyDTmzLtWYBj/um1Sxid8MYUQDOJs
Tle1gNgo0CTkirlLhEe8pS32/uYU8VF2SWVtQtUC9kEoveR9SMYMud3cyoHqLEaH
wV4DPmZ4Kx8hWdorLwT+wMziDACz/Zw8QT0jNn3EzTD3fbZZ5Uq2Dc5NFtuhIGEZ
y5+6GPv7HaGhTL56rdU8UmPs+uCaNgcah+t+T1Gwd5p/6/jb7kSHw2Fy70J5ljPT
JnaZw2d2p+aZo6jQVO92LHI2Q1LiPE0as8bAKF2kPEk4NR/HGUzsE7IZjkZ8acFc
WhjQM3pnDnSmbVGbolaSDgzCbFPIsZr8125ZO/Ekto0QeavuSuaue223d+S1ijd2
b6/73+eTGJFpjFfcllIb90q7S8A6YOTXkOH+IT7bbZcct9dAhsqZFA8AGnIg+ir0
j5WoP/54weknQP8H2HK3vtml5Z2pvlebdrjc4LvZi/Cfwj4QN5lKNqhh5WknnA64
JrzIfHDLTS/4Kqlh1xsVKisl8/qw1ja9a3G9Mqs0k7dvClq09rYqlo6dP8kxnnSM
COCIg65jIwe/VbNFi1cXIcHYgZYeBh9LutCPPr1KlGzqAgdChWyAoVaedN0KIGcI
Ns8t4kLuIPws5QysnM46
=4Ijl
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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-----

[Otto Kratik]

On Thursday, September 22, 2016 at 7:54:31 PM UTC-4, Andrew David Wong wrote:
> 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.

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.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

There is an extra step. In Qubes Manager, when you create a new VM,
you can check the "Standalone" box.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX56XoAAoJENtN07w5UDAwdQ8P/1YsQASwuL0NCWBya/fyGzCM
TShdPFAry5xRsCvQeCRyj4T20Ck7l0o1o7A2WtDstKZbpfGIsQY3EtozjBckYxyC
uDrnLJ4ZA/pq3BSoCFoC8+pxlODqVvoc2rXyurxRVNmbdHKwS7ceXIZSVx0+32GU
NZoJ4tND9KcN6J4/ifODUp0MDVVhOFDGSnuVG4gsN6ade9k3dzbcn0QYgIKcJKuN
pggw6ojxmbotAo7kie35FbGrWFF646C/lGBWYqtSoI5YPmWACW4czhQdX2Uv7Duq
tZHzETc3pRi/jCEbCSowe9OgYivfQgj/HZUydybDxcM1xH9KgKu8KH8OENu0Jfpj
NTwa1YrUS019l68PU5od3V6Wh0PHRXLU5R6hCTTJsIMBxWq2kgFaR3vCy/AtHbGL
BZR6FjuYMWtiUaNruh/7LSxMvgXwnJb0PYMMcg4fHl9ZoUI47AMocX+N4S1s21HD
nVyUT1SdRFZJJsipH+Z0DU+vTw3NarAxgNVH0P62LXPjXr0ZH/nEdow5EzTxHb/b
HS2R8y/4wYhqnNQSPpfHw8UFRW77RAk7MjPtrW0n86V/YqakUwNWMFehqLjOd9xk
pFRJpfzcJpuppl0nCkb1/vk0XZ8QqOFX6AMzCf5sPKVI+bup5IPq01L/fULKy6N1
sadye616PQAtFmsQzmmK
=lHDK
-----END PGP SIGNATURE-----