diff --git a/introduction/faq.md b/introduction/faq.md index 97850571..6b56ceb2 100644 --- a/introduction/faq.md +++ b/introduction/faq.md @@ -78,7 +78,7 @@ For more information about how to use this powerful tool correctly and safely, p ### What about privacy in non-Whonix qubes? Qubes OS does not claim to provide special privacy (as opposed to security) properties in non-[Whonix](/doc/whonix/) qubes. -This includes [DisposableVMs](/doc/disposablevm/). +This includes [disposables](/doc/how-to-use-disposables/). For example, a standard [Fedora](/doc/templates/fedora/) qube is expected to have basically the same privacy properties as that upstream Fedora distribution, enhanced to some degree by the control Qubes provides over that qube. For most users, this level of privacy may be good enough for many common activities. @@ -88,7 +88,7 @@ Privacy is far more difficult than is commonly understood. In addition to the [web browser](https://www.torproject.org/projects/torbrowser/design/), there is also [VM fingerprinting](https://www.whonix.org/wiki/VM_Fingerprinting) and [advanced deanonymization attacks](https://www.whonix.org/wiki/Advanced_Deanonymization_Attacks) that most users have never considered (and this is just to mention a few examples). The [Whonix Project](https://www.whonix.org/) specializes in [protecting against these risks](https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection). -In order to achieve the same results in non-Whonix qubes (including DisposableVMs), one would have to reinvent Whonix. +In order to achieve the same results in non-Whonix qubes (including disposables), one would have to reinvent Whonix. Such duplication of effort makes no sense when Whonix already exists and is already integrated into Qubes OS. Therefore, when you need privacy, you should use Whonix qubes. @@ -325,7 +325,7 @@ Those won’t fly. We do not provide GPU virtualization for Qubes. This is mostly a security decision, as implementing such a feature would most likely introduce a great deal of complexity into the GUI virtualization infrastructure. However, Qubes does allow for the use of accelerated graphics (e.g. OpenGL) in dom0’s Window Manager, so all the fancy desktop effects should still work. -AppVMs use a software-only (CPU-based) implementation of OpenGL, which may be good enough for basic games and applications. +App qubes use a software-only (CPU-based) implementation of OpenGL, which may be good enough for basic games and applications. For further discussion about the potential for GPU passthrough on Xen/Qubes, please see the following threads: @@ -357,9 +357,9 @@ See [Certified Hardware](/doc/certified-hardware/). ### How much disk space does each qube require? -Each qube is created from a TemplateVM and shares the root filesystem with this TemplateVM (in a read-only manner). +Each qube is created from a template and shares the root filesystem with this template (in a read-only manner). This means that each qube needs only as much disk space as is necessary to store its own private data. -This also means that it is possible to update the software for several qubes simultaneously by running a single update process in the TemplateVM upon which those qubes are based. +This also means that it is possible to update the software for several qubes simultaneously by running a single update process in the template upon which those qubes are based. (These qubes will then have to be restarted in order for the update to take effect in them.) ### How much memory is recommended for Qubes? @@ -424,8 +424,8 @@ See introductions on Wikibooks: [here](https://en.wikibooks.org/wiki/Fedora_And_ You may have an adapter (wired, wireless), that is not compatible with open-source drivers shipped by Qubes. You may need to install a binary blob, which provides drivers, from the linux-firmware package. -Open a terminal and run `sudo dnf install linux-firmware` in the TemplateVM upon which your NetVM is based. -You have to restart the NetVM after the TemplateVM has been shut down. +Open a terminal and run `sudo dnf install linux-firmware` in the template upon which your NetVM is based. +You have to restart the NetVM after the template has been shut down. ### Can I install Qubes OS together with other operating system (dual-boot/multi-boot)? @@ -437,21 +437,21 @@ It begins with an explanation of the risks with such a setup. See [here](/doc/version-scheme/#check-installed-version). -### My qubes lost internet access after a TemplateVM update. What should I do? +### My qubes lost internet access after a template update. What should I do? -See [Update Troubleshooting](/doc/update-troubleshooting/#lost-internet-access-after-a-templatevm-update). +See [Update Troubleshooting](/doc/update-troubleshooting/#lost-internet-access-after-a-template-update). ### My keyboard layout settings are not behaving correctly. What should I do? See [Hardware Troubleshooting](/doc/hardware-troubleshooting/#keyboard-layout-settings-not-behaving-correctly). -### My dom0 and/or TemplateVM update stalls when attempting to update via the GUI tool. What should I do? +### My dom0 and/or template update stalls when attempting to update via the GUI tool. What should I do? This can usually be fixed by updating via the command line. In dom0, open a terminal and run `sudo qubes-dom0-update`. -In your TemplateVMs, open a terminal and run `sudo dnf upgrade`. +In your templates, open a terminal and run `sudo dnf upgrade`. ### How do I run a Windows HVM in non-seamless mode (i.e., as a single window)? @@ -487,12 +487,12 @@ See also [here](/doc/assigning-devices/). If you're having trouble playing a video file in a qube, you're probably missing the required codecs. The easiest way to resolve this is to install VLC Media Player and use that to play your video files. -You can do this in multiple different TemplateVM distros (Fedora, Debian, etc.). +You can do this in multiple different template distros (Fedora, Debian, etc.). For Debian: -1. (Recommended) Clone an existing Debian TemplateVM -2. Install VLC in that TemplateVM: +1. (Recommended) Clone an existing Debian template +2. Install VLC in that template: ```bash_session $ sudo apt install vlc @@ -502,9 +502,9 @@ For Debian: For Fedora: -1. (Recommended) Clone an existing Fedora TemplateVM -2. [Enable the appropriate RPMFusion repos in the desired Fedora TemplateVM](/doc/how-to-install-software/#rpmfusion-for-fedora-templatevms). -3. Install VLC in that TemplateVM: +1. (Recommended) Clone an existing Fedora template +2. [Enable the appropriate RPMFusion repos in the desired Fedora template](/doc/how-to-install-software/#rpmfusion-for-fedora-templates). +3. Install VLC in that template: ```bash_session $ sudo dnf install vlc @@ -577,9 +577,9 @@ From a `dom0` prompt, enter: qvm-prefs kernel "" ``` -### When I try to install a TemplateVM, it says no match is found. +### When I try to install a template, it says no match is found. -See [VM Troubleshooting](/doc/vm-troubleshooting/#no-match-found-when-trying-to-install-a-templatevm). +See [VM Troubleshooting](/doc/vm-troubleshooting/#no-match-found-when-trying-to-install-a-template). ### I keep getting "Failed to synchronize cache for repo" errors when trying to update my Fedora templates @@ -627,7 +627,7 @@ Specifically: - If PGP signatures are used, the signing key(s) should have well-publicized fingerprint(s) verifiable via multiple independent channels or be accessible to the developers through a web of trust. - If the software is security-sensitive and requires communication with the outside world, a "split" implementation is highly preferred (for examples, see [Split GPG](/doc/split-gpg/) and [Split Bitcoin](/doc/split-bitcoin/)). -- If the software has dependencies, these should be packaged and available in repos for a [current, Qubes-supported version](/doc/supported-versions/#templatevms) of Fedora (preferred) or Debian (unless all the insecure dependencies can run in an untrusted VM in a "split" implementation). +- If the software has dependencies, these should be packaged and available in repos for a [current, Qubes-supported version](/doc/supported-versions/#templates) of Fedora (preferred) or Debian (unless all the insecure dependencies can run in an untrusted VM in a "split" implementation). - If the software must be built from source, the source code and any builders must be signed. (Practically speaking, the more cumbersome and time-consuming it is to build from source, the less likely the developers are to use it.) diff --git a/introduction/intro.html b/introduction/intro.html index 80f5e762..ef4637fe 100644 --- a/introduction/intro.html +++ b/introduction/intro.html @@ -77,8 +77,7 @@ title: Introduction

