v2.4.2 — a login refused for lack of a role says so; an unreadable host is not called unreachable (2026-10-19)

Needs vmware-monitor 2.4.2 (now the floor). Found on a vCenter 8.0.3 lab with two restricted SSO accounts
(follow-up to AIops#47).

• A login vCenter refuses with NoPermission gets the role error, not the raw fault. For an account with no
  permission anywhere, vCenter refuses the login itself (System.View on the root folder), so the post-login
  no-role check never ran and doctor and every tool showed the raw fault with a connectivity hint. It now raises
  the no-role error: the "no vSphere role / Global Permissions" remedy only for a vCenter target and System.View;
  an ESXi target or another privilege gets a neutral text naming the (sanitized) privilege. A wrong password
  (InvalidLogin) is unchanged. Same text as vmware-monitor.
• vmk tools and cluster info no longer call an unreadable host unreachable. When the account cannot read a
  host's connection state, list_host_vmks rows and the vmk write tools' refusal say the account cannot read the
  host (reachable: false means "not read"), instead of advising a reconnect. cluster info colours the state
  yellow, not red.
• From vmware-monitor 2.4.2 (through get_cluster_health_summary / get_cross_vcenter_attention): a host this
  account cannot read is counted hosts_unreadable with a warning issue host_unreadable, not ranked as a
  critical host_down.

Unreleased — follow-ups to the 2.4.1 review

• Previews show policy refusals. restore_vm_clean_slate, provision_vm_guest and
  run_vm_guest_command_with_output were refused by rules.yaml only at confirm=True; the preview now lists that
  refusal in blast_radius.blockers, so the user sees it before agreeing.
• A delete that powers the VM off first is checked as power_off_vm too: the CLI vm delete, the TTL daemon,
  and a plan rollback deleting the VM it created (checked when the VM is running or its state cannot be read). The
  TTL daemon records one delete_vm row per change of outcome, as for a deny on delete_vm, and keeps the entry.
  Behaviour change for custom network roles: a role that allows set_vm_ttl must also allow power_off_vm.
• Image cache: writes take a lock across processes (a CLI and an MCP scan at the same time lost one side's
  rows); a scan keeps rows on datastores it failed to browse (its own or legacy ones) and drops this target's rows
  on datastores that no longer exist. A cache that cannot be written no longer fails the scan: the images come back
  with a cache_note, as in vmware-storage.
• Each call is checked for what it will do, at the moment it does it. restore_vm_clean_slate asks about
  power_off_vm only when it actually powers the VM off; provision_vm_guest asks about the guest tools its step
  types use (an exec-only provision is not refused by a deny on upload_vm_guest_file); a plan rollback asks about
  the power-off after confirming it is the VM the plan created, just before powering it off.
• set_vm_ttl is checked as the deletion it schedules: the preview lists a deny on delete_vm (and on
  power_off_vm for a running VM), and confirm=True refuses it, instead of scheduling a TTL the daemon can never
  act on. The daemon still asks again at expiry.
• migrate_vm previews run vCenter's own vMotion compatibility check (CheckMigrate_Task, read-only): its
  errors (CPU features, devices, networks, datastores) become blockers, with the CPU-feature remedy where it applies,
  so a move vCenter would refuse is refused in the preview and before the CLI asks for confirmation; warnings are
  shown and do not block. On a standalone ESXi host, or when the check cannot run, the preview says "not checked"
  and does not block (vCenter checks again when the move starts). Plan migrate steps get the same check.
• The TTL store takes the same cross-process lock as the image cache (set_vm_ttl and the daemon run in separate
  processes).