From b71bc6174f4d246d15deb5b3da552dda0b5fdf41 Mon Sep 17 00:00:00 2001 From: awokd <34515595+awokd@users.noreply.github.com> Date: Sat, 3 Feb 2018 16:11:11 +0000 Subject: [PATCH 1/2] secondary-storage 4.0 updates add 4.0 content (sourced from https://mail-archive.com/qubes-users@googlegroups.com/msg14871.html) add version headings adjust R3.2 procedure for consistency with rest of document remove "#" from R3.2 procedure because it works as regular user if permissions are set correctly remove "known issues" heading so bullet points fall under R3.2 section instead of appearing to apply to both versions --- configuration/secondary-storage.md | 57 +++++++++++++++++++++++++----- 1 file changed, 48 insertions(+), 9 deletions(-) diff --git a/configuration/secondary-storage.md b/configuration/secondary-storage.md index f04b6665..1bfbfaff 100644 --- a/configuration/secondary-storage.md +++ b/configuration/secondary-storage.md @@ -12,28 +12,67 @@ 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. In dom0: +HDD. You want to store a subset of your AppVMs on the HDD. -1. `# mv /var/lib/qubes/appvms/my-new-appvm -/path/to/secondary/drive/my-new-appvm` +### R4.0 ### -2. `# ln -s /path/to/secondary/drive/my-new-appvm /var/lib/qubes/appvms/` +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: + + 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 + +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: + + 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. +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. + +### R3.2 ### + +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). -Known Issues ------------- - * 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]] - * This issue applies only to R3.1, not R3.2 or later: - After implementing the above procedure, starting `my-new-appvm` will cause + * 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 From 01dee1b2a833c5212134ad281716fe70194a5d4e Mon Sep 17 00:00:00 2001 From: awokd <34515595+awokd@users.noreply.github.com> Date: Mon, 5 Feb 2018 15:48:44 +0000 Subject: [PATCH 2/2] fix line breaks --- configuration/secondary-storage.md | 46 +++++++++++------------------- 1 file changed, 17 insertions(+), 29 deletions(-) diff --git a/configuration/secondary-storage.md b/configuration/secondary-storage.md index 1bfbfaff..76c455b5 100644 --- a/configuration/secondary-storage.md +++ b/configuration/secondary-storage.md @@ -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/