What Compatibility, Networking, and Security Checks Should You Complete Before a Provider Manages Your Own GPUs Alongside Cloud Capacity?

Three inventories decide whether your own GPUs are ready to be managed next to cloud capacity: a hardware and software matrix for every node, a map of every network path between your site and the provider, and a written boundary for who holds which credentials. On GMI Cloud, this is the groundwork for Managed GPU Cluster, our early-access service built for organizations with existing GPU clusters. It supports managed clusters across both GMI Cloud and BYOS (Bring Your Own Service) environments under one management experience.

That makes GMI Cloud a fit for teams that already run GPUs, need extra cloud capacity, and want both operated as Kubernetes clusters under centralized lifecycle management, with H200 nodes, available now, on the cloud side. Once the inventories are clean, three tests close the loop: a real job that gives consistent results on an owned node and a cloud node, an upgrade rehearsed on one node, and a removal that returns a node to your standalone control.

Build the hardware and software matrix

Mixed environments break at version seams. A job image built against one CUDA release lands on a node whose driver is older than that release requires, or a Kubernetes manifest relies on an API that the other side's version no longer serves. Record each owned node group in one row and the cloud side in the last row, then look for columns that disagree.

A managed cluster request on GMI Cloud lets you choose the data center, Kubernetes version, worker node specification, node count, and OS image, with Ubuntu 22.04 x86 64-bit as the default image. Pick those values to sit as close as possible to your owned fleet, so one container image and one set of manifests cover both. Worker nodes are H200 today; B200 nodes, like all Blackwell hardware on GMI Cloud, are in pre-order.

Owned nodes that differ among themselves each get their own row. An older GPU generation, a separate driver branch, or another Linux distribution is an input to the onboarding design, and every distinct row needs at least one node in the first validation wave.

Map the network paths before a node joins

Joint management adds traffic your firewall team has not seen before. List every path, its direction, and the test that proves it works under the narrowest possible rule.

Connection direction comes first in security review. A policy that allows management traffic only when it starts from your site, with no inbound management port open on-prem, shapes every other row in the path map.

Three lower-level details come next. Address ranges must not overlap: each GMI Cloud data center comes with a Default VPC that has a preset IPv4 CIDR block, and the VPC and subnet settings show that range, so compare it with your on-prem ranges before anything is routed. When the site link runs through a VPN or other tunnel, encapsulation lowers the effective path MTU, so size packets to that value and let through the ICMP messages that path MTU discovery relies on. If those are blocked and a sender exceeds the path MTU, large transfers can stall while small pings still succeed. Clocks must agree as well, since certificates and log correlation both depend on time sync.

On the cloud side, GMI firewalls control inbound traffic to bare metal servers and container instances. Each one is scoped to a single data center and takes rules by protocol, port range, and source CIDR, and every data center has a preset All Open firewall intended for testing. For bare metal or container instances that your site reaches, attach a custom firewall whose sources are the addresses your traffic actually arrives from, such as a NAT egress address or a routed private range, on the ports in the path table.

Write down the access boundary

Settle these points in writing before security review:

• Root and out-of-band access. Who keeps root on owned hosts, who holds BMC credentials, and whether the provider ever needs either.
• Change rights. Who may drain, cordon, reboot, or update drivers, and which of those actions need your approval first.
• Software on owned hosts. Which agents or Kubernetes components get installed on your nodes, the privileges they run with, and what they can reach.
• Console membership. Which people belong to your GMI organization. Members are invited by email and can be removed, and the organization owner can be reassigned, as the organization settings describe. Kubernetes credentials, SSH keys, BMC accounts, and service tokens sit outside that list and need their own revocation step.
• Data placement. Which datasets may leave your site. Keep restricted jobs on owned nodes with required scheduling rules on labels the nodes cannot change. Those rules govern placement only, so also set storage, checkpoint, and log destinations, and restrict outbound traffic from owned nodes to approved endpoints.
• Secrets. Where registry credentials and service tokens live, and how they rotate.
• Audit. Where records of administrative actions on owned nodes are kept, and who can read them.

Then test it. Remove a test member, revoke that person's cluster and host credentials, and try each path again; trigger an action your change process routes for approval to see that it waits for one.

Validate onboarding with a job

After the first owned nodes join, run this sequence:

1. Inventory check. Each owned node reports the GPU count, memory, and labels recorded in your matrix.
2. Reference job. A short job with the same image, inputs, precision, and deterministic settings runs on an owned node and on a cloud node, and the results agree within the tolerance you set, or on the task metric where exact matches are not expected.
3. Collective tests. An NCCL all-reduce across the GPUs inside one owned node, and for multi-node workloads another across at least two owned nodes on the same fabric, each land within the range you measured before onboarding.
4. Placement rules. A job marked restricted schedules only on owned nodes, and an unmarked job lands where your policy says it should.
5. Telemetry and alerts. GPU metrics and logs from both sides appear together, your existing monitoring still receives owned-node data, and an induced fault on an owned node raises an alert.
6. Management link interruption. Cut the management connection to one owned test node for a set window while a job runs, and record whether the job continues, how the node is reported, and how it rejoins.

Rerun the sequence after every change to the matrix.

Rehearse an upgrade and a removal

For the upgrade, pick one owned node and a realistic change such as a driver update. Drain the node, have whoever holds that change right under your access boundary apply it, return the node to service, and rerun the validation sequence. Record who approved, who executed, how long the node was out, and whether jobs on other nodes were affected.

For the removal, take the same node out of management completely. Workloads should drain, the agents and credentials used to manage that node should be gone, firewall rules opened for it should be closed, and the node should run your standalone stack again. A clean exit on one node is the strongest evidence that onboarding the rest is reversible.

Nodes to hold for a later wave

Some owned capacity is better left out of the first wave until a design decision is made: air-gapped enclaves with no permitted outbound path, nodes shared with non-AI production systems, hardware generations far from the cloud side's matrix, and machines whose security owner has not signed off on the access boundary.

FAQ

How many owned nodes should the first onboarding wave include?

Enough to exercise every row that differs in your matrix: one node from each hardware or driver group, plus one spare for the upgrade and removal rehearsal.

Which records should come out of the onboarding review?

Keep the completed matrix, the path table with test results, the signed access boundary, per-node validation output, and the upgrade and removal logs. Together they are the baseline for later changes and the next wave.

Bring your node matrix to an onboarding review

Share your node matrix and network constraints with GMI Cloud's team to scope a Managed GPU Cluster that spans your GPUs and ours during early access. To see how cloud-side clusters are configured, open Managed GPU Clusters in the console and walk through the request form.