Skip to content

feat: Performance - load host data in the background and stop reporting failed pre-checks - #179

Merged
MickLesk merged 6 commits into
mainfrom
perf/faster-start
Oct 29, 2026
Merged

feat: Performance - load host data in the background and stop reporting failed pre-checks#179
MickLesk merged 6 commits into
mainfrom
perf/faster-start

Conversation

@MickLesk

@MickLesk MickLesk commented Oct 29, 2026

Copy link
Copy Markdown
Member

✍️ Description

  • core/build.func starts pveversion, pvesm status (all/vztmpl/rootdir), pveam available, pvesh nextid and pvecm status in the background before the engine download; variables adds the pve-container OS check
  • Checks, settings and storage dialogs read them via _cs_probe_read / _cs_probe_rc / _pvesm_status, fall back to the live command, and _cs_probe_drop discards stale data after pvesm set / pveam update
  • Container ID checks use /etc/pve/nodes/*/{lxc,qemu-server} instead of pvesh /cluster/resources (~1 s per ID tried)
  • Telemetry no longer starts pveversion for every send (LXC and VM)
  • Failed pre-checks send no telemetry; tools/add-ons skip "requirement not met" codes
  • root_check runs before pve_check (non-root users got "storage.cfg is missing")
  • Advanced suggests the checked container ID and respects var_ctid
  • ensure_log_on_host skips pct pull when no container exists (~2 s on early failures)
  • log_msg / log_section never abort a run

🔗 Related Issue

Fixes #

✅ Prerequisites (X in brackets)

  • Self-review completed – Code follows project standards.
  • Tested thoroughly – Changes work as expected (Proxmox VE and/or Incus, as applicable).
  • No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.
  • API.txt regenerated – If a function signature or behavior changed, API.txt was updated to match.

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any code in this PR, you must confirm compliance below.
Select exactly one option.

  • No AI used – Code was written without AI assistance.
  • AI was used – The output has been reviewed and corrected, and I take responsibility for it matching this repo's conventions.

🛠️ Type of Change (X in brackets)

  • 🐞 Bug fix – Resolves an issue without breaking functionality.
  • ✨ New feature – Adds new, non-breaking functionality.
  • 💥 Breaking change – Alters existing behavior in a way that may require updates in every downstream script.
  • 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
  • 📝 Documentation update – Changes to README, docs/, CONTRIBUTING.md, or other docs.

@MickLesk
Run the host checks' probes during load, and report nothing a check s…
f1283c2 
…topped

The checks before the settings menu waited on pveversion, two pvesm status
calls, pvesh and, on clusters, pvecm, one after the other. core/build.func
now starts them in the background before it downloads the engine; the checks
read the results through _cs_probe_read and run a command themselves only
when its probe failed or never ran. The storage check trusts a probe's yes
and asks a no again live.

Telemetry starts with the install record the build sends. A run that ends
before it, in the checks or a dialog, reports nothing: a host that is not
ready is not a failed install, and these runs made up a third of the failures
since 27 October. Tools and add-ons have no such point, so their
"requirement not met" codes send nothing either.

root_check now runs before pve_check. As another user /etc/pve/storage.cfg
is unreadable, and the cluster check reported a damaged cluster. log_msg and
log_section no longer end a run when the log cannot be written.
@MickLesk
Answer storage, catalog and ID questions from the load-time probes
a0c9f15 
From the menu to the storage dialog a default install waited about eight
seconds on Perl: pvesh /cluster/resources once per ID tried, pveversion
once per telemetry send, pvesm status before every storage decision, and
pveam for the template catalog.

The probes started at load now also take pvesm status and pveam available.
check_storage_support, the storage dialogs, the preselect and space checks
and the content checks after the dialog read them through _pvesm_status;
_offer_storage_content drops them when it changes a storage.

validate_container_id and the late ID check look for the guest config under
/etc/pve/nodes, which pmxcfs keeps for every node; pvesh is the fallback
without it. telemetry_collect_sysinfo takes the cached version, since every
payload is built in a subshell and its own cache never reached the caller.
variables no longer asks for the version before the menu.
@MickLesk
Offer the checked container ID in the advanced settings
79ed6c5 
base_settings already found a free ID before advanced_settings runs. The
dialog offered NEXTID instead, which a leftover disk can hold, and then
answered its own suggestion with 'ID already in use'.
@MickLesk
Keep the VM path from starting pveversion and qm per telemetry send
d6f5589 
The VM engine has no _pve_version, so every telemetry payload, built in a
subshell, started pveversion again; pve_check now keeps the version it read
and telemetry_collect_sysinfo uses it. cleanup asked qm config whether the
VM exists; its config file says the same.
@MickLesk
Start the probes with one fork, ask the OS check early, skip pulls fr…
ebd7ff5 
…om no container

The probes forked six times from the script's own shell before the engine
download; on the arm64 host that held the download back by a fifth of a
second. One subshell now starts them.

lxc_os_support_check asks pve-container through Perl whether it can set up
the release, between "Creating" and the storage dialog. variables() knows
the release and starts that question as a probe; a release changed in the
advanced settings is asked live.

ensure_log_on_host pulled the install log and the error capture from the
container after every failure, including those before pct create, where
each pull waited for its timeout to find no container.
@MickLesk
Describe the load-time probes and who reads them
72eaddb
@github-actions

github-actions Bot commented Oct 29, 2026

Copy link
Copy Markdown
Contributor

Try this branch

The engine and the scripts resolve independently, so a production script can
be run against the engine from this PR by setting one variable:

COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/community-scripts/core/perf/faster-start \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/debian.sh)"

Swap ct/debian.sh for whatever exercises the change.

This PR touches pve/, so it needs a Proxmox VE host.

Run a script from a fork as well 
curl -fsSL https://raw.githubusercontent.com/community-scripts/core/perf/faster-start/tools/run.sh |
  bash -s -- https://raw.githubusercontent.com/YOU/DevScripts/your-branch ct/debian.sh \
             https://raw.githubusercontent.com/community-scripts/core/perf/faster-start

Note that run.sh is reached through a pipe, so the script it starts inherits
an exhausted stdin. Whiptail is fine — it opens /dev/tty — but a plain read
would see EOF. The single-variable form above does not have that problem.

Useful flags while testing

dev_mode=net logs every engine fetch with status and duration, which is the
quickest way to confirm the branch is really being used. dev_mode=keep stops a
failed build from deleting the container along with the evidence.

@MickLesk MickLesk changed the title Load host data in the background and stop reporting failed pre-checks feat: Performance - load host data in the background and stop reporting failed pre-checks Oct 29, 2026
@MickLesk
MickLesk merged commit 3c1ef2a into main Oct 29, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@MickLesk