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

Edit secondary storage page for clarity

Browse source
This commit is contained in:
unman 2025-05-25 01:05:24 +00:00
parent 75d18931d1
commit f72ad83ffb
No known key found for this signature in database
GPG key ID: BB52274595B71262
1 changed files with 21 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

40
user/advanced-configuration/secondary-storage.md
View file

@ -10,35 +10,38 @@ ref: 187
title: Secondary Storage
---
# Storing AppVMs on Secondary Drives
# Storing qubes 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.
You may want to store a subset of your qubes on the HDD.
Or if you install a second SSD, you may want to use *that* for storage of some qubes.
This page explains how to use that second drive.
## 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 qubes on another, without messy symlinks.
You can query qvm-pool to list available storage drivers:
``` shell_session
qvm-pool --help-drivers
```
qvm-pool driver explaination:
```shell_session
qvm-pool driver explanation:
```
<file> refers to using a simple file for image storage and lacks a few features.
<file-reflink> refers to storing images on a filesystem supporting copy on write.
<linux-kernel> refers to a directory holding kernel images.
<lvm_thin> refers to LVM managed pools.
```
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 they will lack some features: for example, you won't be able to do backups without shutting down the qube.
Additionnal storage can also be added on a Btrfs filesystem. A unique feature of Btrfs over LVM is that data can be compressed transparently. The subvolume can also be backuped using snapshots for an additionnal layer of protection; Btrfs supports differents level of redundancy; it has parity checksum; it is able to be expanded/shrinked. Starting/stoping a VM has less impact and less chances of causing slowdown of the system as some have noted with LVM. Revelant information for general btrfs configuration will be provided after LVM section.
Additional storage can also be added on a Btrfs filesystem. A unique feature of Btrfs is that data can be compressed transparently. The subvolume can also be backed up using snapshots for an additional layer of protection; Btrfs supports differents level of redundancy; it has parity checksum; Btrfs volumes can be expanded or shrunk. Starting or stopping a VM has less impact and less chance of causing slowdown of the system as some users have noted with LVM. Relevant information for general btrfs configuration will be provided after the section on LVM storage.
### LVM storage
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.
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 second drive..
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.
First, collect some information in a dom0 terminal:
@ -48,9 +51,9 @@ sudo pvs
sudo lvs
```
Take note of the VG and thin pool names for your HDD, then register it with Qubes:
Take note of the VG and thin pool names for your second drive., then register it with Qubes:
```shell_session
```
# <pool_name> is a freely chosen pool name
# <vg_name> is LVM volume group name
# <thin_pool_name> is LVM thin pool name
@ -58,10 +61,10 @@ qvm-pool --add <pool_name> lvm_thin -o volume_group=<vg_name>,thin_pool=<thin_po
```
### BTRFS storage
Theses steps assume you have already created a separate Btrfs filesystem for your HDD, that it is encrypted with LUKS and it is mounted. It is recommended to use a subvolume as it enables compression and excess storage can be use for other things.
Theses steps assume you have already created a separate Btrfs filesystem for your second drive., that it is encrypted with LUKS and it is mounted. It is recommended to use a subvolume as it enables compression and excess storage can be use for other things.
It is possible to use already available Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using:
It is possible to use an existing Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using:
```shell_session
mount -t btrfs
btrfs show filesystem
@ -89,20 +92,19 @@ qvm-clone -P <pool_name> <sourceVMname> <cloneVMname>
qvm-remove <sourceVMname>
```
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:
```shell_session
qvm-prefs <appvmname_based_on_old_template> template <new_template_name>
```
#### Example HDD setup
#### Example setup of second drive.
Assuming the secondary hard disk is at /dev/sdb (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
Assuming the secondary hard disk is at /dev/sdb , you can encrypt the drive as follows. Note that the drive contents will be completely erased, In a dom0 terminal run this command - use the same passphrase as the main Qubes disk to avoid a second password prompt at boot:
```shell_session
sudo cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb
sudo blkid /dev/sdb
```
Note the device's UUID (in this example "b209..."), we will use it as its luks name for auto-mounting at boot, by doing:
@ -111,13 +113,13 @@ Note the device's UUID (in this example "b209..."), we will use it as its luks n
sudo nano /etc/crypttab
```
And adding this line (change both "b209..." for your device's UUID from blkid) to crypttab:
And adding this line to crypttab (replacing both "b209..." entries with your device's UUID taken from blkid) :
```shell_session
luks-b20975aa-8318-433d-8508-6c23982c6cde UUID=b20975aa-8318-433d-8508-6c23982c6cde none
```
Reboot the computer so the new luks device appears at /dev/mapper/luks-b209... and we can then create its pool, by doing this on a dom0 terminal (substitute the b209... UUIDs with yours):
Reboot the computer so the new luks device appears at /dev/mapper/luks-b209... You can then create the new pool by running this command in a dom0 terminal (substitute the b209... UUIDs with your UID):
##### For LVM
@ -180,7 +182,7 @@ Finally we will tell Qubes to add a new pool on the just created Btrfs subvolume
qvm-pool --add poolhd0_qubes file-reflink -o dir_path=/var/lib/qubes_newpool,revisions_to_keep=2
```
By default VMs will be created on the main Qubes disk (i.e. a small SSD), to create them on this secondary HDD do the following on a dom0 terminal:
By default VMs will be created on the main Qubes disk (i.e. a small SSD), to create them on this secondary drive do the following on a dom0 terminal:
```shell_session
qvm-create -P poolhd0_qubes --label red unstrusted-hdd