Ticket #5 (closed enhancement: fixed)
Allow to grow the AppVM's private storage?
| Reported by: | joanna | Owned by: | marmarek |
|---|---|---|---|
| Priority: | major | Milestone: | Release 1 Beta 1 |
| Component: | core | Keywords: | |
| Cc: | marmarek@… |
Description
Research options for automatically or semi-automatically handling a situation when a given AppVM needs more storage (private.img) than originally assigned.
Currently if a user wants to extend private storage for an AppVM, the user must do something like this:
cd /var/lib/qubes/appvms/XXX/ mkdir mnt mnt.new mount -o loop,ro private.img mnt truncate -s <new_max_size> private-new.img mkfs.ext4 private-new.img mount -o loop private-new.img mnt.new cp -pr mnt/* mnt.new/ umount mnt mnt.new rm -f private.img mnt mnt.new mv private-new.img private.img
... which is a bit, well, not user-friendly ;)
Change History
comment:1 Changed 11 months ago by joanna
- Priority changed from minor to major
- Milestone changed from Release 1 Beta 1 to Release 1 Beta 2
comment:2 Changed 11 months ago by marmarek
There is easier way:
Dom0 (AppVM _can_ be running):
cd /var/lib/qubes/appvms/XXX/ truncate -s <new_max_size> private.img
if AppVM is running (still in Dom0):
losetup -a # find loop device connected with private.img losetup -c /dev/loopX
in AppVM:
resize2fs /dev/xvdb
Tested :)
This can be easly automated with simple qvm-* tool and/or qubes-manager.
comment:3 Changed 11 months ago by marmarek
- Cc marmarek@… added
- Owner changed from joanna to marmarek
- Status changed from new to accepted
comment:4 Changed 11 months ago by joanna
- Milestone changed from Release 1 Beta 2 to Release 1 Beta 1
comment:5 Changed 11 months ago by marmarek
- Status changed from accepted to closed
- Resolution set to implemented
comment:6 Changed 10 months ago by marmarek
- Status changed from closed to reopened
- Resolution implemented deleted
Wait for resize device in AppVM before resize2fs.
Note: See
TracTickets for help on using
tickets.
