Last update: March 17, 2019. This website uses cookies. By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. More information


Qubes DisposableVMs

< Qubes
About this Qubes/DisposableVM Page
Support Status stable
Difficulty easy
Maintainer 0brand
Support Support

What are DisposableVMs?[edit]

In the Qubes TemplateVM model, [3] 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 /rw/ and include /home/user as well as additional directories defined by "bind directory" settings. [4]

Qubes does not have a built-in snapshot capability like VirtualBox that can completely revert all changes back to a previous VM state. [5] [6] 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 [7] Persistence [8]
TemplateVM n/a Everything
TemplateBasedVM /etc/skel/ to /home/ /rw/ (includes /home/ and bind-dirs)
DVM Template [9] /etc/skel/ to /home/ /rw/ (includes /home/ and bind-dirs)
DisposableVM /rw/ (includes /home/ and bind-dirs) Nothing

The Layered DisposableVM System[edit]

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 whonix-ws-14.
  • The Whonix-Workstation default DVM Template is called whonix-ws-14-dvm.
  • Each Whonix-Workstation default DispVM (disp1, disp2, ...) is based on whonix-ws-14-dvm.

Once a DVM Template is created, its /home/user/ directory can be customized [10] 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 template_for_dispvms property.

In Qubes R4, Qubes-Whonix 14's default DVM Template (whonix-ws-14-dvm) can be easily created using salt and will have this property set.

DisposableVM Traffic is Stream Isolated from Other VMs[edit]

DispVMs work especially well with Whonix-Gateway. [11] All DispVM traffic is stream-isolated from the traffic of other VMs running in parallel.


Avoid Ephemeral Whonix-Gateway ProxyVMs[edit]

Some Whonix users have the mistaken belief that DispVMs for both the Whonix Gateway and Workstation in Qubes R4 is the ultimate configuration: increasing their security, without any corresponding privacy downside. This reasoning is incorrect for the following reasons: [12] [13] [14]

  • DispVMs are not amnesic. In practice this means traces of their activity can be left on storage or in memory, making them vulnerable to forensic operations. [15]
  • Using a DispVM for the Whonix-Gateway results in non-persistent entry guards to the Tor network; behavior unlike the default configurations for Whonix, Tor, and the Tor Browser Bundle. Mathematically speaking, end-to-end correlation attacks are more likely to succeed when a user chooses many random entry and exit points in the Tor network, rather than semi-permanent entry guards which are only rotated every few months. [16] [17]

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".

Check the Tor Browser Version[edit]

To learn about recent Tor Browser versions, follow The Tor Project blog or look at raw data for the latest Recommended TBB Versions. Tor Browser's version number can also be checked manually: Tor Browser -> Menu -> Help -> About Tor Browser. See Keep Tor Browser Up-to-date.

DisposableVMs are not Amnesic[edit]

This is further justification for using full disk encryption on the Qubes host and completely shutting down the system when it is not in use. Laptop users may wish to remove batteries to ensure that power to the RAM is definitely disconnected. [18] [19] [20] [21] [22]

DisposableVMs may be Linkable to other VMs Connected to the Same Whonix-Gateway[edit]

The Tor Project developer Teor has stated that Tor caches DNS, HS descriptors, pre-emptive circuits, etc. [23] which may lead to linkage between AppVMs and DispVMs sharing the same gateway. The extent to which this is a threat for Whonix users is still being investigated. [24]

Do not Start Tor Browser in a DVM Template[edit]

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.

Do not Start Tor Browser Updater in a DVM Template[edit]

For reasons why, see: tb-updater in Qubes DVM Template.

Instead, run Tor Browser Downloader by Whonix developers in Whonix-Workstation TemplateVM (whonix-ws-14).

Use Caution when Spawning DisposableVMs from Other VMs[edit]

The reason is because DispVMs inherit their NetVMs from the calling VM, or the calling VM's dispvm_netvm setting (if different). The dispvm_netvm setting can be configured per VM via:

dom0 -> Qube Manager -> VM Settings -> Advanced -> NetVM for DisposableVM [26]

If the calling VM is connected to Whonix-Gateway, this step is not necessary and the DispVM's traffic will be routed over Tor. See: Whonix default NetVM settings fixes.

Verify DisposableVM Status upon Launch[edit]

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. There could be serious consequences if an application like Tor Browser was started in a DVM Template and used extensively for web browsing. Compromise of the DVM Template would mean all DispVMs spawned from it would be similarly compromised; see Running Tor Browser in Qubes TemplateVM.

To check the freshly started VM is a DispVM, verify it is named [disp xxxx] where xxxx is the number assigned to that DispVM. If the DVM Template was started instead, then it should be shut down immediately. If the DVM Template is ever inadvertently used for a dangerous activity like web browsing, then delete it and create a new one.

Manual Shutdown of Named DisposableVMs Required[edit]

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.[29] Before starting a new named DispVM instance, first verify in Qube Manager that the VM is fully shutdown. Failure to do this could lead to session data from previous activities persisting until the DispVM is properly shutdown.


