Servers

The Servers in Inventory Data Centers provides a centralized view to manage all physical infrastructure resources, such as GPU servers and bare metal nodes. This inventory enables efficient tracking, allocation, and planning of hardware resources across the system.

Each server entry represents a real physical node in the cloud partner’s infrastructure. These entries serve as the source of truth for provisioning compute resources to customers through isolated virtual machines and assigned GPUs.

Keeping server entries updated ensures full visibility and control over infrastructure assets, helping administrators prepare resources for provisioning and usage across environments.

Why use Servers?¶

Maintain a complete inventory of physical compute resources
Track details such as serial numbers, resource configurations, and tags
Allocate and deallocate resources as needed
Plan capacity and monitor utilization
Gain insight into GPU and VM usage per service
Serve as the backing source for compute provisioning workflows

Servers List View¶

From the Servers page, click the ellipsis icon at the far right of the required server and click View to access the following details:

Properties
Tags
Interfaces
GPU(s)
VM(s)

Click the edit (pencil) icon to modify server details.

Automatic Server Creation from Kubernetes Nodes¶

Servers can be created automatically in Inventory through Kubernetes node synchronization. This enhancement removes the need to manually create server records for Kubernetes-based infrastructure.

When a Kubernetes cluster is registered, the system evaluates each node for mandatory node-level labels. Nodes that meet all label requirements are synchronized into Inventory and result in server creation.

Node Label Requirement¶

Automatic server creation is driven by mandatory node-level labels applied on Kubernetes nodes.

Labels are applied at the Kubernetes node level
Both labels are required for inventory synchronization and server creation
Labels are evaluated per node, not per cluster

Required Labels¶

Enable Node Synchronization
- Label key: paas.envmgmt.io/node-sync
- Label value: true
- This label enables synchronization of the Kubernetes node with Inventory. It determines whether the node is eligible for inventory sync.
Target Data Center
- Label key: paas.envmgmt.io/node-sync-datacenter
- Label value: <datacenter-name>
- This label specifies the Inventory data center in which the corresponding server entry is created.
Each node intended to appear in Inventory must include both labels
Nodes missing either label are ignored during synchronization and no server is created

Note: The labels are evaluated per node, not per cluster.

Multi-Node Cluster Behavior¶

A Kubernetes cluster may contain one or more nodes
Each node that meets the label requirements results in a separate server entry
If multiple nodes include the required labels, the same number of server entries are created
Nodes without the required labels are ignored
All server entries created from labeled nodes are automatically associated with the same cluster

Example

In the Servers list, the server mks-5dec is created automatically through Kubernetes node synchronization.

The Kubernetes node includes the following labels:

paas.envmgmt.io/node-sync=true
paas.envmgmt.io/node-sync-datacenter=default-dc

Once detected, the system synchronizes the node with Inventory, creates the server entry in the specified data center, populates resource and GPU details, and assigns the device type as GPU-SERVER based on the GPUs present on the node.

Note:
If a cluster contains multiple nodes and different data center names are specified using the paas.envmgmt.io/node-sync-datacenter label on different nodes, the system does not synchronize nodes to multiple data centers.

Instead, all nodes in the cluster are synchronized to a single data center, determined by the data center label defined on the first node processed in the cluster. Any data center labels specified on the remaining nodes are ignored, and those nodes are synchronized to the same data center as the first node.

Automatically Populated Server Details¶

For each eligible node, the system automatically populates server details, including:

IP address
Total CPU count
Memory
Storage
GPU details (if available)

Device Type and GPU Detection¶

Nodes without GPUs are created as Server
Nodes with GPUs are created as GPU Server
If GPUs are added to a node after creation, the device type is automatically updated from Server to GPU Server
GPU configuration is detected automatically during synchronization

GPU Details in Server Inventory¶

The GPU(s) tab in the server details view displays the GPUs detected on the server and populated through inventory synchronization. Each entry represents an individual physical or logical GPU associated with the server.

The following GPU details are displayed:

