I have the honor of a response from Andrew! :)

On Tue, 2020-11-17 at 20:57 -0800, Andrew David Wong wrote:
> For me, the advantage of TemplateVMs over StandaloneVMs (even if there's 
> only one TemplateBasedVM based on the TemplateVM) is that it's easier to 
> update the TemplateVM and back up the TemplateBasedVM.

I assumed the update process was the same for a TemplateVM or a
StandaloneVM (though I've never tried the latter), and for backups, I
can select any set of VMs in the Qube Manager.  Perhaps you're pointing
out that if the system volume of the desired AppVM is easy enough to
recreate that it's not worth backing up, then using a TemplateVM +
TemplateBasedVM rather than a StandaloneVM makes it possible to skip
the backup?  Interesting point.  Though I suppose the more general
observation underlying my original proposal was that if the process to
generate the system volume from that of the main TemplateVM is
automated and reasonably fast, then there's the option to run it on
every boot of the TemplateBasedVM rather than persisting a separate
system volume at all.

> > my bigger
> > concern is the custom tools and configuration changes in my main
> > template that aren't currently packaged for dnf.  I could probably
> > package them and/or do without some of them in some proprietary-app
> > VMs, but I think that would end up being a bigger hassle than
> > developing and using my proposed tool.
> No need. Just make your changes in one template, then clone that 
> template as needed. That way, you only have to make the changes once.

The problem is when I change the main TemplateVM and want to apply the
change to all existing system volumes.  For example, recently I've
migrated some really useful configuration settings (e.g., enabling
undo-tree by default in Emacs and setting "merge.conflictstyle = diff3"
in Git) from the user volume of my "main" AppVM to my TemplateVM so I
would enjoy their benefits in all AppVMs.  If I had multiple
TemplateVMs, I would have to somehow copy those changes to all of them.
 If I changed a single file, maybe I could write a script that does a
bunch of qvm-copy commands.  But if I want to make sure things do not
get out of sync over time due to mistakes, it would help to have a
management tool of some kind.

However, on second thought, I realize that the only VM with a
proprietary app in which most of these customizations are valuable is
the one with Visual Studio Code, in which I do some of my software
development.  In the others, I pretty much run the proprietary app and
nothing else because I want to minimize the data exposed to the
proprietary app.  So as long as there are only two TemplateVMs in which
the customizations are needed, it may be manageable to copy them

> > Also, I'm low on disk space and
> > making many templates would make it worse, though maybe it's time that
> > I just bought a bigger disk.
> > 
> If you use minimal templates, even having a lot of them doesn't take up 
> much space.

Good point.  This would likely be appropriate for my VMs that run a
proprietary app and nothing else, although the video conferencing ones
will need at least pavucontrol, for example.  For the Visual Studio
Code VM, I'd need a lot more, but probably still a lot less than the
~13G of software in my main TemplateVM that is the union of everything
needed for all the projects in its TemplateBasedVMs.


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 view this discussion on the web visit 

Reply via email to