Hi,
Considering templates are aimed only for storing the OS, i.e. not user data, why do they have a private volume at all? And why is it persistent?
1 Like
Here is the closest issue I could find on github about Templates having a separate private volume:
I donāt think thereās a concise answer to why this is a thing and what the benefits are, other than maybe hiding files from inherited app qubes.
Thanks. I searched a lot too but found nothing useful.
I donāt understand how it hides anything by being persistent, as xvdb is not inherited anyway, i.e. it can simply be another volatile volume. Or, if it is persistent, perhaps it might be more suitable to place /root in it.
I guess I have asked another difficult question.
You have made an incorrect assumption. Templates are not only aimed at storing the OS. They also provide a skeleton file system for user data, including home user defaults and the like.
On the other hand, a template does have /home/user. It is persistentā¦from one run of the template to the next.
/home/user as seen on the template wonāt be what /home/user is on the AppVM (either āregularā or template-for-dvm), so itās not persistent in that way.
So you can put things in the template /home/user and by doing so, hide them from the user of the AppVM (or disposable). Iāve created many of my own packages, and I put them in /home/user/repository on the template (and set it up as a repository). I can check later to ensure they all got copied there by starting the template; the AppVM canāt see them at all.
Because that how Qubes is designed, architecturally speaking.
Template, or a skeleton as @Rudd-O said, is used as template for the rest.
That being said, it would be nice to verify this with someone who know how this work under the hood.
You have made an incorrect assumption. Templates are not only aimed at storing the OS.
It may be imperfect wording on my side. The essence is obviously that templates are not supposed to store user data
They also provide a skeleton file system for user data, including home user defaults and the like.
In case you mean /etc/skel - that is still in root.img.
not persistent in that way.
By persistent I mean non-volatile, not hidden. If the goal is to hide something, one can do it in an AppVM.
So you can put things in the template /home/user and by doing so, hide them from the user of the AppVM (or disposable).
I understand you use it that way because it is available. But is this really the purpose it is meant to serve?
1 Like
Because that how Qubes is designed, architecturally speaking.
I know it is so. The question is why 
These kind of things are usually based on personal preferences, limited knowledge and general abilities.
Itās maybe not so much that a TemplateVM needs to have a normal āprivateā volume, but rather that it doesnāt need to not have it. 
Setting up a new kind of non-snap_on_start non-save_on_stop āprivateā volume (similar to the āvolatileā volume), or not having a āprivateā volume at all - either way it would be an additional thing to implement and probably make the codebase (dom0, and especially the in-VM init logic) more complex.
3 Likes
Your response was a bit confusing to readā¦in part because it looks on the surface like youāre quoting me, but some of the quotes are actually someone else.
My response was in large part meant to educate anyone else who might be reading the thread.
Iām quite sure youāre right and what I use the templateVM /home/user isnāt what it was meant for. I just wanted to use what I do use it for as an example to explain the behavior.
No, I donāt know why it was done this way, and honestly I donāt see that it matters why itās there, or for that matter, whether it is there or not. Because as stated the user canāt see it anyway when running an AppVM.
Setting up a new kind of non-
snap_on_startnon-save_on_stopāprivateā volume (similar to the āvolatileā volume), or not having a āprivateā volume at all - either way it would be an additional thing to implement and probably make the codebase (dom0, and especially the in-VM init logic) more complex.
How about making it tmpfs? Then no volume would be required at all - simpler code, less volumes.
BTW, @rustybird I would very much like to have your thoughts in this thread:
Your response was a bit confusing to readā¦in part because it looks on the surface like youāre quoting me, but some of the quotes are actually someone else.
Sorry about the confusion.
I use the forum by email. I replied to the latest post (yours), quoting also part of the post you replied to, in order to avoid 2 separate replies. I am not sure if the latter would have been better.
If a special case (a TemplateVM) is to be treated differently from the general case (a VM of any type), that inherently increases the complexity of the system as a whole. I wouldnāt do it unless the general case is intolerable.
A TemplateVM having a normal āprivateā volume seems totally fine to me: Itās just a place thatās available if you ever want to have some stuff in the TemplateVM but not in AppVMs based on it or StandaloneVMs derived from it. If you leave that place empty, its storage overhead is < 100 MB per independent TemplateVM (less for clones) and it takes a fraction of a second to mount on TemplateVM startup. 
1 Like
I think that clarifies it.
Thanks!
Yah that is exactly the incorrect assumption. Templates can and do store user data.