Model No: Displays the GPU model detected on the node
PCIe ID: Displays the PCIe bus identifier of the GPU when available
Vendor Code: Displays the detected GPU vendor
UUID: Displays the unique identifier assigned to the GPU
Type:
- PASSTHROUGH – Full physical GPU allocation
- MIG (Multi-Instance GPU) – Partitioned GPU instances
- vGPU – Shared GPU allocation
vGPU Configuration: Displayed only for vGPU-based allocation

GPU identifiers, configuration type, and allocation details are refreshed automatically during inventory synchronization.

Existing Server Handling¶

Server names are derived from Kubernetes node names
Name matching is case-sensitive
If a server with the same name already exists:
- A duplicate server is not created
- The existing server record is updated

Synchronization Interval¶

Inventory synchronization runs every 120 seconds (± 5 seconds).

Any changes to node-level configuration, including GPU configuration and device type updates, are reflected during the next synchronization cycle.

Adding a Server (Manual Process)¶

Click + Add Server and provide the below details

Properties¶

Basic Information¶

Field	Description	Example
Name	Unique device name	`gpu-server-1`
Organization Name	Name of the associated organization	`ABC Corp`
Model	Hardware model of the device	`PowerEdge R750`
Manufacturer	Device manufacturer (e.g., NVIDIA)	`Dell`
Serial Number	Unique hardware serial number	`SN1234567890`
Device Type	Type of physical device (e.g., SERVER)	`SERVER`
Allocation Status	AVAILABLE or ALLOCATED	`AVAILABLE`

Authentication¶

Field	Description	Example
Username	Login username	`admin`
Password	Login password	`********`

Power Management¶

Field	Description	Example
BMC IP	BMC management IP	`192.168.1.10`
BMC Username	BMC login username	`root`
BMC Password	BMC login password	`********`

Resource Configuration¶

Field	Description	Example
Total CPU	Total number of CPU cores	`64`
Total Memory (MB)	RAM available in megabytes	`262144`
Total Storage (GB)	Local disk capacity in GB	`2048`

Tags¶

The Tags tab allows users to apply metadata to a server to help categorize and filter servers effectively.

There are two types of tags:

System Tags: These are managed internally by the platform and cannot be edited by the user. Example: priority: qe
Tags: These are user-defined key-value pairs. Users must provide both the key and value to add a tag.

Click Add Tags to enter the following:

Field	Description	Example
Key	The tag name or identifier	`env`
Value	The value associated with the key	`prod`

Note: Both the key and value fields are mandatory. An error is shown if either field is left blank.

Node Onboarding¶

Automatic node onboarding provides a streamlined method to register newly provisioned nodes into the platform. When nodes are deployed with the required agent and labeled with the vmaas-node-onboarding tag, the platform detects and initiates the onboarding workflow without manual steps.

This capability is useful in environments where nodes are frequently created or refreshed, such as large-scale deployments or automated infrastructure pipelines. It helps maintain consistency, reduces configuration errors, and improves operational efficiency by eliminating repetitive onboarding tasks.

This feature is primarily used by platform administrators, infrastructure teams, and managed service operators who maintain fleets of compute resources and require standardized enrollment behavior across environments.

Add Node Onboarding Tag to Server

A client-specific tag is used to trigger the automatic onboarding workflow. The tag name is determined by the onboarding template associated with the environment. For example, when using the default onboarding template, the tag vmaas-node-onboarding=true is used to indicate that the server should be onboarded.

Tag Key	Value	Purpose
`vmaas-node-onboarding`	`true`	Marks the server for onboarding workflow execution.

Note: The exact tag name may differ based on customer-specific environment or template configurations.

Configure Global Settings

Global settings define the onboarding template and required variables.

agents:
  - edge-onboarding-agent
deviceonboarding:
  template:
    name: vmaas-system-node-onboarding
    version: v3-node-onboarding
    overrides:
      variables:
        "Partner API Key": <client-specific-partner-api-key>
        "Ops Console Endpoint": <ops-console-endpoint>
        "Processing Type": inventory-page

