Add preload disposable setting to global config

[ben-grande]

For: QubesOS/qubes-issues#1512

[ben-grande]

The current behavior of preloaded disposables when changing default_dispvm needs to be defined.

1. Do not mess with the old default_dispvm preload-dispvm-max feature and set the new default_dispvm feature to the same as per the old one.
2. Set old default_dispvm preload-dispvm-max feature to 0 and set the new default_dispvm feature to the same as per the old one.
   1. Marek recommended a dom0 feature default-dispvm-preload-max. I'd say that such feature must take precedence over the disposable template feature for the GUI to behave as expected by the user.

I am concerned option 1 as a user that only uses Global Config and not Qube Settings will have lingering qubes.

Option 2 seems more sane, but I don't like the last part of my proposition:

set the new default_dispvm feature to the same as per the old one

I prefer the current behavior, which is, when toggling between disposable templates, it fetches the current feature value so you can see it updating at runtime. If we consider that the selected disposable template that is being set already has preload-dispvm-max set to a number different than the default_dispvm feature, we would be modifying the value set by the user elsewhere (vm settings, qvm-features or API) to the value received from the default_dispvm, I don't think this part makes sense.

And after writing what the new value should behave like, makes me think that the old value should not be changed to 0, because the user may have set the value elsewhere.

Then, I think the default-disvpm-preload-max dom0 feature makes sense, it would avoid this problems. With this feature, I'd say that the best behavior would be:

1. If the disposable template is the default_dispvm, than it must respect default-disvpm-preload-max.
2. When changing default_dispvm:
   1. The old default_dispvm will have the preload event start triggered to adapt to only having the feature preload-dispvm-max
   2. The new default_dispvm will have the value the user sets for it at runtime without depending on the old default_dispvm feature value.

Or I make fetching current value code less dynamic from the current disposable template selected and enforce that it only reads and set the dom0 feature default-dispvm-preload-max.

I guess it will be easier to grasp the advantages and disadvantages when coding. Any takes?

[codecov]

Codecov Report

❌ Patch coverage is 98.71795% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.99%. Comparing base (3a85bee) to head (26cdf14).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
qubes_config/global_config/basics_handler.py	97.18%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #262      +/-   ##
==========================================
- Coverage   92.99%   92.99%   -0.01%     
==========================================
  Files          64       64              
  Lines       13034    13217     +183     
==========================================
+ Hits        12121    12291     +170     
- Misses        913      926      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[marmarta]

I don't love the sentence "This removes fresh disposable qube startup time at the cost of increased memory usage"; I think that we do not use the "fresh disposable qube startup time" anywhere in the docs, so it might be somewhat confusing. "This speeds up disposable qube startup at the cost of memory."?

[ben-grande]

"This speeds up disposable qube startup at the cost of memory."?

But it doesn't speed up startup time, the startup time remains the same. What it does, when requested, on the best case scenario (requesting after preload procedures have completed), is that it skips startup time.

Changed it to:

Reduces disposable qube use waiting time at the cost of increased memory usage.

What do you think? Used a similar phrase from the manual: https://github.com/QubesOS/qubes-core-admin-client/blob/68b2b3250c87ee18ed0e28b1b8e208e501d0faa9/doc/manpages/qvm-features.rst?plain=1#L450

[andrewdavidwong]

How about something like, "Queues disposables in the background so they're available immediately, but each one uses memory."

[ben-grande]

What do you think:

Maximum number of disposable qubes (based on default disposable template) to queue in the background so they are available immediately, but each one reserves memory. This setting takes precedence over the default disposable template's individual settings.

[andrewdavidwong]

Suggested rewording:

The maximum number of disposable qubes to queue in the background. Preloaded disposables start instantly, but each one uses memory while queued. Preloaded disposables are always based on the default disposable template. This setting takes precedence over the default disposable template's preload setting.

If you need to make it shorter, I suggest dropping the last 1-2 sentences or moving them into a nearby "?" or "i" icon tooltip.

[ben-grande]

Current text:

Maximum number of disposable qubes (based on default disposable template) to queue in the background so they are available immediately, but each one reserves memory. This setting takes precedence over the default disposable template's preload setting.

[andrewdavidwong]

IMHO, the first sentence is awkward, because the clause after the "but" doesn't contrast with the entire clause before the "but." Also, "Maximum number of disposable qubes (based on default disposable template)" is ambiguous, since it could be interpreted to mean that the maximum number is somehow based on the default disposable template.

[ben-grande]

What do you think:

Maximum number of disposable qubes (created from the default disposable template) to queue in the background. They are available immediately, but each one reserves memory. This setting takes precedence over the default disposable template's preload setting.

[andrewdavidwong]

Sounds good 👍

[marmarta]

But from user POV this is startup time: time between "I asked for a dispvm" and "I've received a dispvm".

[marmarek]

When you enable preload, can you make the default to "1"? To save one click when enabling the feature.

[marmarek]

Hm, but this will change explicit 0 into 1, no?

[ben-grande]

Yes, I see how it is wrong now...

…

On Wed, Jul 23, 2025, 11:35 PM Marek Marczykowski-Górecki < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In qubes_config/global_config/basics_handler.py <#262 (comment)> : > + ) + + def on_defdispvm_changed(self): + defdispvm = self.defdispvm_model.get_selected() + if defdispvm: + self.preload_dispvm_check.set_sensitive(True) + self.preload_dispvm_check.set_active(self.get_feat_value() is not None) + else: + self.preload_dispvm_check.set_sensitive(False) + self.preload_dispvm_check.set_active(False) + + def on_check_changed(self, *args): # pylint: disable=unused-argument + defdispvm = self.defdispvm_model.get_selected() + preloadcheck = self.preload_dispvm_check.get_active() + if defdispvm and preloadcheck: + self.preload_dispvm_spin.set_value(self.get_current_value() or 1) Hm, but this will change explicit 0 into 1, no? — Reply to this email directly, view it on GitHub <#262 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCE2O4O2TXXSWBJQZYCXE2T3J75Z3AVCNFSM6AAAAAB5WNPV52VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTANBZGEZDMMZVGU> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[ben-grande]

PipelineRetryFailed

[ben-grande]

PipelineRetryFailed

[ben-grande]

PipelineRetryFailed

[ben-grande]

Finally :) !