Note: Examples below reference GUI steps whenever possible, but Qube Manager configuration options in R4 are limited in comparison to earlier releases. [30] Where relevant, additional command line commands are listed in the footnotes.

Creating Whonix Default DVM Template Based on Whonix-Workstation[edit]

1. Update Qubes-Whonix.

2. Open a dom0 terminal.

Qubes App Launcher (blue/grey "Q") -> System Tools -> Konsole or Xfce Terminal

3. Create whonix-ws-14-dvm DVM Template.

sudo qubesctl state.sls qvm.whonix-ws-dvm

Qubes-Whonix DispVMs are now ready for use.

Creating a Named Whonix DisposableVM Based on Whonix-Workstation[edit]

Do not include -dvm when naming DispVMs! Tor Browser will not be inherited from Whonix-Workstation TemplateVM (whonix-ws-14) if this advice is ignored.

Before creating named DisposableVMs, users should become familiar with their behavior and read all relevant warnings. Failure to do this could lead to unwanted behavior occurring without the users knowledge.

To create a DispVM called anon-whonix-disp based on the whonix-ws-14-dvm Template, in dom0 run.

qvm-create -C DispVM -l red --template whonix-ws-14-dvm anon-whonix-disp

Launch Konsole in the DispVM.

qvm-run -a anon-whonix-disp konsole

TODO: Investigate use cases for this procedure.

Maybe a named DisposableVM would be useful to have a larger root image or larger private image? Could be useful for activities such as building TemplateVMs in a DispVM?

Deleting a DVM Template[edit]

If a DVM Template has been customized and the user wishes 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.

dom0 -> Qube Manager -> right-click 'whonix-ws-14-dvm' -> left-click 'Remove VM' [31]

Customizing DVM Templates[edit]

Extra caution must be exercised when customizing a DVM Template. [32] 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, [33] so only make alterations if the impacts are known. See also: tb-updater in Qubes DVM Template.

A decision must be made in advance whether to disable JavaScript by default. There is a usability-security trade-off to consider: fingerprinting and usability is worsened by disabled JavaScript, but this provides better protection against vulnerabilities. Conversely, enabled JavaScript improves usability and increases the risk of exploitation, but the browser fingerprint is (likely) more common.

Customizing Tor Browser in DVM Template[edit]

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.

Customizing Applications other than Torbrowser in DVM Template[edit]

1. Launch the application in the DVM template.

Either open dom0 terminal and run.

qvm-run -a whonix-ws-14-dvm <app>

Or use Qube Manager:

dom0 -> Qube Manager -> right-click 'whonix-ws-14-dvm' -> Run command in qube -> type name of the <app>

2. Customize application settings.

Customize the application as per normal procedures.

3. Exit the application.

If required, save application-specific settings, then exit the application so settings are stored on the disk.

4. Shutdown the DVM template.

Either use a dom0 terminal.

qvm-shutdown whonix-ws-14-dvm

Or use Qube Manager:

dom0 -> Qube Manager -> right-click 'whonix-ws-14-dvm' -> left-click 'Shutdown VM'

The changes will be available when the DispVM is restarted.

Keep Tor Browser Up-to-date[edit]

To obtain the latest Tor Browser, the simplest method is to use Whonix's built-in Tor Browser downloader functionality. Simply update using Tor Browser Downloader by Whonix (tb-updater) in Whonix-Workstation TemplateVM (whonix-ws-14) when performing your usual maintenance upgrading:

Qubes App Launcher (blue/grey "Q") -> whonix-ws-14 -> Konsole [34] [35]

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. [36]

update-torbrowser --input gui

Shutdown the DVM Template: [37]

dom0 -> Qube Manager -> right-click on 'whonix-ws-14-dvm' -> click 'Shutdown VM'

Updating a DVM Template[edit]

Changes to the underlying TemplateVM (whonix-ws-14) are detected automatically and the DVM Template is updated without user intervention. That means package updates that are applied to whonix-ws-14 are also applied to the whonix-ws-14-dvm.


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).

User Tips[edit]

Data Storage[edit]

In Qubes, it is unrecommended to store any valuable data in an untrusted VM. This perspective is reinforced by the Tor Browser design which similarly does not remember bookmarks or credentials. Best practice is to store sensitive data in an offline vault VM; for instance, when accessing passwords with a password manager.

@rustybird has announced a new "split-tor-browser" [38] package that can retrieve urls and credentials from a trusted VM for use in a DispVM's browser. This package is yet to be tested or endorsed by Whonix, but it looks promising.

DispVM Shutdown[edit]

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.

Offline DispVMs[edit]

Non-networked DispVMs are useful for opening untrusted files that potentially might try to use the network maliciously. Like all Qubes VMs, the NetVM for a DispVM can be changed dynamically while the VM is still running. Simply set the NetVM to "none" using Qube Manager or the command line interface. [39]

Spawning DispVMs from other AppVMs[edit]

There are several ways to spawn DispVMs from TemplateBased AppVMs. In fact, in addition to the dom0 terminal and application menu, users can also spawn DispVMs from the AppVM konsole or context-menu. [40] These tools provide a safe and convenient way to open files and email attachments that could contain malicious code. There is also an option to convert potentially dangerous PDFs into trusted PDFs and open it in a DispVM. [41]