Parameter	Description
Partner API Key	Authorization key used during onboarding.
Ops Console Endpoint	Endpoint for console communication.
Processing Type	Defines processing behavior for the onboarding workflow.

Trigger Node Onboarding

Navigation: Data Centers → Servers → Actions → Node Onboarding

This executes the onboarding workflow using:

Onboarding agent
Onboarding template
Variables from global settings
Automatic Host Tag Assignment

When onboarding completes, a host identifier tag is automatically added to the server.

Example:

Tag Key	Value	Meaning
`vmaas-onboarded`	`true`	Indicates successful onboarding and maps the server to a host profile.

Once onboarding is completed, select Node Onboarding again for the server to view the onboarding status, device identifier and partner identifier details.

Bulk Node Onboarding¶

Bulk Node Onboarding allows multiple servers in a data center to be onboarded using a single trigger instead of onboarding each server individually.

This capability is designed for large-scale environments where many servers must be registered quickly and consistently.

Bulk onboarding uses a tag + trigger model:

Servers are marked using a tag
A trigger is created to pick and onboard those tagged servers

Tag Servers for Bulk Onboarding

Add the following tag in the VM Onboarding Tags section of each server:

vmaas-node-onboarding = true

Only servers with this tag are eligible for bulk onboarding. Servers without this tag are ignored.

Start Bulk Node Onboarding

Navigation: Data Centers → Servers → Bulk Node Onboard

Click Bulk Node Onboard and select Create Onboarding Trigger to start a new bulk node onboarding operation.

Provide the following details:

Onboarding Trigger Name

A unique name to identify this bulk onboarding run. This name is used to track the trigger across retries, status views, and audit history.

Example: batch1-bulknode

Batch Size

Specifies the maximum number of servers that this trigger can pick for onboarding. Only servers with the vmaas-node-onboarding = true tag are considered.

Example: 5

Variables (Optional)

Allows passing runtime variables to the onboarding workflow. These values override or supplement variables defined in the onboarding template.

Environment Variables (Optional)

Allows setting environment-specific parameters required during onboarding, such as integration endpoints or credentials.

Overview Panel

Displays:

Ready Devices – Number of servers in the data center that have the vmaas-node-onboarding = true tag
Trigger Statistics – Count of devices in Success and Failed states for this trigger

After selecting Create Onboarding Trigger, the system scans the data center and picks servers that have the vmaas-node-onboarding = true tag. The selected servers are immediately submitted for onboarding.

How Batch Size Works

Batch size defines how many servers a single trigger is allowed to pick.

Tagged Servers	Batch Size	Result
3	2	The trigger picks 2 servers. One server remains and requires a new trigger.
100	50	The trigger picks 50 servers. A new trigger is required for the remaining 50.
3	15	All 3 servers are picked in the same trigger.

Trigger States

State	Meaning
Active	The trigger is currently running
Success	All servers picked by the trigger have been onboarded
Failed	One or more servers failed onboarding

Retrying Failed Servers

If a trigger picks multiple servers and some fail, selecting Retry retries only the failed servers. Successfully onboarded servers are skipped.

Handling Persistent Failures

If a server continues to fail: * Investigate and fix the issue in the Infra Portal * Retry the trigger

To exclude a server, remove the vmaas-node-onboarding = true tag

Trigger Constraints

Only one bulk onboarding trigger is allowed per data center at a time. A new trigger can be created only after the current trigger reaches a terminal state (Success or Failed).

Recommended Usage

All servers intended for onboarding should be tagged and processed using a single bulk trigger to ensure clean tracking, reliable retries, and accurate auditing.

View All Triggers

The View All Triggers page displays all bulk device onboarding triggers created for the selected data center and their current status.

This page is used to monitor progress, review results, and retry failed onboarding attempts.

Onboarding Triggers List

The left panel shows all triggers created for the data center.

Each trigger displays the trigger name, trigger status (Success or Failed), batch size, creation date, and the retry option for failed triggers.

Use the Search, Status, and Date filters to locate specific triggers.

Trigger Status

Status	Meaning
Success	All devices picked by the trigger have been onboarded successfully
Failed	One or more devices failed during onboarding

