Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-12-26 15:59:24 -05:00
Code Issues Packages Projects Releases Wiki Activity

fix line breaks

Browse Source
This commit is contained in:
awokd 2018-02-05 15:48:44 +00:00 committed by GitHub
parent b71bc6174f
commit 01dee1b2a8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
configuration/secondary-storage.md
View File

@ -11,19 +11,15 @@ redirect_from:
Storing AppVMs on Secondary Drives
==================================
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.
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.
### R4.0 ###
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.
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.
Assuming 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,
first collect some information in a dom0 terminal:
Assuming 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, first collect some information in a dom0 terminal:
sudo pvs
sudo lvs
@ -39,21 +35,17 @@ Now, you can create qubes in that pool:
qvm-create -P pool_name --label red vmname
It isn't possible to directly migrate an existing qube to the new pool, but
you can clone it there, then remove the old one:
It isn't possible to directly migrate an existing qube to the new pool, but you can clone it there, then remove the old one:
qvm-clone -P pool_name old_name new_name
qvm-remove old_name
If that was a template, or other qube referenced elsewhere (NetVM or
such), you will need to adjust those references manually after moving.
If that was a template, or other qube referenced elsewhere (NetVM or such), you will need to adjust those references manually after moving.
For example:
qvm-prefs appvm_based_on_old_name_template template new_name
In theory, you can still use file-based disk images ("file" pool driver),
but it lacks some features such as you won't be able to do
backups without shutting down the qube.
In theory, you can still use file-based disk images ("file" pool driver), but it lacks some features such as you won't be able to do backups without shutting down the qube.
### R3.2 ###
@ -62,21 +54,17 @@ In dom0:
mv /var/lib/qubes/appvms/my-new-appvm /path/to/secondary/drive/my-new-appvm
ln -s /path/to/secondary/drive/my-new-appvm /var/lib/qubes/appvms/
Now, `my-new-appvm` will behave as if it were still stored on the primary SSD
(except that it will probably be slower, since it's actually stored on the
secondary HDD).
Now, `my-new-appvm` will behave as if it were still stored on the primary SSD (except that it will probably be slower, since it's actually stored on the secondary HDD).
* The above procedure does **not** interfere with [Qubes Backup][]. However,
attempting to symlink a `private.img` file (rather than the whole AppVM
directory) is known to prevent the `private.img` file from being backed up.
The same problem may occur if the above procedure is attempted on a
[TemplateVM][]. [[1]]
* The above procedure does **not** interfere with [Qubes Backup][].
However, attempting to symlink a `private.img` file (rather than the whole AppVM directory) is known to prevent the `private.img` file from being backed up.
The same problem may occur if the above procedure is attempted on a [TemplateVM][]. [[1]]
* After implementing the above procedure, starting `my-new-appvm` will cause
dom0 notifications to occur stating that loop devices have been attached to
dom0. This is normal. (No untrusted devices are actually being mounted to
dom0.) Do not attempt to detach these disks. (They will automatically be
detached when you shut down the AppVM.) [[2]]
* After implementing the above procedure, starting `my-new-appvm` will cause dom0 notifications to occur stating that loop devices have been attached to dom0.
This is normal.
(No untrusted devices are actually being mounted to dom0.)
Do not attempt to detach these disks.
(They will automatically be detached when you shut down the AppVM.) [[2]]
[Qubes Backup]: https://www.qubes-os.org/doc/BackupRestore/
[TemplateVM]: https://www.qubes-os.org/doc/Templates/