Some binary prefs like disable_updates came be added to qubes to manage this feature. Looks useful as some qubes (offline) with fixed version of software can indeed be expected not to be updated.

I wonder if this is what the updateable preference is for. The docs don't clarify much about the intended purpose:

updateable
True if this machine may be updated on its own.

However it cannot be changed by the user. I wonder what the reasoning is (maybe footshooting prevention).

[user@dom0 ~]$ qvm-prefs fedora-39-xfce updateable False
qvm-prefs: error: property 'updateable' on TemplateVM instance cannot be set

Ok. This issue is relatively easy to solve. I am going to work on this. The design is going to be like this:

• A new boolean feature named skip-update (or similar) could be allocated for this (reusing the updateable pref is not recommended since the Template might be indeed updateable but user wants to skip updating it temporary).
• vmupdate library should be updated to honour the above feature.
• GKT tools (The GUI Updater & Qubes Update systray widget) should be updated to honour the above feature.
• Qt GUI tools (Qube Manager) should be updated to honour the above feature.

Overall it is very simple. But more than one PR will be necessary.

p.s.: Since this will be an advanced feature and niche area which is most probably not used by most users, I believe it is better to avoid adding it to qubes-vm-settings dialog. Advanced users could use the CLI to change the feature.

Nice! Happy to see some momentum on this.

A new boolean feature named skip-update (or similar)

Meta question: should this be a feature or a preference? updatable is a preference and not a feature.

I often confused both, but in my head qube preferences are well defined whereas as features are more open-ended. In particular (especially if something that exists natively -- like this case), with preferences one can list / discover all available by running qvm-prefs [vmname] --help-properties. Otherwise users will have to happen to come across this option in the docs somewhere.

Anyways, just my two cents. I may be wrong on the distinction, though.

Meta question: should this be a feature or a preference? updatable is a preference and not a feature.

This is a very good question :) We don't have any guidelines for this, and we don't use it consistently really (*)...
The updatable property is really a read-only property more or less meaning if root volume is persistent ("does it make sense to install updates there"). And this too may be misleading when the updating mechanism will support flatpaks installed in the user home in the future.
The properties and features can have a bit different set of behaviors:

• properties:
  • can be listed in qvm-prefs
  • can have custom setter that validates the value, and possibly transform it
  • can have an arbitrary mechanics for default value (like calculated based on other properties, different for different qube type etc)
  • properties are cached, and needs to handle cache invalidation properly (especially tricky for default value that is calculated based on other properties)
• features:
  • just simple key+value, usually value is just boolean (empty for false, "1" for true)
  • few predefined inheritance methods (take default from template, from netvm, from guivm)
  • default value is "feature not set", up for its user to define what that means
  • no validation on setting, no detection for typos in the feature name etc

Generally, properties are smarter. But due to its stricter nature, and potentially smarter behavior, need more care when implementing. This also means committing to its support in the future, converting on upgrades, while restoring old backups in the future etc. More or less it means you cannot really remove it in the future - at least some migration code needs to stay forever.

There was a plan to make features a bit smarter, especially around their documentation and value validation (basically have an API that allows adding extra metadata to some feature names). But that mechanism never materialized and the only thing we have is the qvm-features man page.

In this particular case, I think it's okay to go with a feature, especially since updates-available is a feature already and is yet another factor for selecting what to update. But if you'd prefer to make it a property, I would be okay with that too.

(*) one one hand backup_timestamp or keyboard_layout are properties, which aren't really part of core mechanism, but on the other hand, memory-hotplug, video-model or uefi are features but their implementation is deeply integrated into core-admin component.

That makes sense. Thanks a lot for the clarification. Feature it is :)

In the last few hours, I considered patching qubes-core-admin directly to honour the skip-update feature while updating updates-available feature. Theoretically this should allow patching everything in one place instead of patching 3 individual repositories.

Finally I decided to revert back to the original plan.

The PRs (total of 3) for this issue are ready for review.

Review priority: low

1. qubes-vm-update is patched to ignore VMs with skip-update feature. User could still target them and force update on them with --targets option.
2. Qubes Manager will show a warning sign+tooltip message for TemplateVMs and StandaloneVMs with skip-update feature. Just as a reminded that this is potentially a dangerous and advanced feature.
3. Qubes Update systray widget will not show notifications for TemplateVMs and StandaloneVMs with skip-update feature. Neither for outdated nor for EOL with the mentioned feature.
4. By default, Qubes OS Update GUI will not show VMs with skip-update feature. User could change this behaviour with --show-advanced-settings and change it in settings page. I also added an additional option to hide already updated and not stalled VMs from VM selection page.

Video demo:

I'm reviewing the PRs and I wonder if 4. is not too many layers of hiding - I feel like showing advanced settings (while marking them as advanced) by default is not a bad idea? It still requires CLI command to actually set on a VM, right?

I'm reviewing the PRs and I wonder if 4. is not too many layers of hiding - I feel like showing advanced settings (while marking them as advanced) by default is not a bad idea? It still requires CLI command to actually set on a VM, right?

We discussed this on forum. We were/are afraid if novice users might use this potentially dangerous feature and end up with many outdated templates. But reconsidering it, maybe it is not that bad. I will remove --show-advanced-settings option and always show the advanced options.