A host with the VM service off is not a host with a broken API key

The API answered and simply had no vms node, but that was recorded as an API fallback, and the monitor reads any fallback with a key present as 'Unraid API unreachable — check API key in host conf.'

Plugin/unraid/include/vms.php

@@ -52,7 +52,20 @@ function vv_get_vms(): array {
         return ['available' => true, 'vms' => $vms];
     }
 
+    // ── VM service off is not an API failure ──────────────────────────────────
+    // The API answered — there is simply no vms node in the reply, which is what a host with
+    // the VM service disabled returns. Recording a fallback here put 'vms' on the API-status
+    // list, and the monitor banner reads any non-empty list with a key present as
+    // "⚠ Unraid API unreachable — using local reads. Check API key in host conf." So a healthy
+    // host with VMs switched off accused its own API key of being broken, and the only clue to
+    // the contrary was the quiet "(vms)" after the message.
+    //
+    // Falling through to virsh would be wrong too: libvirt is not running, so it can only fail,
+    // and the header of this file already says the absence of VMs is the expected state.
+    if ($api !== null) return ['available' => false, 'vms' => []];
+
     // ── Local fallback ────────────────────────────────────────────────────────
+    // Reached only when the API itself gave us nothing, which IS worth reporting.
     vv_api_record_fallback('vms');
 
     if (!file_exists('/usr/bin/virsh')) return ['available' => false, 'vms' => []];