Strong isolation

Isolate different pieces of software as if they were installed on separate - physical machines using PV or - HVM virtualization techniques. + physical machines using advanced virtualization techniques.

@@ -104,9 +103,9 @@ title: Introduction
-

DisposableVMs

+

Disposables

- Create DisposableVMs on the fly that + Create disposables on the fly that self-destruct when shut down.

diff --git a/user/advanced-topics/bind-dirs.md b/user/advanced-topics/bind-dirs.md index 15380f24..2eaedc3d 100644 --- a/user/advanced-topics/bind-dirs.md +++ b/user/advanced-topics/bind-dirs.md @@ -12,22 +12,22 @@ title: How to Make Any File Persistent (bind-dirs) ## What are bind-dirs? ## With [bind-dirs](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/bind-dirs.sh) -any arbitrary files or folders can be made persistent in TemplateBasedVMs. +any arbitrary files or folders can be made persistent in app qubes. ## What is it useful for? ## -In a TemplateBasedVM all of the file system comes from the template except `/home`, `/usr/local`, and `/rw`. -This means that changes in the rest of the filesystem are lost when the TemplateBasedVM is shutdown. +In an app qube all of the file system comes from the template except `/home`, `/usr/local`, and `/rw`. +This means that changes in the rest of the filesystem are lost when the app qube is shutdown. bind-dirs provides a mechanism whereby files usually taken from the template can be persisted across reboots. For example, in Whonix, [Tor's data dir `/var/lib/tor` has been made persistent in the TemplateBased ProxyVM sys-whonix](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5) -In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a StandaloneVM. +In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a standalone. ## How to use bind-dirs.sh? ## In this example, we want to make `/var/lib/tor` persistent. -Inside the TemplateBasedVM. +Inside the app qube. 1. Make sure folder `/rw/config/qubes-bind-dirs.d` exists. @@ -45,7 +45,7 @@ Inside the TemplateBasedVM. 4. Save. -5. Reboot the TemplateBasedVM. +5. Reboot the app qube. 6. Done. @@ -67,17 +67,17 @@ binds+=( '/etc/tor/torrc' ) ## How does it work? ## -bind-dirs.sh is called at startup of a TemplateBasedVM, and configuration files in the above configuration folders are parsed to build a bash array. +bind-dirs.sh is called at startup of an app qube, and configuration files in the above configuration folders are parsed to build a bash array. Files or folders identified in the array are copied to `/rw/bind-dirs` if they do not already exist there, and are then bind mounted over the original files/folders. -Creation of the files and folders in `/rw/bind-dirs` should be automatic the first time the TemplateBasedVM is restarted after configuration. +Creation of the files and folders in `/rw/bind-dirs` should be automatic the first time the app qube is restarted after configuration. If you want to circumvent this process, you can create the relevant file structure under `/rw/bind-dirs` and make any changes at the same time that you perform the configuration, before reboot. Note that you must create the full folder structure under `/rw/bind-dirs` - e.g you would have to create `/rw/bind-dirs/var/lib/tor` ## Limitations ## -* Files that exist in the TemplateVM root image cannot be deleted in the TemplateBasedVMs root image using bind-dirs.sh. +* Files that exist in the template root image cannot be deleted in the app qubes root image using bind-dirs.sh. * Re-running `sudo /usr/lib/qubes/init/bind-dirs.sh` without a previous `sudo /usr/lib/qubes/init/bind-dirs.sh umount` does not work. * Running `sudo /usr/lib/qubes/init/bind-dirs.sh umount` after boot (before shutdown) is probably not sane and nothing can be done about that. * Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount. @@ -102,5 +102,5 @@ binds=( "${binds[@]/'/var/lib/tor'}" ) ## Discussion ## -[TemplateBasedVMs: make selected files and folders located in the root image persistent- review bind-dirs.sh](https://groups.google.com/forum/#!topic/qubes-devel/tcYQ4eV-XX4/discussion) +[app qubes: make selected files and folders located in the root image persistent- review bind-dirs.sh](https://groups.google.com/forum/#!topic/qubes-devel/tcYQ4eV-XX4/discussion) diff --git a/user/advanced-topics/config-files.md b/user/advanced-topics/config-files.md index 1fbd0fe9..bc55048a 100644 --- a/user/advanced-topics/config-files.md +++ b/user/advanced-topics/config-files.md @@ -36,7 +36,7 @@ The scripts here all run as root. - `/rw/config/qubes-ip-change-hook` - script runs in NetVM after every external IP change and on "hardware" link status change. -- In ProxyVMs (or AppVMs with `qubes-firewall` service enabled), scripts placed in the following directories will be executed in the listed order followed by `qubes-firewall-user-script` at start up. +- In ProxyVMs (or app qubes with `qubes-firewall` service enabled), scripts placed in the following directories will be executed in the listed order followed by `qubes-firewall-user-script` at start up. Good place to write custom firewall rules. ~~~ @@ -49,7 +49,7 @@ The scripts here all run as root. The file is used only in a VM with PCI devices attached. Intended for use with problematic device drivers. -- In NetVMs/ProxyVMs, scripts placed in `/rw/config/network-hooks.d` will be ran when configuring Qubes interfaces. For each script, the `command`, `vif`, `vif_type` and `ip` is passed as arguments (see `/etc/xen/scripts/vif-route-qubes`). For example, consider a PV AppVM `work` with IP `10.137.0.100` and `sys-firewall` as NetVM. Assuming it's Xen domain id is arbitrary `12` then, the following script located at `/rw/config/network-hooks.d/hook-100.sh` in `sys-firewall`: +- In NetVMs/ProxyVMs, scripts placed in `/rw/config/network-hooks.d` will be ran when configuring Qubes interfaces. For each script, the `command`, `vif`, `vif_type` and `ip` is passed as arguments (see `/etc/xen/scripts/vif-route-qubes`). For example, consider a PV app qube `work` with IP `10.137.0.100` and `sys-firewall` as NetVM. Assuming it's Xen domain id is arbitrary `12` then, the following script located at `/rw/config/network-hooks.d/hook-100.sh` in `sys-firewall`: ~~~ #!/bin/bash @@ -75,7 +75,7 @@ The scripts here all run as root. Note that scripts need to be executable (`chmod +x`) to be used. -Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easily modify arbitrary system files in an AppVM and have those changes persist. +Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easily modify arbitrary system files in an app qube and have those changes persist. GUI and audio configuration in dom0 ----------------------------------- diff --git a/user/advanced-topics/disposablevm-customization.md b/user/advanced-topics/disposable-customization.md similarity index 59% rename from user/advanced-topics/disposablevm-customization.md rename to user/advanced-topics/disposable-customization.md index 19ef47e1..876ccc72 100644 --- a/user/advanced-topics/disposablevm-customization.md +++ b/user/advanced-topics/disposable-customization.md @@ -1,29 +1,30 @@ --- lang: en layout: doc -permalink: /doc/disposablevm-customization/ +permalink: /doc/disposable-customization/ redirect_from: +- /doc/disposablevm-customization/ - /doc/dispvm-customization/ - /en/doc/dispvm-customization/ - /doc/DispVMCustomization/ - /doc/UserDoc/DispVMCustomization/ - /wiki/UserDoc/DispVMCustomization/ ref: 174 -title: DisposableVM Customization +title: Disposable Customization --- ## Introduction -A [DisposableVM](/doc/disposablevm) can be based on any [TemplateBasedVM](/doc/glossary/#templatebasedvm). -You can also choose to use different [DisposableVM Templates](/doc/glossary/#disposablevm-template) for different DisposableVMs. -To prepare an AppVM to be a DisposableVM Template, you need to set `template_for_dispvms` property, for example: +A [disposable](/doc/disposable/) can be based on any [app qube](/doc/glossary/#app-qube). +You can also choose to use different [disposable templates](/doc/glossary/#disposable-template) for different disposables. +To prepare an app qube to be a disposable template, you need to set `template_for_dispvms` property, for example: ```shell_session [user@dom0 ~]$ qvm-prefs fedora-26-dvm template_for_dispvms True ``` -Additionally, if you want to have menu entries for starting applications in DisposableVM based on this AppVM (instead of in the AppVM itself), you can achieve it with `appmenus-dispvm` feature: +Additionally, if you want to have menu entries for starting applications in disposable based on this app qube (instead of in the app qube itself), you can achieve it with `appmenus-dispvm` feature: ```shell_session [user@dom0 ~]$ qvm-features fedora-26-dvm appmenus-dispvm 1 @@ -33,41 +34,41 @@ Note: application shortcuts that existed before setting this feature will not be ## Security -If a DisposableVM Template becomes compromised, then any DisposableVM based on that DisposableVM Template could be compromised. -Therefore, you should not make any risky customizations (e.g., installing untrusted browser plugins) in important DisposableVM Templates. -In particular, the *default* DisposableVM Template is important because it is used by the "Open in DisposableVM" feature. +If a disposable template becomes compromised, then any disposable based on that disposable template could be compromised. +Therefore, you should not make any risky customizations (e.g., installing untrusted browser plugins) in important disposable templates. +In particular, the *default* disposable template is important because it is used by the "Open in disposable" feature. This means that it will have access to everything that you open with this feature. -For this reason, it is strongly recommended that you base the default DisposableVM Template on a trusted TemplateVM and refrain from making any risky customizations to it. +For this reason, it is strongly recommended that you base the default disposable template on a trusted template and refrain from making any risky customizations to it. -## Creating a new DisposableVM Template +## Creating a new disposable template -In Qubes 4.0, you're no longer restricted to a single DisposableVM Template. Instead, you can create as many as you want. Whenever you start a new DisposableVM, you can choose to base it on whichever DisposableVM Template you like. -To create new DisposableVM Template, lets say `custom-disposablevm-template`, based on `debian-9` template, use following commands: +In Qubes 4.0, you're no longer restricted to a single disposable template. Instead, you can create as many as you want. Whenever you start a new disposable, you can choose to base it on whichever disposable template you like. +To create new disposable template, lets say `custom-disposable-template`, based on `debian-9` template, use following commands: ```shell_session -[user@dom0 ~]$ qvm-create --template debian-9 --label red custom-disposablevm-template -[user@dom0 ~]$ qvm-prefs custom-disposablevm-template template_for_dispvms True -[user@dom0 ~]$ qvm-features custom-disposablevm-template appmenus-dispvm 1 +[user@dom0 ~]$ qvm-create --template debian-9 --label red custom-disposable-template +[user@dom0 ~]$ qvm-prefs custom-disposable-template template_for_dispvms True +[user@dom0 ~]$ qvm-features custom-disposable-template appmenus-dispvm 1 ``` -Additionally you may want to set it as default DisposableVM Template: +Additionally you may want to set it as default disposable template: ```shell_session -[user@dom0 ~]$ qubes-prefs default_dispvm custom-disposablevm-template +[user@dom0 ~]$ qubes-prefs default_dispvm custom-disposable-template ``` -The above default is used whenever a qube request starting a new DisposableVM and do not specify which one (for example `qvm-open-in-dvm` tool). This can be also set in qube settings and will affect service calls from that qube. See [qrexec documentation](/doc/qrexec/#specifying-vms-tags-types-targets-etc) for details. +The above default is used whenever a qube request starting a new disposable and do not specify which one (for example `qvm-open-in-dvm` tool). This can be also set in qube settings and will affect service calls from that qube. See [qrexec documentation](/doc/qrexec/#specifying-vms-tags-types-targets-etc) for details. -If you wish to use a [Minimal TemplateVM](/doc/templates/minimal/) as a DisposableVM Template, please see the [Minimal TemplateVM](/doc/templates/minimal/) page. +If you wish to use a [Minimal Template](/doc/templates/minimal/) as a disposable template, please see the [Minimal Template](/doc/templates/minimal/) page. -## Customization of DisposableVM +## Customization of disposable -_**Note:** If you are trying to customize Tor Browser in a Whonix DisposableVM, please consult the [Whonix documentation](https://www.whonix.org/wiki/Tor_Browser/Advanced_Users#DVM_Template_Customization)._ +_**Note:** If you are trying to customize Tor Browser in a Whonix disposable, please consult the [Whonix documentation](https://www.whonix.org/wiki/Tor_Browser/Advanced_Users#disposable_Template_Customization)._ -It is possible to change the settings for each new DisposableVM. -This can be done by customizing the DisposableVM Template on which it is based: +It is possible to change the settings for each new disposable. +This can be done by customizing the disposable template on which it is based: -1. Start a terminal in the `fedora-26-dvm` qube (or another DisposableVM Template) by running the following command in a dom0 terminal. (If you enable `appmenus-dispvm` feature (as explained at the top), applications menu for this VM (`fedora-26-dvm`) will be "Disposable: fedora-26-dvm" (instead of "Domain: fedora-26-dvm") and entries there will start new DisposableVM based on that VM (`fedora-26-dvm`). Not in that VM (`fedora-26-dvm`) itself). +1. Start a terminal in the `fedora-26-dvm` qube (or another disposable template) by running the following command in a dom0 terminal. (If you enable `appmenus-dispvm` feature (as explained at the top), applications menu for this VM (`fedora-26-dvm`) will be "Disposable: fedora-26-dvm" (instead of "Domain: fedora-26-dvm") and entries there will start new disposable based on that VM (`fedora-26-dvm`). Not in that VM (`fedora-26-dvm`) itself). ```shell_session [user@dom0 ~]$ qvm-run -a fedora-26-dvm gnome-terminal @@ -76,16 +77,16 @@ This can be done by customizing the DisposableVM Template on which it is based: 2. Change the qube's settings and/or applications, as desired. Some examples of changes you may want to make include: - Changing Firefox's default startup settings and homepage. - Changing default editor, image viewer. In Debian-based templates this can be done with the `mimeopen` command. - - Changing the DisposableVM's default NetVM. For example, you may wish to set the NetVM to "none." Then, whenever you start a new DisposableVM, you can choose your desired ProxyVM manually (by changing the newly-started DisposableVMs settings). This is useful if you sometimes wish to use a DisposableVM with a Whonix Gateway, for example. It is also useful if you sometimes wish to open untrusted files in a network-disconnected DisposableVM. + - Changing the disposable's default NetVM. For example, you may wish to set the NetVM to "none." Then, whenever you start a new disposable, you can choose your desired ProxyVM manually (by changing the newly-started disposables settings). This is useful if you sometimes wish to use a disposable with a Whonix Gateway, for example. It is also useful if you sometimes wish to open untrusted files in a network-disconnected disposable. 4. Shutdown the qube (either by `poweroff` from qube's terminal, or `qvm-shutdown` from dom0 terminal). -## Using static DisposableVMs for sys-* +## Using static disposables for sys-* -You can use a static DisposableVM for `sys-*` as long as it is stateless. +You can use a static disposable for `sys-*` as long as it is stateless. For example, a `sys-net` using DHCP or `sys-usb` will work. -In most cases `sys-firewall` will also work, even if you have configured AppVM firewall rules. -The only exception is if you require something like VM to VM communication and have manually edited `iptables` or other items directly inside the firewall AppVM. +In most cases `sys-firewall` will also work, even if you have configured app qube firewall rules. +The only exception is if you require something like VM to VM communication and have manually edited `iptables` or other items directly inside the firewall app qube. To create one that has no PCI devices attached, such as for `sys-firewall`: @@ -113,7 +114,7 @@ qvm-pci attach --persistent dom0: qvm-prefs autostart true qvm-prefs netvm '' qvm-features appmenus-dispvm '' -# optional, if this DisposableVM will be providing networking +# optional, if this disposable will be providing networking qvm-prefs provides_network true ~~~ @@ -137,52 +138,52 @@ qvm-prefs sys-firewall netvm sys-net2 qubes-prefs clockvm sys-net2 ~~~ -## Adding programs to DisposableVM Application Menu +## Adding programs to disposable Application Menu -For added convenience, arbitrary programs can be added to the Application Menu of the DisposableVM. +For added convenience, arbitrary programs can be added to the Application Menu of the disposable. -In order to do that, select "Qube settings" entry in selected base AppVM, go to "Applications" tab and select desired applications as for any other qube. +In order to do that, select "Qube settings" entry in selected base app qube, go to "Applications" tab and select desired applications as for any other qube. Note that currently only applications whose main process keeps running until you close the application (i.e. do not start a background process instead) will work. One of known examples of incompatible applications is GNOME Terminal (shown on the list as "Terminal"). Choose different terminal emulator (like XTerm) instead. -## Create Custom sys-net sys-firewall and sys-usb DisposableVMs +## Create Custom sys-net sys-firewall and sys-usb disposables -Users have the option of creating customized DisposableVMs for the `sys-net`, `sys-firewall` and `sys-usb` VMs. In this configuration, a fresh VM instance is created each time a DisposableVM is launched. Functionality is near-identical to the default VMs created following a new Qubes’ installation, except the user benefits from a non-persistent filesystem. +Users have the option of creating customized disposables for the `sys-net`, `sys-firewall` and `sys-usb` VMs. In this configuration, a fresh VM instance is created each time a disposable is launched. Functionality is near-identical to the default VMs created following a new Qubes’ installation, except the user benefits from a non-persistent filesystem. Functionality is not limited, users can: - Set custom firewall rule sets and run Qubes VPN scripts. -- Set DisposableVMs to autostart at system boot. +- Set disposables to autostart at system boot. - Attach PCI devices with the `--persistent` option. -Using DisposableVMs in this manner is ideal for untrusted qubes which require persistent PCI devices, such as USB VMs and NetVMs. +Using disposables in this manner is ideal for untrusted qubes which require persistent PCI devices, such as USB VMs and NetVMs. ->_**Note:**_ Users who want customized VPN or firewall rule sets must create a separate DisposableVM Template for use by each DisposableVM. If DisposableVM Template customization is not needed, then a single DisposableVM Template is used as a template for all DisposableVMs. +>_**Note:**_ Users who want customized VPN or firewall rule sets must create a separate disposable template for use by each disposable. If disposable template customization is not needed, then a single disposable template is used as a template for all disposables. -### Create and configure the DisposableVM Template on which the DisposableVM will be based +### Create and configure the disposable template on which the disposable will be based -1. Create the DisposableVM Template: +1. Create the disposable template: ```shell_session - [user@dom0 ~]$ qvm-create --class AppVM --label gray + [user@dom0 ~]$ qvm-create --class AppVM --label gray ``` -2. _(optional)_ In the DisposableVM Template, add custom firewall rule sets, Qubes VPN scripts, etc. +2. _(optional)_ In the disposable template, add custom firewall rule sets, Qubes VPN scripts, etc. Firewall rules sets and Qubes VPN scripts can be added just like any other VM. -3. Set the DisposableVM Template as template for DisposableVMs: +3. Set the disposable template as template for disposables: ```shell_session - [user@dom0 ~]$ qvm-prefs template_for_dispvms true + [user@dom0 ~]$ qvm-prefs template_for_dispvms true ``` -### Create the sys-net DisposableVM +### Create the sys-net disposable -1. Create `sys-net` DisposableVM based on the DisposableVM Template: +1. Create `sys-net` disposable based on the disposable template: ```shell_session - [user@dom0 ~]$ qvm-create --template --class DispVM --label red disp-sys-net + [user@dom0 ~]$ qvm-create --template --class DispVM --label red disp-sys-net ``` 2. Set `disp-sys-net` virtualization mode to [hvm](/doc/hvm/): @@ -221,7 +222,7 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe [user@dom0 ~]$ qvm-prefs disp-sys-net autostart true ``` -8. _(recommended)_ Disable the `appmenus-dispvm` feature, as disp-sys-net is not itself a DisposableVM template (Note: this is only necessary if you enabled the `appmenus-dispvm` feature for the DisposableVM template): +8. _(recommended)_ Disable the `appmenus-dispvm` feature, as disp-sys-net is not itself a disposable template (Note: this is only necessary if you enabled the `appmenus-dispvm` feature for the disposable template): ```shell_session [user@dom0 ~]$ qvm-features disp-sys-net appmenus-dispvm '' @@ -235,12 +236,12 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe 10. _(recommended)_ Allow templates to be updated via `disp-sys-net`. In dom0, edit `/etc/qubes-rpc/policy/qubes.UpdatesProxy` to change the target from `sys-net` to `disp-sys-net`. -### Create the sys-firewall DisposableVM +### Create the sys-firewall disposable -1. Create `sys-firewall` DisposableVM: +1. Create `sys-firewall` disposable: ```shell_session - [user@dom0 ~]$ qvm-create --template --class DispVM --label green disp-sys-firewall + [user@dom0 ~]$ qvm-create --template --class DispVM --label green disp-sys-firewall ``` 2. Set `disp-sys-firewall` to provide network for other VMs: @@ -255,7 +256,7 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe [user@dom0 ~]$ qvm-prefs disp-sys-firewall netvm disp-sys-net ``` -4. Set `disp-sys-firewall` as NetVM for other AppVMs: +4. Set `disp-sys-firewall` as NetVM for other app qubes: ```shell_session [user@dom0 ~]$ qvm-prefs netvm disp-sys-firewall @@ -267,7 +268,7 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe [user@dom0 ~]$ qvm-prefs disp-sys-firewall autostart true ``` -6. _(recommended)_ Disable the `appmenus-dispvm` feature, as disp-sys-firewall is not itself a DisposableVM template (Note: this is only necessary if you enabled the `appmenus-dispvm` feature for the DisposableVM template): +6. _(recommended)_ Disable the `appmenus-dispvm` feature, as disp-sys-firewall is not itself a disposable template (Note: this is only necessary if you enabled the `appmenus-dispvm` feature for the disposable template): ```shell_session [user@dom0 ~]$ qvm-features disp-sys-firewall appmenus-dispvm '' @@ -279,12 +280,12 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe [user@dom0 ~]$ qubes-prefs default_netvm disp-sys-firewall ``` -### Create the sys-usb DisposableVM +### Create the sys-usb disposable 1. Create the `disp-sys-usb`: ```shell_session - [user@dom0 ~]$ qvm-create --template --class DispVM --label red disp-sys-usb + [user@dom0 ~]$ qvm-create --template --class DispVM --label red disp-sys-usb ``` 2. Set the `disp-sys-usb` virtualization mode to hvm: @@ -318,7 +319,7 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe [user@dom0 ~]$ qvm-prefs disp-sys-usb autostart true ``` -7. _(recommended)_ Disable the `appmenus-dispvm` feature, as disp-sys-usb is not itself a DisposableVM template (Note: this is only necessary if you enabled the `appmenus-dispvm` feature for the DisposableVM template): +7. _(recommended)_ Disable the `appmenus-dispvm` feature, as disp-sys-usb is not itself a disposable template (Note: this is only necessary if you enabled the `appmenus-dispvm` feature for the disposable template): ```shell_session [user@dom0 ~]$ qvm-features disp-sys-usb appmenus-dispvm '' @@ -339,9 +340,9 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe disp-sys-usb dom0 allow,user=root ``` -### Starting the DisposableVMs +### Starting the disposables -Prior to starting the new VMs, users should ensure that no other VMs such as the old `sys-net` and `sys-usb` VMs are running. This is because no two VMs can share the same PCI device while both running. It is recommended that users detach the PCI devices from the old VMs without deleting them. This will allow users to reattach the PCI devices if the newly created DisposableVMs fail to start. +Prior to starting the new VMs, users should ensure that no other VMs such as the old `sys-net` and `sys-usb` VMs are running. This is because no two VMs can share the same PCI device while both running. It is recommended that users detach the PCI devices from the old VMs without deleting them. This will allow users to reattach the PCI devices if the newly created disposables fail to start. Detach PCI device from VM: @@ -353,28 +354,28 @@ Detach PCI device from VM: If the `disp-sys-usb` does not start, it could be due to a PCI passthrough problem. For more details on this issue along with possible solutions, users can look [here](/doc/pci-troubleshooting/#pci-passthrough-issues). -## Deleting DisposableVMs +## Deleting disposables -While working in a DisposableVM, you may want to open a document in another DisposableVM. -For this reason, the property `default_dispvm` may be set to the name of your DisposableVM in a number of VMs: +While working in a disposable, you may want to open a document in another disposable. +For this reason, the property `default_dispvm` may be set to the name of your disposable in a number of VMs: ```shell_session [user@dom0 ~]$ qvm-prefs workvm | grep default_dispvm -default_dispvm - custom-disposablevm-template +default_dispvm - custom-disposable-template ``` -This will prevent the deletion of the DisposableVM Template. In order to fix this you need to unset the `default_dispvm` property: +This will prevent the deletion of the disposable template. In order to fix this you need to unset the `default_dispvm` property: ```shell_session [user@dom0 ~]$ qvm-prefs workvm default_dispvm "" ``` -You can then delete the DisposableVM Template: +You can then delete the disposable template: ```shell_session -[user@dom0 ~]$ qvm-remove custom-disposablevm-template +[user@dom0 ~]$ qvm-remove custom-disposable-template This will completely remove the selected VM(s) - custom-disposablevm-template + custom-disposable-template ``` diff --git a/user/advanced-topics/how-to-install-software-in-dom0.md b/user/advanced-topics/how-to-install-software-in-dom0.md index be426e6c..331849c6 100644 --- a/user/advanced-topics/how-to-install-software-in-dom0.md +++ b/user/advanced-topics/how-to-install-software-in-dom0.md @@ -31,7 +31,7 @@ This separation of duties significantly reduces the attack surface, since all of Although this update scheme is far more secure than directly downloading updates in dom0, it is not invulnerable. For example, there is nothing that the Qubes OS Project can feasibly do to prevent a malicious RPM from exploiting a hypothetical bug in the cryptographic signature verification operation. At best, we could switch to a different distro or package manager, but any of them could be vulnerable to the same (or a similar) attack. -While we could, in theory, write a custom solution, it would only be effective if Qubes repos included all of the regular TemplateVM distro's updates, and this would be far too costly for us to maintain. +While we could, in theory, write a custom solution, it would only be effective if Qubes repos included all of the regular template distro's updates, and this would be far too costly for us to maintain. ## How to update dom0 diff --git a/user/advanced-topics/installing-contributed-packages.md b/user/advanced-topics/installing-contributed-packages.md index e2abf82d..dc4724d1 100644 --- a/user/advanced-topics/installing-contributed-packages.md +++ b/user/advanced-topics/installing-contributed-packages.md @@ -35,8 +35,8 @@ In a Debian-based template, use `apt`: sudo apt update && sudo apt install qubes-repo-contrib ``` -The new repository definition will be in the usual location for your distro, and it will follow the naming pattern `qubes-contrib-*`, depending on your Qubes release and whether it is in dom0 or a TemplateVM. -For example, in a Fedora TemplateVM on Qubes 4.0, the new repository definition would be: +The new repository definition will be in the usual location for your distro, and it will follow the naming pattern `qubes-contrib-*`, depending on your Qubes release and whether it is in dom0 or a template. +For example, in a Fedora template on Qubes 4.0, the new repository definition would be: ``` /etc/yum.repos.d/qubes-contrib-vm-r4.0.repo diff --git a/user/advanced-topics/managing-vm-kernels.md b/user/advanced-topics/managing-vm-kernels.md index c3753a6b..4fd3574b 100644 --- a/user/advanced-topics/managing-vm-kernels.md +++ b/user/advanced-topics/managing-vm-kernels.md @@ -278,7 +278,7 @@ Booting to a kernel inside the template is not supported under `PVH`. #### Distribution kernel -Apply the following instruction in a Debian TemplateVM or in a Debian StandaloneVM. +Apply the following instruction in a Debian template or in a Debian standalone. Using a distribution kernel package the initramfs and kernel modules should be handled automatically. diff --git a/user/advanced-topics/mount-from-other-os.md b/user/advanced-topics/mount-from-other-os.md index 29ed3d8d..bb907aab 100644 --- a/user/advanced-topics/mount-from-other-os.md +++ b/user/advanced-topics/mount-from-other-os.md @@ -17,14 +17,14 @@ These functions are manual and do not require any Qubes specific tools. All step - LUKS encrypted disk - LVM based VM storage -Before beginning, if attempting to access one Qubes system from another, it is recommended to pass the entire encrypted Qubes disk to an isolated AppVM. +Before beginning, if attempting to access one Qubes system from another, it is recommended to pass the entire encrypted Qubes disk to an isolated app qube. This can be done with the command `qvm-block attach dom0:` in dom0. Decrypting the Disk ----------------- 1. Find the disk to be accessed: - 1. Open a Linux terminal in either dom0 or the AppVM the disk was passed through to and enter `lsblk`, which will result in an output similar to the following. + 1. Open a Linux terminal in either dom0 or the app qube the disk was passed through to and enter `lsblk`, which will result in an output similar to the following. In this example, the currently booted Qubes system is installed on `sda` and the qubes system to be accessed is on `nvme0n1p2`. ``` @@ -58,7 +58,7 @@ Decrypting the Disk Accessing LVM Logical Volumes ----------------------------- -3. If using an AppVM or standard Linux, LVM should automatically discover the Qubes LVM configuration. In this case, continue to step 4. +3. If using an app qube or standard Linux, LVM should automatically discover the Qubes LVM configuration. In this case, continue to step 4. 1. Qubes uses the default name `qubes_dom0` for it's LVM VG. This will conflict with the name of the VG of the currently installed system. To read both, you will have to rename the VG. @@ -77,7 +77,7 @@ Mounting the disk | ----------------------------- | ----------------- | ------------------------------------------- | | other\_install/root | dom0 root | The root partition of dom0. | | other\_install/-private | VM | The /rw partition of the named VM. | -| other\_install/-root | templateVM root | The root partition of the named TemplateVM. | +| other\_install/-root | template root | The root partition of the named template. | | other\_install/pool00\_tmeta | LVM Metadata | The metadata LV of this disk. | 6. Mount the disk using the command `mount /dev/other_install/ `. @@ -91,7 +91,7 @@ Reverting Changes Any changes which were made to the system in the above steps will need to be reverted before the disk will properly boot. However, LVM will not allow an VG to be renamed to a name already in use. -Thes steps must occur either in an AppVM or using recovery media. +Thes steps must occur either in an app qube or using recovery media. 1. Unmount any disks that were accessed. 2. Rename the VG back to qubes\_dom0 using the command `vgrename other_install qubes_dom0`. diff --git a/user/advanced-topics/resize-disk-image.md b/user/advanced-topics/resize-disk-image.md index faab8bf3..527facd4 100644 --- a/user/advanced-topics/resize-disk-image.md +++ b/user/advanced-topics/resize-disk-image.md @@ -85,7 +85,7 @@ zpool online -e poolname ada0 #### Linux -Qubes will automatically grow the filesystem for you on all AppVMs with Qubes packages installed (which are all AppVMs installed from templates, cloned from templates etc. - if you have not created an empty HVM and installed a Linux distribution in it, without using Qubes repositories, you are almost certainly safe). +Qubes will automatically grow the filesystem for you on all app qubes with Qubes packages installed (which are all app qubes installed from templates, cloned from templates etc. - if you have not created an empty HVM and installed a Linux distribution in it, without using Qubes repositories, you are almost certainly safe). Otherwise, you will see that there is unallocated free space at the end of your primary disk. You can use standard linux tools like `fdisk` and `resize2fs` to make this space available. diff --git a/user/advanced-topics/salt.md b/user/advanced-topics/salt.md index 3ee82da2..eb83a33a 100644 --- a/user/advanced-topics/salt.md +++ b/user/advanced-topics/salt.md @@ -243,8 +243,8 @@ optional arguments: --skip-dom0 Skip dom0 configuration (VM creation etc) --targets TARGETS Coma separated list of VMs to target --templates Target all templates - --app Target all AppVMs - --all Target all non-disposable VMs (TemplateVMs and AppVMs) + --app Target all app qubes + --all Target all non-disposables (templates and app qubes) ``` To apply a state to all templates, call `qubesctl --templates state.highstate`. @@ -260,18 +260,18 @@ compromise cannot spread from one VM to another. Beginning with Qubes 4.0 and after [QSB #45](/news/2018/12/03/qsb-45/), we implemented two changes: -1. Added the `management_dispvm` VM property, which specifies the DVM +1. Added the `management_dispvm` VM property, which specifies the disposable Template that should be used for management, such as Salt - configuration. TemplateBasedVMs inherit this property from their - parent TemplateVMs. If the value is not set explicitly, the default + configuration. App qubes inherit this property from their + parent templates. If the value is not set explicitly, the default is taken from the global `management_dispvm` property. The VM-specific property is set with the `qvm-prefs` command, while the global property is set with the `qubes-prefs` command. -2. Created the `default-mgmt-dvm` DisposableVM Template, which is hidden from +2. Created the `default-mgmt-dvm` disposable template, which is hidden from the menu (to avoid accidental use), has networking disabled, and has - a black label (the same as TemplateVMs). This VM is set as the global - `management_dispvm`. Keep in mind that this DVM template has full control + a black label (the same as templates). This VM is set as the global + `management_dispvm`. Keep in mind that this disposable template has full control over the VMs it's used to manage. ## Writing Your Own Configurations @@ -420,7 +420,7 @@ The default settings can be overridden in the pillar data located in: ``` In dom0, you can apply a single state with `sudo qubesctl state.sls STATE_NAME`. -For example, `sudo qubesctl state.sls qvm.personal` will create a `personal` VM (if it does not already exist) with all its dependencies (TemplateVM, `sys-firewall`, and `sys-net`). +For example, `sudo qubesctl state.sls qvm.personal` will create a `personal` VM (if it does not already exist) with all its dependencies (template, `sys-firewall`, and `sys-net`). ### Available states @@ -451,31 +451,31 @@ Whonix gateway ProxyVM #### `qvm.personal` -Personal AppVM +Personal app qube #### `qvm.work` -Work AppVM +Work app qube #### `qvm.untrusted` -Untrusted AppVM +Untrusted app qube #### `qvm.vault` -Vault AppVM with no NetVM enabled. +Vault app qube with no NetVM enabled. #### `qvm.default-dispvm` -Default DisposableVM template - fedora-26-dvm AppVM +Default disposable template - fedora-26-dvm app qube #### `qvm.anon-whonix` -Whonix workstation AppVM. +Whonix workstation app qube. #### `qvm.whonix-ws-dvm` -Whonix workstation AppVM for Whonix DisposableVMs. +Whonix workstation app qube for Whonix disposables. #### `qvm.updates-via-whonix` @@ -483,27 +483,27 @@ Setup UpdatesProxy to route all templates updates through Tor (sys-whonix here). #### `qvm.template-fedora-21` -Fedora-21 TemplateVM +Fedora-21 template #### `qvm.template-fedora-21-minimal` -Fedora-21 minimal TemplateVM +Fedora-21 minimal template #### `qvm.template-debian-7` -Debian 7 (wheezy) TemplateVM +Debian 7 (wheezy) template #### `qvm.template-debian-8` -Debian 8 (jessie) TemplateVM +Debian 8 (jessie) template #### `qvm.template-whonix-gw` -Whonix Gateway TemplateVM +Whonix Gateway template #### `qvm.template-whonix-ws` -Whonix Workstation TemplateVM +Whonix Workstation template #### `update.qubes-dom0` @@ -515,7 +515,7 @@ $ sudo qubesctl --show-output state.sls update.qubes-dom0 #### `update.qubes-vm` -Updates domUs. Example to update all TemplateVMs (executed in dom0): +Updates domUs. Example to update all templates (executed in dom0): ``` $ sudo qubesctl --show-output --skip-dom0 --templates state.sls update.qubes-vm @@ -543,9 +543,9 @@ Additional pillar data is available to ease targeting configurations (for exampl VM type. Possible values: - `admin` - Administration domain (`dom0`) -- `template` - Template VM +- `template` - template - `standalone` - Standalone VM -- `app` - Template based AppVM +- `app` - Template based app qube ### `qubes:template` diff --git a/user/advanced-topics/secondary-storage.md b/user/advanced-topics/secondary-storage.md index fe5888ae..ede40e7b 100644 --- a/user/advanced-topics/secondary-storage.md +++ b/user/advanced-topics/secondary-storage.md @@ -12,12 +12,12 @@ title: Secondary Storage Suppose you have a fast but small primary SSD and a large but slow secondary HDD. -You want to store a subset of your AppVMs on the HDD. +You want to store a subset of your app qubes on the HDD. ## Instructions Qubes 4.0 is more flexible than earlier versions about placing different VMs on different disks. -For example, you can keep templates on one disk and AppVMs on another, without messy symlinks. +For example, you can keep templates on one disk and app qubes on another, without messy symlinks. These steps assume you have already created a separate [volume group](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_admin#VG_create) and [thin pool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/thinly_provisioned_volume_creation) (not thin volume) for your HDD. See also [this example](https://www.linux.com/blog/how-full-encrypt-your-linux-system-lvm-luks) if you would like to create an encrypted LVM pool (but note you can use a single logical volume if preferred, and to use the `-T` option on `lvcreate` to specify it is thin). You can find the commands for this example applied to Qubes at the bottom of this R4.0 section. diff --git a/user/advanced-topics/standalone-and-hvm.md b/user/advanced-topics/standalones-and-hvm.md similarity index 80% rename from user/advanced-topics/standalone-and-hvm.md rename to user/advanced-topics/standalones-and-hvm.md index 770cfcca..76d5a5a7 100644 --- a/user/advanced-topics/standalone-and-hvm.md +++ b/user/advanced-topics/standalones-and-hvm.md @@ -1,45 +1,44 @@ --- lang: en layout: doc -permalink: /doc/standalone-and-hvm/ +permalink: /doc/standalones-and-hvm/ redirect_from: +- /doc/standalone-and-hvm/ - /doc/hvm/ - /doc/hvm-create/ - /en/doc/hvm-create/ - /doc/HvmCreate/ - /wiki/HvmCreate/ ref: 130 -title: StandaloneVMs and HVMs +title: Standalones and HVMs --- +A [standalone](/doc/glossary/#standalone) is a type of qube that is created by cloning a [template](/doc/templates/). +Unlike templates, however, standalones do not supply their root filesystems to other qubes. +Examples of situations in which standalones can be useful include: -A [StandaloneVM](/doc/glossary/#standalonevm) is a type of VM in Qubes that is created by cloning a [TemplateVM](/doc/templates/). -Unlike TemplateVMs, however, StandaloneVMs do not supply their root filesystems to other VMs. -Examples of situations in which StandaloneVMs can be useful include: - -- VMs used for development (dev environments often require a lot of specific packages and tools) -- VMs used for installing untrusted packages. +- Qubes used for development (dev environments often require a lot of specific packages and tools) +- Qubes used for installing untrusted packages. Normally, you install digitally signed software from Red Hat/Fedora repositories, and it's reasonable that such software has non malicious *installation* scripts (rpm pre/post scripts). - However, when you would like to install some packages from less trusted sources, or unsigned, then using a dedicated (untrusted) standalone VM might be a better way. + However, when you would like to install some packages from less trusted sources, or unsigned, then using a dedicated (untrusted) standalone might be a better way. Meanwhile, a [Hardware-assisted Virtual Machine (HVM)](/doc/glossary/#hvm), also known as a "Fully-Virtualized Virtual Machine," utilizes the virtualization extensions of the host CPU. -These are typically contrasted with [Paravirtualized (PV)](/doc/glossary/#pv) VMs. +These are typically contrasted with Paravirtualized (PV) VMs. HVMs allow you to create qubes based on any OS for which you have an installation ISO, so you can easily have qubes running Windows, *BSD, or any Linux distribution. You can also use HVMs to run "live" distros. -By default, every Qubes VM runs in [PVH](/doc/glossary/#pvhvm) mode (which has security advantages over both PV and HVM) except for those with attached PCI devices, which run in HVM mode. +By default, every Qubes VM runs in PVH mode (which has security advantages over both PV and HVM) except for those with attached PCI devices, which run in HVM mode. See [here](https://blog.invisiblethings.org/2017/07/31/qubes-40-rc1.html) for a discussion of the switch from PV to HVM and [here](/news/2018/01/11/qsb-37/) for the announcement about the change to using PVH as default. -The StandaloneVM/TemplateVM distinction and the HVM/PV/PVH distinctions are orthogonal. +The standalone/template distinction and the HVM/PV/PVH distinctions are orthogonal. The former is about root filesystem inheritance, whereas the latter is about the virtualization mode. -In practice, however, it is most common for StandaloneVMs to be HVMs and for HVMs to be StandaloneVMs. -In fact, this is so common that [StandaloneHVMs](/doc/glossary/#standalonehvm) are typically just called "HVMs." +In practice, however, it is most common for standalones to be HVMs and for HVMs to be standalones. Hence, this page covers both topics. -## Creating a StandaloneVM +## Creating a standalone -You can create a StandaloneVM in the Qube Manager by selecting the "Type" of "Standalone qube copied from a template" or "Empty standalone qube (install your own OS)." +You can create a standalone in the Qube Manager by selecting the "Type" of "Standalone qube copied from a template" or "Empty standalone qube (install your own OS)." Alternatively, from the dom0 command line: @@ -47,7 +46,7 @@ Alternatively, from the dom0 command line: qvm-create --class StandaloneVM --label