Trigger Details Panel: Selecting a trigger shows detailed information on the right side. This includes:
- Overall trigger status
- Success, Failed, and Pending device counts
- Progress bar showing how many devices have been processed
- Start and completion timestamps
Device List: The device list displays all devices associated with the selected trigger. For each device, the following information is shown:
- Device ID
- Onboarding status
- Status message returned by the onboarding workflow
Retry Failed Devices: For triggers in Failed state, a Retry option is available.

Selecting Retry will re-attempt onboarding only for the devices that previously failed and skip devices that were already onboarded successfully.

Users can also access the View All Triggers page directly from the Bulk Node Onboard dialog.

Selecting View All Triggers opens the list of all bulk onboarding triggers created for the selected data center, allowing tracking of progress, reviewing results, and retrying failed devices.

Interfaces¶

The Interfaces tab lists network interface details. Click Add Interface, fill in the required fields, and then click Add to save the entry.

Field	Description	Example
Interface Name	Name of the network interface	`eth0`
MAC Address	MAC address of the interface	`00:1A:2B:3C:4D:5E`
IP Address	Assigned IP address	`10.0.0.5`
Label	Custom label (optional)	`Primary NIC`
Connecting Switch	Name of the connected switch	`core-switch-01`
Switch Port	Port used on the switch	`Gig1/0/24`

GPU(s)¶

The GPU(s) tab allows you to add or view GPU assignments for the server. One or more GPUs can be attached to a single server.

Click Add GPU to input:

Field	Description	Example
Model No	GPU model number	`A100`
PCIe ID	PCIe identifier of the GPU	`0000:36:00.0`
Vendor Code	Identifier for the GPU vendor	`10de`
UUID	Unique identifier for the GPU	`GPU-f3f716ed`
Type	Assignment type: - PASSTHROUGH (full GPU to one VM), - MIG (split GPU into instances), - VGPU (shared GPU across VMs)	`PASSTHROUGH`
VM Reference	ID of the VM if the GPU is currently attached to a virtual machine	`0xa8789`

At the top of the GPU tab, users can track the allocated and unallocated GPU count in real time.

VM(s)¶

The VM(s) tab displays the virtual machines associated with the selected server. One or more VMs can be associated with a single server.

❗ Important: VM creation is only supported via API. The UI allows viewing details of VMs already associated with the server.

Below is an example of a VM already linked to a server:

Field	Description	Example
VM Name	Name of the virtual machine	`paas-hello-vm`
IP Address	IP assigned to the VM	`192.168.1.110`
Instance ID	VM instance ID	`i-abcxyz`
CPU Cores	CPU cores allocated	`4`
Memory (MB)	RAM allocated to the VM	`8192`
Storage (GB)	Storage allocated	`50`
Workspace ID	Associated workspace	`4qkolkn`
Organization ID	Owning organization	`4qkolkn`
Project ID	Project under which the VM runs	`4qkolkn`
Partner ID	Partner reference	`rx280ml`

Allocated and unallocated VM counts for the server are shown at the top of the tab.

Once all configuration tabs are completed, click Update Server to save changes for an existing server, or click Add Server to create a new server.

Bulk Upload Using CSV¶

To onboard multiple servers, use the CSV File menu available on the Servers page.

Download the CSV Template¶

Navigation: Data Centers → Servers → CSV File → Download Template

Select Download Template to download a pre-formatted CSV file that contains all required columns for server onboarding.

Open the downloaded file and enter server details such as:

Hostname
Model
IP Address
MAC Address
Device Type
Resource configuration

Save the file with a .csv extension.

Upload the CSV File¶

Navigation: Data Centers → Servers → CSV File → Upload CSV

Select Upload CSV, choose the updated CSV file, and confirm the upload.
The system validates the file and creates server records in the inventory.

This flow enables fast, large-scale server onboarding during environment setup, capacity expansion, or hardware migration.

Best Practices¶

Keep server records up-to-date
Use tags and system tags consistently
Regularly audit inventory for unused or outdated servers
Remove decommissioned servers from the inventory