I have searched on google and read this site glossary but I still have doubts.
Qube Manager
DispVM and AppVM both delete every changes done inside after shutting it down?
And TemplateVM?
Also a qube named fedora-32-dvm: dvm what does mean?
I would know in which case I should chose one instead of another with practical newbie examples.
No, only disposables. App qubes only reset their root filesystems, which they read from their respective templates on each boot.
Totally persistent.
Old terminology referring to a disposable template.
@Ringo9 The key concepts to understand are āinheritanceā and āpersistenceā. AppVMs inherit the root file system of their template on every reboot, but the home directory persists (i.e. changes you make within /home/* will persist across reboots.)
A dispVM is based on a special type of appVM known has a ādisposable VM templateā. The disposable VM inherits everything upon each rebootā¦ the root file system from the main template and the home directory from the disposable VM template. As such, a given disposable VM is āfully volatileā, meaning that all changes made during a session are lost.
ādvmā stands for ādisposable virtual machineā. The abbreviation is most often used when naming certain VMs to designate them as a disposable VM template. However, disposable VM templates can be named anything. ādvmā is only used for clarity.
Noteā¦ if you start a disposable VM template from the application menu, a randomly named disposable VM will launch (ex. disp-1234). However, you can also create a ānamed disposableā by creating a new āfully volatileā qube based on the respective disposable VM template. That allows you to give the disposable VM a consistent name which can be useful for configuring networks and otherwise referencing the VM in other configurations. In this case, only the name of the VM persists. The file system is still fully volatile.
Is it possible to apply changes of the command āsudo apt upgradeā on each debian vm to upgrade all of them once?
I canāt apply this to every of my machine it require lot of time.
This is why Qubes uses the template mechanism - by updating a template
and restarting the qubes that use it you update all of them at once.
Of course, you may have many templates.
In that case you can cut the update time by using a caching proxy
instead of the standard Update proxy.
This has been discussed in the Forum before - a caching proxy will store
the updates, so that the next request from another template does not
pull the package from the internet, but from the proxy.
You can read about one options here
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Have a look at this page:
And this one: