|About this Qubes/DisposableVM Page|
- 1 What are DisposableVMs?
- 2 Warnings
- 3 Setup
- 3.1 Create a Whonix ™ Default DVM Template based on Whonix-Workstation ™
- 3.2 Create a Named Whonix ™ DisposableVM based on Whonix-Workstation ™
- 3.3 Customization
- 3.4 Delete a DVM Template
- 3.5 Keep Tor Browser Up-to-date
- 3.6 Update a DVM Template
- 4 Usage
- 5 TODO
- 6 Footnotes
What are DisposableVMs?
In the Qubes TemplateVM model,  any changes made to a root filesystem of a TemplateBasedVM are lost upon reboot. This is advantageous for several reasons: it saves time and disk space, and allows faster, centralized updates for applications that are usually found inside the root filesystem. However, certain directories are designed to persist between reboots in order to store files and settings. These directories are stored in
/usr/local as well as additional directories defined by "bind directory" settings. 
Qubes does not have a built-in snapshot capability like VirtualBox that can completely revert all changes back to a previous VM state.   In other words, no method exists within AppVMs to reverse changes made to the persistent file system without implementing some type of custom solution. To ensure that all filesystem changes are discarded after a session, Qubes offers DispVMs. When a DispVM is shutdown, the VM is removed from Qubes and all related VM images are deleted from the host filesystem. This method is not yet amnesic and should not be relied upon for anti-forensics!
While DispVMs ensure that files do not persist without user intervention, the downside is the user can no longer decide whether or not the current VM state should be kept or destroyed; users must choose beforehand to use a standard AppVM or a DispVM.
Table: Qubes R4 Inheritance and Persistence
|Inheritance ||Persistence |
|DVM Template ||
The Layered DisposableVM System
Qubes uses a two-layered approach to DispVMs. At the core of the system is a TemplateVM upon which a DVM Template is based. Every time a new DispVM is launched it is based on the DVM Template - hence, two layers. In a standard Qubes-Whonix ™ installation:
- The Whonix-Workstation ™ default TemplateVM is
- The Whonix-Workstation ™ default DVM Template is called
- Each Whonix-Workstation ™ default DispVM (
disp1, disp2, ...) is based on
Once a DVM Template is created, its /home/user/ directory can be customized  independently of the TemplateVM. In this special case, the DVM Template will continue to inherit changes from the base TemplateVM's root filesystem (like package updates), but user files in /home/user/ will persist independently.
It is possible to have multiple DVM Templates and DispVMs at the same time. Any TemplateBasedVM can be enabled for use as a template for DispVMs, by setting its
DisposableVM Traffic Stream Isolation
Table: DispVM Warnings
|Ephemeral Whonix-Gateway ™ ProxyVMs||Using DispVMs for both the Whonix ™ Gateway and Workstation in Qubes R4 does not increase security without any corresponding privacy downside, for the following reasons:    |
|Named DisposableVMs: Manual Shutdown||Unlike DispVMs spawned from the Whonix ™ default DVM Template, named DispVMs do not automatically shutdown when the first user process is terminated. If a fresh Named DispVM is needed, users must first shutdown the named DispVM and start a new DispVM instance.  Failure to do so could lead to session data from previous activities persisting until the DispVM is properly shutdown.|
|Tor Browser in a DVM Template||Do not start Tor Browser in a DVM Template! For reasons why, see: Running Tor Browser in Qubes TemplateVM. Only start Tor Browser in TemplateBased AppVMs or DispVMs, see: Start Tor Browser in a DisposableVM.|
|Tor Browser Updater in a DVM Template||Do not start Tor Browser Updater in a DVM Template! For reasons why, see: tb-updater in Qubes DVM Template. Instead, run Tor Browser Downloader by Whonix ™ developers in Whonix-Workstation ™ TemplateVM (|
|Tor Browser Version||
|Verify DisposableVM Status||
|Whonix-Gateway ™ Linkability||The Tor Project developer Teor has stated that Tor caches  which may lead to linkage between AppVMs and DispVMs sharing the same Whonix-Gateway ™. The extent to which this is a threat for Whonix ™ users has now been documented; see Multiple Whonix-Workstation ™.|
Note: Examples below reference GUI steps whenever possible, but Qube Manager configuration options in R4 are limited in comparison to earlier releases.  Where relevant, additional command line commands are listed in the footnotes.
Create a Whonix ™ Default DVM Template based on Whonix-Workstation ™
- Update Qubes-Whonix ™.
- Open a dom0 terminal:
Qubes App Launcher (blue/grey "Q")→
Konsole or Xfce Terminal
sudo qubesctl state.sls qvm.whonix-ws-dvm
Qubes-Whonix ™ DispVMs are now ready for use.
Create a Named Whonix ™ DisposableVM based on Whonix-Workstation ™
Do not include
-dvm when naming DispVMs! Tor Browser will not be inherited from Whonix-Workstation ™ TemplateVM (
whonix-ws-15) if this advice is ignored.
Before creating named DisposableVMs, familiarize yourself with their behavior and read all relevant warnings. Failure to do so could lead to unwanted behavior which occurs without the user's knowledge.
TODO - Investigate use cases for this procedure:
- A named DisposableVM might be useful for a larger root/private image.
- It might also be useful for activities such as building TemplateVMs in a DispVM.
Extra caution must be exercised when customizing a DVM Template.  From a privacy perspective, it is ideal to have a DVM Template that is indistinguishable from any other Whonix-Workstation ™. If changes are made to the DVM Template, these may link all of the DispVMs via a uniquely generated fingerprint should they be compromised independently. Risky changes include, but are not limited to:
- Installation of obscure programs;
- Uncommon configuration settings; or
- The placement of unique data files.
Always keep in mind the DispVM will likely be exposed to the greatest Internet threats.
Tor Browser is specifically designed to prevent website fingerprinting or identification based on the user's browser fingerprint. It is safest to run Tor Browser in its stock configuration so the fingerprint is less unique, due to commonality with the larger Tor Browser user pool. Each individual browser change can significantly worsen the fingerprint because of the associated entropy,  so only make alterations if the impacts are known. See also: tb-updater in Qubes DVM Template.
Tor Browser in DVM Template
For most users, Tor Browser customizations in the DVM Template or TemplateVM are discouraged. Advanced users who wish to customize the DVM template despite the risks should follow these steps.
Applications other than Torbrowser in DVM Template
Delete a DVM Template
If a DVM Template has been customized and it is necessary to revert these changes, a DVM Template can be deleted the same way as any other VM.
Note the DVM Template cannot be deleted while it is the default DispVM of another VM, otherwise an error message appears. In that case, follow tips found here on how to manually change the default DispVM of VMs to another setting, then repeat the procedure.
Qube Manager →
right-click 'whonix-ws-15-dvm' →
left-click 'Delete qube'
Keep Tor Browser Up-to-date
To obtain the latest Tor Browser, the simplest method is to use Whonix ™ built-in Tor Browser downloader functionality. Simply update using Tor Browser Downloader by Whonix ™ (tb-updater) in Whonix-Workstation ™ TemplateVM (
whonix-ws-15) when performing your usual maintenance updating:
Update the package lists.
sudo apt-get update
sudo apt-get dist-upgrade
If Tor Browser is not upgraded, use update-torbrowser to download a new copy.
Launch Tor Browser Downloader by Whonix ™ and follow the instructions. 
update-torbrowser --input gui
Shutdown the DVM Template: 
Qube Manager →
right-click on 'whonix-ws-15-dvm' →
click 'Shutdown qube'
Update a DVM Template
Changes to the underlying TemplateVM (
whonix-ws-15) are detected automatically and the DVM Template is updated without user intervention. That means package updates that are applied to
whonix-ws-15 are also applied to the
DispVMs are well-suited for risky and largely independent activities, like web browsing or opening untrusted files. In contrast, AppVMs might be better suited for activities necessitating file persistence, like email clients with local email storage.
With either kind of VM, Qubes' VM integration tools like secure file copy and secure clipboard ensure that clean, trusted files and text can be easily and safely transferred to trusted VMs (if necessary).
Table: DispVM User Tips
|DispVM Shutdown||A DispVM automatically shuts down when the first user-launched process is terminated. For example, if a new DispVM is created by launching Tor Browser and a user simultaneously starts typing in an editor later on, all this work will be lost after Tor Browser is closed. To avoid this, first launch a terminal in the DispVM and then launch additional applications from the terminal. This way the DispVM is only destroyed after exiting the terminal.|
|Spawning DispVMs from other AppVMs||
Add a Desktop Shortcut
- From the Qubes application menu, drag and drop a menu item onto the desktop.
- Double-click the newly created launcher to start it.
- At first start, it is safe to click "Mark Executable".
Add an XFCE4 Panel Shortcut
From the Qubes application menu, drag and drop the menu item onto the panel.
Start Tor Browser in a DisposableVM
Tor Browser can be started via the GUI or on the command line.
After launch, always first check the Tor Browser version!
Start Terminal Emulator in a DisposableVM
konsole can be started via the GUI or on the command line.
- TODO document how to use multiple DVM Templates - https://forums.whonix.org/t/is-anyone-interested-in-using-multiple-dvm-templates-based-on-whonix-ws-dvm/5757/5
- DispVMs have significant improvements; see https://github.com/QubesOS/qubes-issues/issues/866#issuecomment-220495485
- A serious privacy bug is unresolved in Qubes R3.2 / R3.2.1 and below.
- AppVMs (qubes) and TemplateVMs.
- How to make any file in a TemplateBasedVM persistent using bind-dirs.
- Apart from qvm-revert-template-changes which can only revert to the state existing before the last shutdown of the TemplateVM.
- Qubes VM snapshots using git / SVN.
- Upon creation.
- Following shutdown.
- Because each VM is assigned a unique, internal IP address.
- Whonix ™ is not amnesic.
- Is there a substitute for Whonix ™ lack of an Amnesic feature?
- DisposableVMs do not run entirely in RAM.
- DisposableVMs: support for in-RAM execution only (for anti-forensics) #904
- 4.0rc1 dirty shutdown causes dispVMs to remain persistent #3037
- DisposableVMs are not Amnesic.
- Tor Entry Guards.
- This is another reminder of why full disk encryption should always be used on the host.
- The reason is there are both malicious and benign guards in the Tor network. The more often the user "rolls the dice" (changes guards), the greater the chance of striking out.
- The solution to the first problem is only allowing in-RAM execution of DisposableVMs, but this is not planned for implementation in the short-term. There is no perfect solution to the second problem. That said, there is an actual unstated security-privacy trade-off by running this configuration. Theoretically, an ephemeral Whonix-Gateway ™ ProxyVM is only able to be infected for a single session (via the /home, /usr/local and /rw directories), since it is discarded upon shutdown. This provides a counterbalance to the increased threat of malicious guards, as Whonix ™ becomes more "Tails-like".
- See DispVM Shutdown for more on this.
- This is because named DispVMs are created using a similar method to that which is used to create TemplateBasedAppVMs. This means that named DispVMs -- in some respects -- exhibit behavior similar to that of a TemplateBasedAppVM. For example, behavior such as persistent VM settings across restarts; this includes, but is not limited to settings like --netvm, --autostart and --label to name a few. Before starting a new named DispVM instance, first verify in Qube Manager that the VM is fully shutdown.
- DispVMs are created in one of two ways:
Open in DisposableVM. On the command line (domU), run.
Edit/View in DisposableVM. From the GUI context-menu (domU).
Edit/View in DisposableVM
- On the command line (dom0), run.
qvm-prefs -s vmname dispvm_netvm sys-whonix
- After creation of a new DVM Template, all VMs spawned from the DVM Template should be DispVMs by design. This includes the first start and all subsequent starts thereafter. While this is expected behavior, it is safest to confirm the DispVM was correctly spawned on each occasion it is used.
- For instance, DispVM networking can no longer be set from Qube Manager.
- Qubes documentation: DisposableVM Customization.
- 33 bits of entropy will identify one individual out of several billion.
- Or on the command line (dom0), run.
right-click on 'whonix-ws-15'→
click 'Run command in qube'→
On the command line (dom0), run.
qvm-run -a whonix-ws-15 konsole
On the command line (dom0), run.
DVM Template command line (domU), run.
- Github: Split Browser
- On the command line (dom0), run.
qvm-prefs disp<1 | 2 | ...> netvm none
- See: Qubes DispVMs
- See Micahflee's blog on How Qubes makes handling pdfs way safer.
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.
Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)