Changing dispVM private storage has no effect

[3hhh]

Qubes OS version:

4.0rc3

Affected TemplateVMs:

only debian 8 was tested

Steps to reproduce the behavior:

1. Start a dispVM (named or unnamed) terminal
2. Check sudo df -h in the dispVM terminal
3. dom0: qubes-vm-settings [dispVM], edit the private storage to something larger and close
4. Check sudo df -h in the dispVM terminal (resize2fs /dev/xvdb doesn't do anything neither)

Expected behavior:

Storage size changes at least until the dispVM is shut down.

Actual behavior:

Storage size doesn't change.

[marmarek]

This is a bit tricky, because technically the same applies to root volume ("system storage") of TemplateBasedVM. Allowing change for DispVM:private would also allow it for TemplateBasedVM:root. And in both cases the change would be discarded (reset to original value) after VM shutdown. The difference is DispVM (in most cases) is removed then, but other VMs stays there. It is consistent with how TemplateBasedVM works - changes to root volume are discarded after VM shutdown. But IMO it still may be confusing.
@andrewdavidwong any advice on this?

Technically, it is easy to change it (allow resize) on LVM, might be impossible for file driver. But I wouldn't care about this case, file driver have limited functionality anyway. It's ok to support only some features in some storage drivers (as long as clearly communicated).

[marmarek]

This is a bit tricky, because technically the same applies to root volume ("system storage") of TemplateBasedVM. Allowing change for DispVM:private would also allow it for TemplateBasedVM:root. And in both cases the change would be discarded (reset to original value) after VM shutdown. The difference is DispVM (in most cases) is removed then, but other VMs stays there. It is consistent with how TemplateBasedVM works - changes to root volume are discarded after VM shutdown. But IMO it still may be confusing.
@andrewdavidwong any advice on this?

Technically, it is easy to change it (allow resize) on LVM, might be impossible for file driver. But I wouldn't care about this case, file driver have limited functionality anyway. It's ok to support only some features in some storage drivers (as long as clearly communicated).

[andrewdavidwong]

This is a bit tricky, because technically the same applies to root volume ("system storage") of TemplateBasedVM. Allowing change for DispVM:private would also allow it for TemplateBasedVM:root. And in both cases the change would be discarded (reset to original value) after VM shutdown. The difference is DispVM (in most cases) is removed then, but other VMs stays there. It is consistent with how TemplateBasedVM works - changes to root volume are discarded after VM shutdown. But IMO it still may be confusing.
@andrewdavidwong any advice on this?

In 3.2, there's no need to change the volume size (user or root) of a DispVM (i.e. home directory storage in the DispVM is not limited to the DVM Template's max private storage size anyway), so this only becomes an issue in 4.x, right?

I think the proposed change would be fine. For most users, what matters is whether changes persist across VM restarts. For TemplateBasedVMs, root volume changes don't persist. For DispVMs, nothing persists. The proposed change would maintain that distinction, which is all most users care about. The users who might actually care that non-persistent TemplateBasedVM root volume size changes are possible are likely to be more advanced users trying to do special things, and we can point them to documentation that explains this.

[andrewdavidwong]

This is a bit tricky, because technically the same applies to root volume ("system storage") of TemplateBasedVM. Allowing change for DispVM:private would also allow it for TemplateBasedVM:root. And in both cases the change would be discarded (reset to original value) after VM shutdown. The difference is DispVM (in most cases) is removed then, but other VMs stays there. It is consistent with how TemplateBasedVM works - changes to root volume are discarded after VM shutdown. But IMO it still may be confusing.
@andrewdavidwong any advice on this?

In 3.2, there's no need to change the volume size (user or root) of a DispVM (i.e. home directory storage in the DispVM is not limited to the DVM Template's max private storage size anyway), so this only becomes an issue in 4.x, right?

I think the proposed change would be fine. For most users, what matters is whether changes persist across VM restarts. For TemplateBasedVMs, root volume changes don't persist. For DispVMs, nothing persists. The proposed change would maintain that distinction, which is all most users care about. The users who might actually care that non-persistent TemplateBasedVM root volume size changes are possible are likely to be more advanced users trying to do special things, and we can point them to documentation that explains this.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.24-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.24-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.24-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.24-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update