Implement UI Notifications for cases of a Qube disk full

[bnvk]

Currently, one only realizes that a Qube is full usually after some other operation (downloading, installing) fails. We should surface notifications to users when a Qube is

• 75% full
• 85% full
• 90% full

These should be system notifications that provide an actionable button that takes user to the Qubes Manager for that given Qube.

Additionally, there is the case where the sum total of "potential disk space allowed" for all Qubes, might be greater than that of the actual physical hard drive. In the case that this limit is actually reached @marmarek and @woju claim that all information about a users Qubes is erased. This of course is very bad for users and should be mitigated by not allowing a user to set each Qube to larger than total available space.

[marmarek]

Related to #1053

[marmarek]

Related to #1053

[tasket]

This could be quickly done in 4.0 if its added to @marmarta 's disk space widget, or just made into a cron job or systemd timer.

I'll also suggest expanding this function beyond a warning:

Perhaps pausing domUs if the storage pool (containing admin root) free space goes below a certain number. It could even un-pause automatically once enough space has been freed. I don't know if Linux offers a better way to handle this (i.e. an LVM feature that can reserve space in a pool for a particular LV)... open to suggestions.

[tasket]

This could be quickly done in 4.0 if its added to @marmarta 's disk space widget, or just made into a cron job or systemd timer.

I'll also suggest expanding this function beyond a warning:

Perhaps pausing domUs if the storage pool (containing admin root) free space goes below a certain number. It could even un-pause automatically once enough space has been freed. I don't know if Linux offers a better way to handle this (i.e. an LVM feature that can reserve space in a pool for a particular LV)... open to suggestions.

[marmarek]

I don't know if Linux offers a better way to handle this (i.e. an LVM feature that can reserve space in a pool for a particular LV)... open to suggestions.

This is very similar to what we've discussed in #3226 (comment)

As for pausing qubes, this may be tricky. Imagine someone using USB keyboard, or just yubi key for screen unlock. Pausing sys-usb in that case would be bad...

[marmarek]

I don't know if Linux offers a better way to handle this (i.e. an LVM feature that can reserve space in a pool for a particular LV)... open to suggestions.

This is very similar to what we've discussed in #3226 (comment)

As for pausing qubes, this may be tricky. Imagine someone using USB keyboard, or just yubi key for screen unlock. Pausing sys-usb in that case would be bad...

[tasket]

Probably could make an exception for sys-usb, which isn't expected to command a large private volume anyway.

[tasket]

Probably could make an exception for sys-usb, which isn't expected to command a large private volume anyway.

[tasket]

BTW, was referring to current arrangement with dom0 in thin pool in 3226, not allocating a static dom0 volume.

[tasket]

BTW, was referring to current arrangement with dom0 in thin pool in 3226, not allocating a static dom0 volume.

[tasket]

Note: dom0 has dm-event.service which runs dmeventd. This supposedly monitors thin pools for the amount of space left and will log warnings (and even try to dismount member volumes) at certain percentage thresholds.

Monitoring this log output (via rsyslogd?) may be one way to implement notifications/pausing. But I still think using the widget is a good option, especially since it can be applied uniformly to the other storage types.

[tasket]

Note: dom0 has dm-event.service which runs dmeventd. This supposedly monitors thin pools for the amount of space left and will log warnings (and even try to dismount member volumes) at certain percentage thresholds.

Monitoring this log output (via rsyslogd?) may be one way to implement notifications/pausing. But I still think using the widget is a good option, especially since it can be applied uniformly to the other storage types.

[marmarek]

Notification + widget implemented as part of #3240

Safeguards against filling up pool where dom0 root lives would be much easier to implement in 4.1, where GUI will be moved out - no direct user interaction with dom0, can be much smaller, static volume.

[marmarek]

Notification + widget implemented as part of #3240

Safeguards against filling up pool where dom0 root lives would be much easier to implement in 4.1, where GUI will be moved out - no direct user interaction with dom0, can be much smaller, static volume.