Host With GPU Hardware Cannot Be Assigned to a Cluster From the UI

Problem

When attempting to assign a host to a cluster via the PCD UI ('Infrastructure > Hosts > Assign Host'), the 'Host Cluster' dropdown appears empty and shows no available clusters, even though clusters exist and are healthy. The host remains unassigned and cannot be onboarded through the UI.

Environment

• Private Cloud Director Virtualization - up to v2026-1-427

• Self-Hosted Private Cloud Director Virtualization - up to v2026-1-427

• Component: GPU, Host Onboarding

Cause

The PCD UI filters the available clusters based on GPU compatibility. A host reporting GPU hardware is only shown clusters that have gpu.enabled: true in the cluster configuration. If no clusters have GPU enabled, the dropdown renders empty.

This is a known UI-only filtering issue. The backend (Resource Manager API) does not enforce this restriction — a host with GPU hardware can be successfully assigned to a non-GPU cluster via the API. This issue is tracked under PCD-5764.

Diagnostics

1

Step 1 — Retrieve a token and set variables

Source the OpenStack RC file for the environment and export the required variables. These variables are used across all diagnostic and workaround commands.

$ export OS_TOKEN=$(openstack token issue -f value -c id)
$ export DU=<DU_FQDN>
$ export HOST_ID=<HOST_UUID>

Replace <DU_FQDN> with the fully qualified domain name of the PCD management plane (for example, https://region.app.pcd.platform9.com) and <HOST_UUID> with the UUID of the affected host.

2

Step 2 — Confirm the host has GPU hardware detected

Query the Resource Manager API to check whether the host is reporting GPU hardware.

Resmgr API

$ curl -sS -H "x-auth-token: $OS_TOKEN" \
    "$DU/resmgr/v1/hosts" \
    | jq '.[] | select(.info.hostname == "<HOSTNAME>") | .extensions.gpu_info.gpu_pci'

Sample Output — GPU detected

[
  {
    "pci_address": "[PCI_ADDRESS]",
    "vendor_id": "[VENDOR_ID]",
    "device_id": "[DEVICE_ID]",
    "model": "[GPU_MODEL]"
  }
]

If the output returns a non-empty array containing GPU device entries (for example, NVIDIA L40S or A100), the host is being reported as a GPU host by the Resource Manager. Proceed to Step 3.

If the output is empty ([]), the host is not detected as a GPU host and this issue does not apply.

3

Step 3 — Confirm no clusters have GPU enabled

Check the GPU configuration of all existing clusters.

Resmgr API

$ curl -sS -H "x-auth-token: $OS_TOKEN" \
    "$DU/resmgr/v2/clusters" \
    | jq '.[] | {name: .name, gpu_enabled: .gpu.enabled}'

Sample Output

{
  "name": "[CLUSTER_NAME]",
  "gpu_enabled": false
}

If all clusters return gpu_enabled: false or null, this confirms the filtering mismatch — the UI finds no GPU-enabled cluster to display and the dropdown renders empty. Proceed to the Workaround.

Workaround

Bypass the UI by assigning the host to a cluster and applying the hypervisor role directly via the Resource Manager API. These API calls use the token and variables set in Diagnostics Step 1 — ensure those variables are still exported in the shell session before proceeding.

For reference on applying roles via the Resource Manager API, see How To Manually Apply Roles On a Host Using API Calls.

1

Step 1 — Assign the host to a cluster

Set the CLUSTER_ID variable to the target cluster's UUID, then run the assignment call. The HOST_ID variable was set in Diagnostics Step 1.

Resmgr API

$ export CLUSTER_ID=<CLUSTER_UUID>

$ curl -sS -X PUT \
    -H "x-auth-token: $OS_TOKEN" \
    -H "Content-Type: application/json" \
    "$DU/resmgr/v2/hosts/$HOST_ID/hostconfig/$CLUSTER_ID" \
    -d '{}'

An empty JSON response {} indicates the cluster assignment was accepted successfully.

2

Step 2 — Apply the hypervisor role

Resmgr API

$ curl -sS -X PUT \
    -H "x-auth-token: $OS_TOKEN" \
    -H "Content-Type: application/json" \
    "$DU/resmgr/v2/hosts/$HOST_ID/roles/hypervisor" \
    -d '{}'

An empty JSON response {} indicates the hypervisor role was applied successfully.

3

Step 3 — Verify the host is assigned and scheduling is enabled

1. In the PCD UI, navigate to 'Infrastructure > Hosts' and confirm the host now appears listed under the target cluster.

2. Click into the host and confirm the 'Scheduling' section shows Enabled.

The host is ready for workload placement once both conditions are confirmed.

Resolution

The fix for PCD-5764 is available in v2026-4.89 (April release). Upgrade to v2026-4.89 or later to resolve this issue permanently. After upgrading, hosts with GPU hardware will be visible in the 'Host Cluster' dropdown for all clusters regardless of whether gpu.enabled is set, and the API workaround above will no longer be required.

Additional Information

Self-Hosted customers — Alternative: Run commands directly from the resmgr pod

On Self-Hosted deployments, all Resource Manager API calls in this article can alternatively be run from within the resmgr pod using localhost:8082, without needing a token. To use this approach, replace $DU/resmgr/ with http://localhost:8082/ and remove the -H "x-auth-token: $OS_TOKEN" header from every curl command. For example:

# Public API form (used in this article — works for all customers):
curl -sS -X PUT \
    -H "x-auth-token: $OS_TOKEN" \
    -H "Content-Type: application/json" \
    "$DU/resmgr/v2/hosts/$HOST_ID/hostconfig/$CLUSTER_ID" \
    -d '{}'

# Self-Hosted alternative (from within the resmgr pod):
curl -s -X PUT \
    -H "Content-Type: application/json" \
    "http://localhost:8082/resmgr/v2/hosts/<HOST_UUID>/hostconfig/<CLUSTER_UUID>" \
    -d '{}'

Apply the same substitution pattern to the diagnostic and role assignment calls in the Workaround section.

Related articles:

• How To Manually Apply Roles On a Host Using API Calls — covers the full set of Resource Manager API role assignments for hypervisor, persistent storage, image library, and other host roles.