Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-01-26 06:26:18 -05:00
Code Issues Packages Projects Releases Wiki Activity

Improve clarity, grammar, and orthography

Browse Source
This commit is contained in:
Andrew David Wong 2019-02-18 23:38:53 -06:00 committed by GitHub
parent ae29a13466
commit 30b72d8913
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
installing/upgrade/upgrade-to-r4.0.md
View File

@ -90,22 +90,23 @@ Restore from your backup
For the TemplateVM OS versions supported in R4.0, see [Supported Versions](/doc/supported-versions/#templatevms).
If the restore tool complains about missing templates, you can select the option to restore the AppVMs anyway, then change them afterward to use one of the default R4.0 templates.
Note about additional disp-\* qubes created during restore
----------------------------------------------------------
Note about additional disp-* qubes created during restore
---------------------------------------------------------
One of differences between R3.2 and R4.0 is handling Disposable qubes.
In R3.2, Disposable qube inherited its network settings (netvm, firewall rules) from the calling qube.
In R4.0 it is no longer the case.
Instead, in R4.0 it's possible to create multiple DVM templates and choose which one should be used by each qube.
It's even possible to use different DVM templates for different operations from the same qube.
This allows much more flexibility, as not only network settings can be differentiated, but all the qubes properties (including template, memory settings etc).
One of differences between R3.2 and R4.0 is the handling of DisposableVMs.
In R3.2, a DisposableVM inherited its network settings (NetVM and firewall rules) from the calling qube.
In R4.0, this is no longer the case.
Instead, in R4.0 it's possible to create multiple DVM Templates and choose which one should be used by each qube.
It's even possible to use different DVM Templates for different operations from the same qube.
This allows much more flexibility, since it allows you to differentiate not only network settings, but all of a qube's properties (including its template, memory settings, etc.).
Restoring a backup from R3.2 preserve the old behavior by creating separate DVM template for each network-providing VM (and also `disp-no-netvm` for network-isolated qubes).
Then, each restored qubes are configured to use appropriate DVM template, according to its `netvm` or `dispvm_netvm` property from R3.2.
This way, DispVMs started on R4.0 by qubes restored from R3.2 backup have the same netvm settings as they had on R3.2.
Restoring a backup from R3.2 preserves the old behavior by creating separate DVM Template for each network-providing qube (and also `disp-no-netvm` for network-isolated qubes).
Then, each restored qube is configured to use the appropriate DVM Template according to its `netvm` or `dispvm_netvm` property from R3.2.
This way, DisposableVMs started on R4.0 by qubes restored from a R3.2 backup have the same NetVM settings as they had on R3.2.
If this behavior is undesired for you, or you want to configure it differently, you can remove those `disp-*` DVM templates.
But to do so, you first need make sure they are not set for any `default_dispvm` property anywhere. Both Qubes Manager and `qvm-remove` tool will show you where such DVM template is used, so you can go there and change the setting.
If you find this behavior undesirable and want to configure it differently, you can remove those `disp-*` DVM Templates.
But, to do so, you must first make sure they are not set as the value for the `default_dispvm` property on any other qube.
Both Qubes Manager and the `qvm-remove` tool will show you where a DVM Template is being used, so you can go there and change the setting.
Upgrade all Template and Standalone VM(s)
-----------------------------------------