Git-Mirrors/Qubes-Community-Content
1
0
Fork 0
mirror of https://github.com/Qubes-Community/Contents.git synced 2024-12-22 21:59:26 -05:00
Code Issues Packages Projects Releases Wiki Activity

add 3.2 intructions from old doc

Browse Source
This commit is contained in:
taradiddles 2018-06-17 15:58:31 +03:00
parent 58f6b026c6
commit cf6b04f4b6
1 changed files with 57 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
_tmp/issue-37.md
View File

@ -1,18 +1,20 @@
Shrinking volumes under Qubes 4.0
=================================
Shrinking volumes of Linux VMs
==============================
The [official documentation](https://www.qubes-os.org/doc/resize-disk-image/#shrinking-a-disk-image) describes a safe(ish) way of "shrinking" a VM's volume. This is the recommended approach of shrinking an AppVM's private volume, but it has two caveats:
The procedure for shrinking a volume on Ext4 and most other filesystems is a bit convoluted because online shrinking isn't supported, and we don't want to process any untrusted data in dom0 for security reasons. **This operation is dangerous and this is why it isn't available in standard Qubes tools. If you have enough disk space, the recommended approach is to create a new VM with a smaller disk and move the data.**
However, the approach above has two caveats:
- it requires copying data, which can take a while
- it is limited to the private volume of VMs based on TemplateVMs
This document describes how to shrink *any* volume.
**ALWAYS BACKUP your data before attempting to shrink a volume.**.
**The instructions given below are error-prone. ALWAYS BACKUP your data before attempting to shrink a volume.**.
Note: Qubes 4.0 uses *thin* LVM storage: only the data present on a volume uses disk space, free space isn't allocated physically. If your only concern is disk space, you may simply be careful with how much data you store in a given volume and avoid having to shrink a volume (use `sudo lvs` in dom0 and compare the `LSize` vs `Data%` fields to find out about real disk usage).
Qubes 4.0 (root and private volumes)
------------------------------------
The procedure for shrinking a volume on Ext4 and most other filesystems is a bit convoluted because they don't support online shrinking, and we don't want to process any untrusted data in dom0.
Qubes 4.0 uses *thin* LVM storage: only the data present on a volume uses disk space, free space isn't allocated physically. If your only concern is disk space, you may simply be careful with how much data you store in a given volume and avoid having to shrink a volume (use `sudo lvs` in dom0 and compare the `LSize` vs `Data%` fields to find out about real disk usage).
The instructions below show how to resize a VM's private volume. For root volumes, swap the `-private` volume suffix with `-root`.
@ -43,3 +45,51 @@ The instructions below show how to resize a VM's private volume. For root volume
The procedure is the same for other OSes (eg. MS Windows) but you'll have to use OS specific tools to resize the volume at step 4. and to be careful to specify the right shrinked size at step 6.
Qubes 3.2 (private image)
-------------------------
First you need to start VM without `/rw` mounted. One possibility is to interrupt its normal startup by adding the `rd.break` kernel option:
~~~
qvm-prefs -s <vm-name> kernelopts rd.break
qvm-start --no-guid <vm-name>
~~~
And wait for qrexec connect timeout (or simply press Ctrl-C). Then you can connect to VM console and shrink the filesystem:
~~~
sudo xl console <vm-name>
# you should get dracut emergency shell here
mount --bind /dev /sysroot/dev
chroot /sysroot
mount /proc
e2fsck -f /dev/xvdb
resize2fs /dev/xvdb <new-desired-size>
umount /proc
exit
umount /sysroot/dev
poweroff
~~~
Now you can resize the image:
~~~
truncate -s <new-desired-size> /var/lib/qubes/appvms/<vm-name>/private.img
~~~
**It is critical to use the same (or bigger for some safety margin) size in truncate call compared to resize2fs call. Otherwise you will lose your data!** Then reset kernel options back to default:
~~~
qvm-prefs -s <vm-name> kernelopts default
~~~
Done.
In order to avoid errors, you might want to first reduce the filesystem to a smaller size than desired (say 3G), then truncate the image to the target size (for example 4G), and lastly grow the filesystem to the target size. In order to do this, after the `truncate` step, start the vm again in maintenance mode and use the following command to extend the filesystem to the correct size:
~~~
resize2fs /dev/xvdb
~~~
With no argument, `resize2fs` grows the filesystem to match the underlying block device (the .img file you just shrunk).