Make a GUI tool to change template for several VMs at once

[marmarta]

Qubes OS version:

R4.0

Affected component(s):

Qube Manager?

General notes:

Introduce some kind of GUI tool - probably in Qube Manager, although there were ideas thrown around to make a Template Manager - to easily change template of several VMs at once; it would be especially usefully when the user installs e.g. newer fedora or other debian and wants to quickly migrate everything to the new template.

[Aekez]

Make a GUI tool to change template for several VMs at once

This is a very nice idea, imho, at least I for one would look forward to such a feature if implemented.

This got me thinking; as having a lot of DVM's, especially many DispVM's (if wanting fixed DVM-names), is really tiresome to create, manage, and change too.

Consider to include a similar feature in tool for DVM's.

• Changing DVM Templates, for the DVM AppVM's (disp####) and the DispVM's (fixed disp-names).
  • Something similar here to the the current issue suggestion, but working out a solution for the DVM's too.

Consider re-use of existing Qubes code - Edit: see picture posted below for quick example.
Maybe the same window-GUI code used for qvm-backup and qvm-backup-restore, as well as the GUI code used for qvm-prefs GUI to change AppVM devices or applications, can also be used to change templates.

• Example: Open tool, select a source-template and a target-template to change all AppVM's and DispVM's based on this template, and then move over all or only partial/some AppVM's (like described GUI above) which should be changed from source-template to target-template, and then clicking "accept" to make it go into effect, or something of the sorts.
• I'm sure there are many other ways to do it, this is just one idea, leaving it here for considering.

Consider allowing AppVM and DispVM's to exist temporarily without templates.

• For example if the user ran out of disk-space, and needs to delete old template to gain enough disp-space for the new TemplateVM.
• For example allows users to restore AppVM's from Qubes backup, without being forced to prepare the right templates before using backup restore, or temporarily use different templates (which might make the user feel un-easy, or feel its an unclean solution).
• For example if the user needs to obtain new clean version of the original template RPM. All the clones can just be deleted with qvm-remove, but the original template rpm needs to be removed with dnf/yum. This puts the user in a dilemma, they need to either temporarily create a new extra clone, in order to uninstall the original rpm template (only to install the same again afterwards), and it doesn't feel quite "clean" to move to a different template type or version either. Ultimately it may feel more clean to just allow the user to pick a "none" template option for the AppVM's TemplateVM, though probably with a warning too?
• As my memory serve from time to time there are people in Qubes-users mailing-lists who has a lot of problems finding the AppVM's (especially the DispVM's) tied to Templates and DVM-Templates. So it might be ideal to allow temporary no templateVM for DispVM's and AppVM's, as to not stop the user in their track, having to troubleshoot why they can't remove the template, or even resorting to ask other people online for help, maybe giving up, or even open GitHub issues, when it could be avoided by allowing the user to put AppVM's template to "none", at least temporary.
• The thinking here goes, instead of outright "blocking" the user if the template has any attached AppVM's, then instead rather "work with the user" and allow AppVM's to exist without templates, and the moment an AppVM is started without a template, the system could for example ask for the right template to use in a popup with a template drop-down menu (with a flag reminder of the original template used).

Consider putting an original TemplateVM flag.

• Essentially a place, whether in qvm-prefs, or in the qvm-prefs GUI window, to show which Template was the original template for the specified AppVM (i.e. whether it was debian, fedora, whonix, centos, etc.).
  • This one in particular would be relevant if allowing the above temporary no template attachment to AppVM's and DispVM's.

Above is only loose thoughts, I realize there are multiple ways to go about these issues, and probably many problems I haven't considered either, so anything above is merely speculative thoughts before it becomes a suggestion.

[Aekez]

Make a GUI tool to change template for several VMs at once

This is a very nice idea, imho, at least I for one would look forward to such a feature if implemented.

This got me thinking; as having a lot of DVM's, especially many DispVM's (if wanting fixed DVM-names), is really tiresome to create, manage, and change too.

Consider to include a similar feature in tool for DVM's.

• Changing DVM Templates, for the DVM AppVM's (disp####) and the DispVM's (fixed disp-names).
  • Something similar here to the the current issue suggestion, but working out a solution for the DVM's too.

Consider re-use of existing Qubes code - Edit: see picture posted below for quick example.
Maybe the same window-GUI code used for qvm-backup and qvm-backup-restore, as well as the GUI code used for qvm-prefs GUI to change AppVM devices or applications, can also be used to change templates.

• Example: Open tool, select a source-template and a target-template to change all AppVM's and DispVM's based on this template, and then move over all or only partial/some AppVM's (like described GUI above) which should be changed from source-template to target-template, and then clicking "accept" to make it go into effect, or something of the sorts.
• I'm sure there are many other ways to do it, this is just one idea, leaving it here for considering.

Consider allowing AppVM and DispVM's to exist temporarily without templates.

