From e8ccfd7d58b87d4830e9894e81fb41533463de44 Mon Sep 17 00:00:00 2001 From: awokd <34515595+awokd@users.noreply.github.com> Date: Sun, 1 Apr 2018 07:43:10 +0000 Subject: [PATCH] add revisions_to_keep and <> markers --- configuration/secondary-storage.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/configuration/secondary-storage.md b/configuration/secondary-storage.md index 4a204811..1506f020 100644 --- a/configuration/secondary-storage.md +++ b/configuration/secondary-storage.md @@ -19,31 +19,34 @@ You want to store a subset of your AppVMs on the HDD. 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: +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). + +First, collect some information in a dom0 terminal: sudo pvs sudo lvs Take note of the VG and thin pool names for your HDD, then register it with Qubes: - # pool_name is a freely chosen pool name - # vg_name is LVM volume group name - # thin_pool_name is LVM thin pool name - qvm-pool --add pool_name lvm_thin -o volume_group=vg_name,thin_pool=thin_pool_name + # is a freely chosen pool name + # is LVM volume group name + # is LVM thin pool name + qvm-pool --add lvm_thin -o volume_group=,thin_pool=,revisions_to_keep=2 Now, you can create qubes in that pool: - qvm-create -P pool_name --label red vmname + qvm-create -P --label red 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 + qvm-clone -P + qvm-remove 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 + qvm-prefs template 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. @@ -51,8 +54,8 @@ In theory, you can still use file-based disk images ("file" pool driver), but it 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/ + mv /var/lib/qubes/appvms/ /path/to/secondary/drive/ + ln -s /path/to/secondary/drive/ /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).