Add an option to use private volume directly, not via a snapshot

[marmarek]

How to file a helpful issue

The problem you're addressing (if any)

Currently starting any AppVM will create a snapshot of a private volume. This snapshot is used for many features, including:

• making a backup when VM is running
• starting DispVM out of AppVM that is still running
• cloning of a running AppVM

But on the other hand, it takes space, which may be significant when AppVM is changing a lot of data. And also, its copy-on-write nature does affect performance.

The solution you'd like

An option to disable making a snapshot on AppVM start, so the single private volume is connected to an AppVM directly. This will need to disable features listed above for such AppVM (or have some other approach for them).
Depending on final design and interaction with other features, it may be even considered a default for some AppVMs (like "personal" or "untrusted").

The value to a user, and who that user might be

Reduced disk usage, easier disk usage monitoring. And possibly slightly better disk performance.

Completion criteria checklist

• add the volume property (disable-snapshot ? ), applicable only to volumes with snap_on_start=False (a bit counter-intuitive...) and save_on_stop=True
• adjust volume startup code to not create the snapshot and attach the volume directly - do this for all in-tree storage pool implementations
• ensure the incompatible features (listed above) are blocked if the property is set
• disallow setting the property if the VM is running or if any conflicting feature is in use
• disallow starting a VM that has a volume with disable-snapshot=True and is a "source" for some other volume (for example: if DispVM's private volume has disable-snapshot=True, it shouldn't be possible to start related disposable template when any DispVM based on it is running)
• disallow starting a VM that has a volume with source.disable-snapshot=True and that source volume is running (symmetric case to the point above)
• alternative to the two points above: forbid using disable-snapshot feature for volumes that are source for any other
• make it configurable using qvm-volume tool (add relevant Admin API parts)
• add unit tests for all the cases listed here
• document in qvm-volume man page (for users)
• document in qubes-doc (for users)
• document in core-admin/doc/qubes-storage.rst (for developers)

[marmarek]

@DemiMarie to answer your question from another issue, you are talking more or less about #1239. So, yes, that could be an option too.

[tasket]

To attain a performance boost on Btrfs & XFS, I think the reflink driver should set the +C attribute on affected img files as needed.

Also, you may want to consider making disable-snapshot a pool-level feature (instead of per-volume) if consistency of volume handling is a desired. Or implement it for both. Having this setting at the pool level allows an administrator to prevent unwanted snapshot behavior even when new volumes are created in the pool.

[marmarek]

Also, you may want to consider making disable-snapshot a pool-level feature

Won't that impact qvm-clone operation?

[tasket]

Yes it would prevent quick cloning. But this wouldn't be something that a user casually disables.