The clue is in your own observation: re-enabling the disabled manual job made all VMs appear. The Backup Restore (V5) view likely filters its restore list based on which backup jobs are currently enabled, if a job is disabled, its associated VMs may not be indexed into the restore view even if backups from that job exist on the remote.

This is different from how the older restore view worked, where it would scan the remote and show everything regardless of job state. The V5 restore view appears to be building its list from job metadata rather than from a direct remote scan.

A few things worth verifying:

Check whether the one VM that does appear is covered by a currently-enabled job, and the others are only covered by disabled jobs. If that pattern holds consistently, that's the root cause and it's a V5 behavior change worth reporting to the XO team. In the XO UI, go to Backup → Jobs and check which jobs are enabled. If you temporarily enable all jobs, does the restore list show all VMs? And when you disable some again, does it immediately drop those VMs from the list?

If the behavior is confirmed, filing it against the backup v5 restore view filter logic would be useful, the restore UI should show all VMs that have restorable backups on the remote, regardless of whether the originating job is currently active or not.

Given you're on a test branch focused on reactivity fixes, this could also be a rendering/state issue where the component isn't re-fetching when job state changes, the list gets built once and doesn't update until you navigate away and back.

To add a bit more detail on the upgrade path: strictly speaking, you do not need to apply outstanding 8.2 patches before upgrading. When you upgrade to 8.3, you are replacing the entire base system with the 8.3 release which already incorporates everything from the 8.2 patch stream. Any 8.2 patches you hadn't yet applied will simply be superseded.

That said, applying them first is still a reasonable approach if you want a clean upgrade history and a fully-patched 8.2 baseline before jumping to 8.3.

A few things worth checking before you start on a production pool:

Check VM compatibility. Run a quick review of your VMs for any that might have specific OS or toolstack dependencies tied to 8.2. Most guests upgrade cleanly but it is worth knowing your environment.

Use rolling pool upgrade if you have more than one host. XCP-ng supports rolling upgrades: you migrate VMs off each host, upgrade it, rejoin the pool, then proceed to the next. This maintains VM availability throughout the process. The XO interface handles this workflow if you have XOA.

Back up before the jump. Export critical VM configurations or snapshots beforehand. If you use Xen Orchestra for backups, trigger a manual full backup job before starting.

The upgrade itself via yum is straightforward: add the 8.3 repo, yum update, reboot. The toolstack and XAPI will handle pool registration after the host comes back up.

After upgrading all hosts, run the post-upgrade checks from the docs (pool metadata sync, storage rescans) and verify HA is healthy if you use it.