VM "last started" date

[andrewdavidwong]

Similar to the "last backup" column in Qubes Manager, allow the user to see when a VM was last started (if ever). This would be especially useful when trying to decide whether a VM needs to be included in a backup. (If the "last started" date is the same or earlier than the "last backup" date, then it probably doesn't need to be backed up again.)

[airelemental]

As a workaround, you can get an approximate "last activity" for a VM by looking at the latest mtime of its associated log files.

For example:

changed_last_3_days () { [ "$(sudo find /var/log '(' -name "*.$1.log" -o -name "vm-$1.log" -o -name "guest-$1.log" ')' -mtime -3)" ] ; }

changed_last_3_days myvm && <run biweekly backup>

[alimirjamali]

Another approach would be adding a property function to qubes.storage.Volume to return the last date changed of the volume (maybe even per snapshot/revision). Then a property function to QubesVM class to return last modification date of private volume.

Finally using the above helper functions in CLI & GUI tools to show the last started date.

This will need the minimum modifications. One issue would be that the modification date of volume will change on restore action.

[marmarek]

That won't work for named disposables, as those are not really changed when started/stopped.

[alimirjamali]

That won't work for named disposables, as those are not really changed when started/stopped.

Oh, Yes. sys-usb and sys-firewall. Printing unknown or N/A for them is not helpful. People actually need last startup of those.

Directory modification date within /var/lib/qubes/appvms is also updated for the named disposables. This could be mixed with private volume modification extraction. Adding a new feature or a property to start start date directly is also a doable approach and is pretty simple. And using the logs as was suggested earlier.