Error attempting to increase private storage max size

necker · January 11, 2022, 12:28pm

First I was getting “not enough disk space” errors on one of my VMs when attempting to copy files into the VM. However the VM has plenty of allocated private space. It’s also a disposable VM and rebooting clears the home directory, but I still get the disk full error when attempting to copy files to the VM. So I attempt to increase the private storage max size of the VM and I now get the error:

ERROR: Basic tab
Logical volume vm-<VM-name>-private-snap not found in volume group qubes_dom0

The private storage max size value reverts to the previous setting when I click okay to close the error window.

Any thoughts?

necker · January 11, 2022, 12:40pm

The VM in question is a named disposable. If I create another named disposable using the same disposable VM template, the new VM also throws the same error when attempting to increase the size of the private storage max size. If I create a standard VM based on the main template that was used to create the disposable VM template, I can increase the private storage max size without a problem.

rustybird · January 11, 2022, 2:41pm

github.com/QubesOS/qubes-issues

Private volume size for sys-usb and sys-firewall cannot be modified in R4.1 via UI - attempt leads to unexpected error popup.

opened 08:01PM - 01 Jan 22 UTC

brendanhoar

T: bug C: core C: manager/widget P: default needs diagnosis

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release R4.1rc2 updated to R4.1rc3 (w/ current-testing updates) ### Brief summary Private volume size for sys-usb and sys-firewall cannot be modified in R4.1 via UI due to an unexpected error popup. Presumably an unexpected side effect of being a Named Disposable? While I am unsure I would ever need to modify sys-usb private volume (others might?), in the past, I have found increasing the private volume for sys-firewall has been helpful if/when dom0 has a large update change set coming. Perhaps the need for this is mitigated due to the qvm-templates tool enforcing one template at a time, but I think this is still an unexpected result. ### Steps to reproduce For sys-firewall, open Qubes Settings You will be on the Basic tab Navigate to Private storage max size, which defaults to 2.0GB. Change value to 4.0GB. Click OK. Repeat for sys-usb. ### Expected behavior No error and instances of sys-firewall have 4.0GB available on private volume. ### Actual behavior Error message dialog. - Title: [Dom0] Error while changing settings for sys-firewall - Message: ERROR: Basic tab: \n Logical volume vm-sys-firewall-private-snap not found in volume group qubes_dom0. Presumably this is due to default configuration of sys-firewall and sys-usb as Named Disposable? Thanks, Brendan

necker · January 12, 2022, 4:12am

Thanks for the link. I got it working. I actually tried to increase the private storage max size on the DVM template yesterday but got the same error. At the time, it didn’t seem relevant to alter the template storage size because I had previously raised the disp VM storage size to 20GB while the DVM template was still set to 2GB and it worked fine for a month or longer.

After a complete system reboot, I was able to resize the template storage. I might have had the disp VM running when I tried to modify the DVM template yesterday. Can’t remember

After I increased the DVM template private storage, I was able to copy several very large files to the disp VM. I was also able to increase the private storage of the disp VM. Interestingly, when I finally raised the storage value of the dispVM, I got a new error saying that the value I entered was lower than the space that was already allotted (even though I was increasing the displayed value in the settings GUI). Perhaps previous attempts to increase the size worked but it just didn’t confirm the setting in the GUI? Or maybe increasing the DVM template storage size somehow gave the dispVM more space without reflecting the change in the GUI?

I’m still a bit confused but it’s working so I’m not complaining.

Thank you again @rustybird!