The most commonly used methods to spawn DispVMs from TemplateBased AppVMs are listed below. It is recommended to read the warning detailing DispVM network settings before proceeding.

  1. Context-menu
  2. Dolphin file manager - open file in DispVM: File -> Actions -> Edit/View in DisposableVM
  3. Nautilus file manager - open file in DispVM: File -> Edit/View in DisposableVM
  4. Nautilus file manager- sanitize PDF: PDF -> Convert to Trusted PDF
  5. Thunderbird E-mail client - open email attachment in DispVM: Email -> Attachments -> Open in DispVM
  6. Command line interface - open file in DispVM:
    qvm-open-in-dvm <file_name>


  • DispVMs can be created directly by launching programs from the application menu using shortcuts; see below for instructions.
  • DispVMs can also be spawned by using context-menus or the command line interface in other AppVMs. Refer to the Qubes DisposableVM documentation for instructions on different methods.
  • Note the relevant warning concerning shortcuts in this chapter.

Adding a Desktop Shortcut[edit]

  1. From the Qubes application menu, drag and drop a menu item onto the desktop.
  2. Double-click the newly created launcher to start it.
  3. At first start, it is safe to click "Mark Executable".

Adding an XFCE4 Panel Shortcut[edit]

From the Qubes application menu, drag and drop the menu item onto the panel.

Start Tor Browser in a DisposableVM[edit]

Tor Browser can be started via the GUI or on the command line.

If you are using a GUI, complete the following steps.

Qubes App Launcher (blue/grey "Q") -> Disposable: whonix-ws-14-dvm -> Tor Browser (AnonDist)

If you are using a terminal, complete the following steps.

qvm-run --dispvm=whonix-ws-14-dvm torbrowser

After launch, always first check the Tor Browser version!

Start Terminal Emulator in a DisposableVM[edit]

Terminal emulator konsole can be started via the GUI or on the command line.

If you are using a GUI, complete the following steps.

Qubes App Launcher (blue/grey "Q") -> Disposable: whonix-ws-14-dvm -> Konsole

If you are using a terminal, complete the following steps.

qvm-run --dispvm=whonix-ws-14-dvm konsole



  1. DispVMs have significant improvements; see
  2. A serious privacy bug is unresolved in Qubes R3.2 / R3.2.1 and below.
  3. AppVMs (qubes) and TemplateVMs.
  4. How to make any file in a TemplateBasedVM persistent using bind-dirs.
  5. Apart from qvm-revert-template-changes which can only revert to the state existing before the last shutdown of the TemplateVM.
  6. Qubes VM snapshots using git / SVN.
  7. Upon creation.
  8. Following shutdown.
  11. Because each VM is assigned a unique, internal IP address.
  12. DisposableVMs are not Amnesic.
  14. Tor Entry Guards.
  15. This is another reminder of why full disk encryption should always be used on the host.
  17. 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.
  18. Whonix is not amnesic.
  19. Is there a substitute for Whonix's lack of an Amnesic feature?
  20. DisposableVMs do not run entirely in RAM.
  21. DisposableVMs: support for in-RAM execution only (for anti-forensics) #904
  22. 4.0rc1 dirty shutdown causes dispVMs to remain persistent #3037
  24. Multi GW Documentation.
  25. 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).

    File -> Actions -> Edit/View in DisposableVM
  26. On the command line (dom0), run.
    qvm-prefs -s vmname dispvm_netvm sys-whonix
  28. See; DispVM Shutdown for more on this.
  29. Behavior such as persistent VM settings across restarts. This includes, but is not limited to setttins such as --netvm, --autostart and --label to name a few.
  30. For instance, DispVM networking can no longer be set from Qube Manager.
  31. Or on the command line (dom0), run.
    qvm-remove <vmname>
  32. Qubes documentation: DisposableVM Customization.
  33. 33 bits of entropy will identify one individual out of several billion.
  34. dom0 -> Qube Manager -> right-click on 'whonix-ws-14' -> click 'Run command in VM' -> type 'konsole'
  35. On the command line (dom0), run.
    qvm-run -a whonix-ws-14 konsole
  36. update-torbrowser
  37. On the command line (dom0), run.
    qvm-shutdown whonix-ws-14-dvm
    DVM Template command line (domU), run.
    sudo poweroff
  38. Github: Split Browser
  39. On the command line (dom0), run.
    qvm-prefs disp<1 | 2 | ...> netvm none
  40. See: Qubes DispVMs
  41. See Micahflee's blog on How Qubes makes handling pdfs way safer.

No user support in comments. See Support.

Comments will be deleted after some time. Specifically after comments have been addressed in form of wiki enhancements. See Wiki Comments Policy.

Add your comment
Whonix welcomes all comments. If you do not want to be anonymous, register or log in. It is free.

Random News:

We are looking for video production specialists to help create demonstration, promotional and conceptual videos or tutorials.

https | (forcing) onion

Share: Twitter | Facebook

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?)

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix is provided by ENCRYPTED SUPPORT LP. See Imprint.