> ## Documentation Index > Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL. > Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other. > Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking. > Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify. # Node Details > Use the node detail page to inspect status, workloads, adapters, storage, configuration, and lifecycle actions. Open a node from **Infrastructure > Fleet > Nodes** to inspect and operate it. The detail page is the main workspace for node-level troubleshooting, configuration, and lifecycle decisions. ## Header and Utility Actions The header shows the node display name, current status, application count, and uptime when available. The utility actions include: | Action | Use it to | | - | - | | **Notifications** | View errors, warnings, and notices reported by EVE-OS (Edge Virtualization Engine) for this node. A color-coded badge on the bell icon shows the count and highest severity (red for errors, amber for warnings, blue for notices). For EVE-OS update failures, the panel includes a **Retry** action. When no notifications are present, the panel shows **All clear**. | | **View Events** | Open events filtered to the node. | | **Configuration Status** | Inspect configuration generation, fetch status, differences, and errors. | | **Configure node** | Open the configuration overlay. | | **Remote Console** | Open an SSH terminal to EVE-OS on the node through Edge View. Requires Edge View to be enabled in the project policy. See [Configure Edge View with the GUI](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-view/configure-edge-view-with-gui.md#connect-to-a-node-via-remote-console). | | **More actions** | Open lifecycle actions such as activate, deactivate, reboot, update EVE-OS, prepare power off, off-board, and delete. Also includes **Collect Logs** (download a diagnostic TAR archive from the node) and **Remote Console (VNC)** (open the graphical console of an application instance running on this node, after you choose the instance in a picker). Both require Edge View to be enabled in the project policy. **Troubleshoot** (interactive Edge View CLI console) is not currently available and is hidden in this release. Collect Logs also requires the **Access EVE-OS** permission, while Remote Console (VNC) requires the **Access Edge Applications** permission. Remote Console (VNC) is hidden when the node has no application instances. See [Configure Edge View with the GUI](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-view/configure-edge-view-with-gui.md#use-the-troubleshoot-cli), [Collect Diagnostic Data](https://zededa.mintlify.site/new-ui/infrastructure-services/troubleshooting/collect-diagnostic-data.md#collect-logs), and [Open Remote Console (VNC) From a Node](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-view/configure-edge-view-with-gui.md#open-remote-console-vnc-from-a-node). | The console hides actions your role cannot perform, rather than showing them in a disabled state. If you expect an action but do not see it, verify your role and project access. ## Status Ribbon Below the header, six cells provide an at-a-glance snapshot of the node without opening any tab. | Cell | Primary value | Secondary line | | - | - | - | | **Status** | Run state (for example, Online, Offline, Suspect). | Admin state (for example, Active, Inactive). Admin state reflects the configured lifecycle state, not the device's runtime state. | | **Uptime** | How long the node has been running since last boot. | Boot timestamp. | | **Last seen** | How long ago the node last reported in (relative). | Absolute date and time of last report. | | **Reboot reason** | The reason for the most recent reboot, as reported by EVE-OS. Displays "—" when no reboot has been recorded. | (none) | | **EVE version** | The EVE-OS version currently running on the node. | CPU architecture and image version, or an update status note when an update is in progress. | | **Workloads** | Number of application instances on the node. | Network instance and volume counts. | **Admin state** appears in the ribbon as a secondary indicator under Status. For the full Admin state field with copy controls, see the Details tab under **State & Timeline**. ## Overview Tab Use **Overview** for a fast operational read. It includes workload previews for Applications, Virtual Networks, Volumes, and Patch Envelopes, a recent activity feed, the **Live status** panel, and the **System and Security** panel. ### Live status panel The Live status panel shows real-time data reported by EVE-OS and read-only service settings for the node. It has the following sub-tabs: **Resources**, **NTP info**, **Certificates**, **Edge Sync**, and **Edge View**. The Edge View sub-tab appears only when Edge View is allowed for the node. **Resources** shows current utilization for the node's CPU, memory, and storage, and the ratio of active uplink interfaces to total uplinks. Each metric includes a live value alongside a one-hour sparkline and average so you can distinguish a momentary spike from sustained load. CPU and memory figures show both allocated capacity (reserved for running application instances) and actual usage. A **View Reports** link opens the node on the **Performance** tab of the Reports page for deeper telemetry. See [Reports](https://zededa.mintlify.site/new-ui/infrastructure-services/monitoring-logs-events-reports-jobs.md#reports). **NTP info** lists the NTP sources EVE-OS is using to synchronize the system clock. Each row shows the server address, stratum, mode (Client, Peer, or Reference), state (Sync, Candidate, Unreachable, and others), reachability, offset, and round-trip delay. The source currently disciplining the clock is marked as Sync. If no source is in Sync state, the system clock might drift. **Certificates** lists the certificates enrolled on the node for port-based network access control (802.1X). Each entry shows the subject common name, issuer common name, enrollment profile, status (Active, Pending, Renewing, Expired, Revoked, or Failed), and expiration date. If no certificates are enrolled, the panel notes that port-based NAC is configured at the project level. See [Configure 802.1X with SCEP](https://zededa.mintlify.site/new-ui/infrastructure-services/networks/configure-802-1x-with-scep.md) for enrollment setup. **Edge Sync** is a read-only summary of the node's Edge Synchronization settings. It always appears, whether or not Edge Sync is configured, because knowing that a node has Edge Sync turned off is also useful. It shows the following: * **Local orchestration**: **Enabled** or **Disabled**. The node counts as enabled only when it has an Edge Sync URL set. When it is not set, the sub-tab notes that Edge Sync is not configured for this node. * **Edge Sync URL**: the address of the Edge Sync server this node falls back to. The row shows a dash when no URL is set. * **Data Stores**: the names of the datastores attached to the node's Edge Sync configuration. The row shows **Not Configured** when no datastore is attached. **Edge View** is a read-only summary of the node's Edge View remote access policy. It shows the **Remote access policy** status, the **Access EVE-OS**, the restriction to cloud sessions, **Override Access Policies**, and **Access Edge App Instances** settings (each **Enabled** or **Disabled**), the maximum and default session time and connection limits, and the **Dispatcher URL**. You can copy any value in these sub-tabs. You cannot change the values here. Edit them in **Configure node** (gear icon). Edge Sync settings are under **General Settings > Administration**. These sub-tabs matter most for users whose role grants read access only, because the Configure overlay is hidden from them. See [Configure Edge Synchronization](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/configure-edge-synchronization.md) and [Configure Edge View with the GUI](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-view/configure-edge-view-with-gui.md). A service summary at the bottom of the Live status panel shows **Edge Sync** (**Enabled** or **Disabled**) and, when Edge View is allowed, **Edge View** (**Policy enabled**). Click either item to open its sub-tab. A green dot next to **Edge View** indicates a live Edge View session, meaning a console is currently connected to this node or to an application instance on it. Start here when you need to decide whether the node is healthy enough to run Applications. ### System and Security panel The System and Security panel summarizes the node's security posture. It shows individual signals for attestation, HSM, PCR, virtualization, ECC memory, Configuration Lock, and Edge Sync when the node reports them. Hover over a signal to open a card with more detail. You can collapse the panel when you do not need it. Hovering the **PCR** signal opens a card that lists the node's reported PCR values, along with the EVE-OS (Edge Virtualization Engine) image version and firmware version reported at the last attestation. Select **Copy All** to copy every PCR index and value, or use the copy icon on a row to copy a single value. The footer of the PCR card links to the PCR template for the node's hardware model, in one of two forms: * If the node's reported PCR values already match a template on the hardware model, the footer shows the template name. Select it to open that template on the hardware model. This does not create a new template. * If no template matches and your role can create hardware models, the footer shows **Configure a PCR Template**. Select it to copy the node's reported PCR values into memory and open the hardware model's **Attestation** tab. A banner on the Attestation tab offers to pre-fill a new template with the copied values. Select the link in the banner to open the create dialog prepopulated with the copied PCR values and reported EVE-OS version, then complete and save the template using the steps in [Manage PCR Templates](https://zededa.mintlify.site/new-ui/marketplace/manage-pcr-templates.md#add-a-pcr-template). ## Details Tab Use **Details** for identity, ownership, hardware, software, and lifecycle metadata. The page groups data into: | Group | Typical content | | - | - | | **Identity & Ownership** | ID, Name, Title, Description, Project, and Tags. | | **Hardware & Software** | Serial, Hardware Model, Model, Brand, Asset ID, Asset Location, Identity type, EVE version, and Location. | | **State & Timeline** | Run status, Admin state, Uptime, Boot time, Last update, Created, and Updated. | Copy controls appear on many values so you can use IDs and names in tickets, logs, or API calls. ### CPU placement The Details tab also includes a **CPU placement** card. Use it to check whether the node can place application instances on specific CPUs, how much CPU capacity is left in each pool, and which cores are already taken. Check this card before you deploy an application instance that uses a Dedicated or Isolated CPU policy. Hover over any label in the card to open a tooltip that explains the field. The card summary shows: | Field | Description | | - | - | | **Support** | **Supported** when EVE-OS reports the CPU placement capability for the node. Otherwise, the field explains why placement is unavailable. It shows **Not reported** when the node's EVE-OS does not report CPU placement capability. A missing report does not mean the node is unsupported. | | **CPU capacity** | Physical cores and logical CPUs the node reports. With SMT (hyper-threading) on, each physical core exposes more than one logical CPU. Workloads are pinned to logical CPUs. | | **Housekeeping** | Reserved and free threads in the Housekeeping pool. EVE-OS and every workload without a dedicated CPU policy run on these CPUs. This pool is never empty, so the node always stays manageable. | | **Dedicated** | Allocated, free, and total threads in the Dedicated pool, plus the number of free whole cores. These CPUs run only workloads with a Dedicated CPU policy. Free whole cores bounds how many whole-core workloads still fit. | | **Isolated** | Allocated, free, and total threads in the Isolated pool, plus the number of free whole cores. These CPUs are isolated from the general scheduler by the running kernel (`isolcpus`). Only workloads on the Isolated pool are placed here. | | **Kernel isolation** | Number of logical CPUs the running kernel isolates. Appears only when the node reports isolated CPUs. | If no CPUs are free outside the ones reserved for EVE-OS, the card warns that the node is fully booked. Host processes, EVE-OS services, and every shared app then share the reserved set. If the node status includes no CPU placement data at all, the card shows **CPU placement data unavailable** instead. Expand **Technical details** to see: * **CPU topology**: the CPU model, SMT (**On** or **Off**), the number of NUMA nodes and sockets, and every logical CPU ID the node reports. CPU IDs are not guaranteed to be contiguous or to start at zero. * **CPU allocation**: a core map that groups logical CPUs by socket and NUMA node (for example, **Socket 0 · NUMA 0**). Each physical core appears as a box labeled **Core N** that contains its logical CPU IDs. Color shows the pool that owns each CPU (**Housekeeping**, **Dedicated**, **Isolated**, or **Not reported** when the CPU is not listed in any pool). Fill shows allocation. A filled cell with a dot is **Allocated** to a workload. An outlined cell is **Free**. Hover over a core to see its socket, core, and the state of each logical CPU. Below the map, the card lists the CPU IDs in each pool and the free CPU IDs in the Dedicated and Isolated pools. * **Kernel isolation**: the **Isolated CPU IDs** and **Tickless CPU IDs** (`nohz_full`) reported by the running kernel. #### Optimize CPU placement When the node flags application instances for repacking, a **CPU placement can be improved** banner appears above the CPU placement card. Repacking restarts the flagged application instances so the node can place their CPUs more efficiently. The banner lists each flagged application instance. Instances that the node only advises repacking are marked **advised**. To repack the flagged application instances: 1. Confirm you have update permission for edge nodes in the node's project. The **Optimize CPU placement** button is hidden if you do not. It is also hidden for archived nodes. 2. Select **Refresh placement status** to load the latest list from the node. 3. Select **Optimize CPU placement**. Edge Infrastructure Services fetches the current list of flagged application instances. If none are flagged, no restart is requested. 4. Review the application instances listed in the **Optimize CPU placement?** dialog. The restart includes instances waiting for a repack and running instances that the repack moves out of the way. 5. Select **Restart flagged apps**. > [!WARNING] > > Workloads will be interrupted. Edge Infrastructure Services resolves the affected set when you confirm, so it might differ from the list shown in the dialog. After you confirm, the banner shows that the restart was requested and waits for fresh reports from the node. The request does not prove that placement has improved. Select **Refresh placement status** to check the result. For CPU placement on edge app definitions, see [CPU Placement for Application Instances](https://zededa.mintlify.site/new-ui/marketplace/cpu-placement.md). ## Workloads Tab Use **Workloads** to see resources associated with the node. The Workloads tab includes sub-views for: * **Applications** * **Patch Envelopes** * **Virtual Networks** * **Volumes** Use this tab before destructive lifecycle actions. For example, review Applications, Virtual Networks, and Volumes before off-boarding or deleting a node. ## Adapters Tab Use **Adapters** to understand how the node connects to networks and attached devices. The Adapters tab includes: * **NICs** * **VLANs** * **LAGs** * **IO Adapters** * **Topology** For adapter configuration steps, see [Configure node adapters](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/configure-node-adapters.md). ## Storage Tab Use **Storage** to inspect physical storage for the node. This is different from the Volumes sub-view in Workloads: * **Storage** focuses on node storage devices and health. * **Volumes** focuses on workload storage resources associated with Applications. Check Storage when Applications fail because of disk capacity, disk availability, or storage health. ## EVE-OS History The node detail page does not include an EVE-OS History tab. To review the EVE-OS base-image publish and activate events recorded for a node, open **Infrastructure > Operations > Release Manager**, select the **History** tab, and select the node. See [Release Manager](https://zededa.mintlify.site/new-ui/infrastructure-services/release-manager/release-manager.md#history-tab). To change the EVE-OS version running on a node, see [Update EVE-OS on Nodes](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/update-eve-os-on-nodes.md). ## Configuration Overlay You can open the configuration overlay from the node list or from the detail page. **From the list:** 1. Open **Infrastructure > Fleet > Nodes**. 2. Hover over the row of the node you want to configure. A **Configure** (gear) icon appears on the right side of the row. 3. Click the **Configure** icon. The configuration overlay opens over the list. **From the detail page:** Select **Configure node** in the header to open the configuration overlay. The overlay includes: * **General Settings > Details.** Edit the node's identity and ownership metadata, including its Title, Description, Project, Tags, Asset ID, Asset Location, and hardware Model. When the selected project is a Deployment project, this pane also shows a required **Deployment Tag** field. The tag assigns the node to one of that project's deployments, and the node then receives the app, network, volume, and node policies attached to the deployment whose tag matches. Changing the **Project** field clears the tag you already selected, because that tag belonged to the previous project's deployment list, so you must choose a new one before you can save. If the selected project holds no deployment records, the field reads `No deployments configured for this project` instead of offering a list. The field is hidden for Standard and Azure IoT projects, which do not use deployment tags. See [Create a Project](https://zededa.mintlify.site/new-ui/infrastructure-services/projects/create-a-project.md#configure-the-deployment) and the [Update policies on a Deployment project section](https://zededa.mintlify.site/new-ui/infrastructure-services/projects/manage-projects.md#update-policies-on-a-deployment-project) of Manage Projects for how deployment records and their tags are defined. * **General Settings > Administration** * **Adapters > NICs** * **Adapters > VLANs** * **Adapters > LAGs** * **Adapters > IO Adapters** * **Edge View.** This section appears only when Edge View is enabled for the node's project. Use it to review the Edge View policy status and configure per-node access settings and session defaults, including the Access EVE-OS toggle, cloud session restriction, Override Access Policies toggle, and Access Edge App Instances toggle, as well as session time limits, connection limits, and the dispatcher URL. See [Configure Edge View with the GUI](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-view/configure-edge-view-with-gui.md) and the [Edge View Policy section](https://zededa.mintlify.site/new-ui/infrastructure-services/projects/configure-project-policies.md#edge-view-policy) of Configure Project Policies. Use this overlay for node metadata, Configuration Lock, Edge Sync settings, adapter configuration, and Edge View policy. ## Verify the Result After using the detail page: * Confirm the expected run state is shown in the Status ribbon. Confirm the admin state sub-label under Status matches the configured lifecycle state, or check the Details tab for the full Admin state value. * Confirm the correct project and hardware model are shown. * Check Workloads before risky actions. * Check Configuration Status after configuration changes. * Check Adapters and Storage if Applications cannot connect or start. ## Next Steps > [card] [Node Status and Health](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/node-status-and-health.md) > > Interpret run state, admin state, and health signals for this node. > [card] [Configure Node Adapters](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/configure-node-adapters.md) > > Configure NICs, VLANs, LAGs, and IO adapters on the node. > [card] [Manage Node Lifecycle](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/manage-node-lifecycle.md) > > Activate, deactivate, reboot, off-board, and perform other lifecycle actions. > [card] [Tagging](https://zededa.mintlify.site/new-ui/start/tagging.md) > > Learn how node tags are used for identification, grouping, filtering, and fleet operations.