• For example if the user ran out of disk-space, and needs to delete old template to gain enough disp-space for the new TemplateVM.
• For example allows users to restore AppVM's from Qubes backup, without being forced to prepare the right templates before using backup restore, or temporarily use different templates (which might make the user feel un-easy, or feel its an unclean solution).
• For example if the user needs to obtain new clean version of the original template RPM. All the clones can just be deleted with qvm-remove, but the original template rpm needs to be removed with dnf/yum. This puts the user in a dilemma, they need to either temporarily create a new extra clone, in order to uninstall the original rpm template (only to install the same again afterwards), and it doesn't feel quite "clean" to move to a different template type or version either. Ultimately it may feel more clean to just allow the user to pick a "none" template option for the AppVM's TemplateVM, though probably with a warning too?
• As my memory serve from time to time there are people in Qubes-users mailing-lists who has a lot of problems finding the AppVM's (especially the DispVM's) tied to Templates and DVM-Templates. So it might be ideal to allow temporary no templateVM for DispVM's and AppVM's, as to not stop the user in their track, having to troubleshoot why they can't remove the template, or even resorting to ask other people online for help, maybe giving up, or even open GitHub issues, when it could be avoided by allowing the user to put AppVM's template to "none", at least temporary.
• The thinking here goes, instead of outright "blocking" the user if the template has any attached AppVM's, then instead rather "work with the user" and allow AppVM's to exist without templates, and the moment an AppVM is started without a template, the system could for example ask for the right template to use in a popup with a template drop-down menu (with a flag reminder of the original template used).

Consider putting an original TemplateVM flag.

• Essentially a place, whether in qvm-prefs, or in the qvm-prefs GUI window, to show which Template was the original template for the specified AppVM (i.e. whether it was debian, fedora, whonix, centos, etc.).
  • This one in particular would be relevant if allowing the above temporary no template attachment to AppVM's and DispVM's.

Above is only loose thoughts, I realize there are multiple ways to go about these issues, and probably many problems I haven't considered either, so anything above is merely speculative thoughts before it becomes a suggestion.

[Aekez]

I tried to draw the above suggestion as a picture, it would sort of look like this on a selected template-source on a clean new Qubes install;

• The double red-lines are to ignore the underlining content, assuming this tool would need to be a window of its own.

• Maybe consider a warning if a user tries to move templates from different types, instead just version of the same type? For example if moving AppVM's from Whonix-ws to fedora-28, or from fedora-28 to Whonix-ws, and in case this may or may not be encouraged?
  • An alternative could maybe be to use code to only show the target templateVM's which are a good idea to move between, i.e. if picking fedora-26 as source-templateVM, then only target templateVM's available on target templateVM's will be the current installed fedora rpm's, like fedora-27, fedora-28, fedora-27-mimimal, cloned fedora templates, etc.
    • This also helps the user to figure out "whats deemed safe and reliable" and "whats not deemed safe and reliable", by building this safety-logic directly into the tool.

[Aekez]

I tried to draw the above suggestion as a picture, it would sort of look like this on a selected template-source on a clean new Qubes install;

• The double red-lines are to ignore the underlining content, assuming this tool would need to be a window of its own.

• Maybe consider a warning if a user tries to move templates from different types, instead just version of the same type? For example if moving AppVM's from Whonix-ws to fedora-28, or from fedora-28 to Whonix-ws, and in case this may or may not be encouraged?
  • An alternative could maybe be to use code to only show the target templateVM's which are a good idea to move between, i.e. if picking fedora-26 as source-templateVM, then only target templateVM's available on target templateVM's will be the current installed fedora rpm's, like fedora-27, fedora-28, fedora-27-mimimal, cloned fedora templates, etc.
    • This also helps the user to figure out "whats deemed safe and reliable" and "whats not deemed safe and reliable", by building this safety-logic directly into the tool.

[Aekez]

Introduce some kind of GUI tool - probably in Qube Manager, although there were ideas thrown around to make a Template Manager

A link to this independent window-tool, like above, could maybe then be linked from the Qube Manager?

• This way it can become both a Qube Manager tool, and align with the Qubes 4 widget-tool approach at the same time.
• A bit similar to how Qubes Create VM's, Create Backup, etc. are detached window GUI's, but are linked from the Qube Manager.
• This also future-proofs work here if an improved widget will include all the Qubes-tools in the future.

[Aekez]

Introduce some kind of GUI tool - probably in Qube Manager, although there were ideas thrown around to make a Template Manager

A link to this independent window-tool, like above, could maybe then be linked from the Qube Manager?

• This way it can become both a Qube Manager tool, and align with the Qubes 4 widget-tool approach at the same time.
• A bit similar to how Qubes Create VM's, Create Backup, etc. are detached window GUI's, but are linked from the Qube Manager.
• This also future-proofs work here if an improved widget will include all the Qubes-tools in the future.