Create a VM

Startup script run inside the guest the first time this VM boots. Must begin with a shebang (e.g. "#!/bin/bash"); a raw cloud-config document is rejected. Runs once per disk, not once per boot: a stop/start keeps the disk and does not re-run it, while a VM that lands on a fresh disk does. It runs as root once the network and your SSH keys are up, and its output goes to the VM's logs. A script that fails does not stop the VM from starting or from being billed, so check the logs rather than assuming it succeeded.

Boot disk in GB. Omit to get the default, which for a GPU VM is 100 GB per GPU. That default is not a floor: a smaller size is accepted down to the platform minimum (minDiskGb on GET /v1/gpu-availability). The ceiling is the node's per-GPU disk share times gpuCount (perGpu.diskGb on its offer), so a one-GPU VM cannot take a whole node's VM dir, and the size must also be free on that node right now.

Guest RAM for a GPU VM, in MiB. Omit for auto, which takes the tightest node that can give a full per-GPU share. At least 65% of the VRAM the VM is placed against (the catalog's floorPerGpu; a smaller request is raised to it), and at most some node's per-GPU share times gpuCount: a request above every node's share is rejected with VM_SHAPE_NOT_PLACEABLE, and one inside a share that no node has free right now with INSUFFICIENT_HOST_CAPACITY. Starting the VM after a stop, or re-dispatching it after its job is lost, starts it on its own node at no more than that node's current share (see requestedGuestMemMb).

Place this VM on a specific node. Required to use capacity reserved to your org; omit to use the public pool. There is no fallback: if the node has no room for this GPU count the request is refused rather than placed elsewhere. A node you have no rights on reads as not found.

true = open endpoint (no data-plane auth); default false requires an org API key

CPU-only VM machine size (the tier picker). Sending it alongside gpuCount is rejected with RESOURCE_SIZE_NOT_APPLICABLE: a GPU VM is sized from the host capacity its GPUs come with, not from this table.

compute-fabric capability tier (e.g. "pod"); empty for a plain VM

compute-fabric purchase option (on_demand; pods created before the rename carry the legacy reserved or interruptible values); empty for a plain VM

GPU vendor from the catalog, the same value as GpuModel.manufacturer (NVIDIA, AMD); absent on a CPU-only row

tenant container image (pods)

platform owner of this row ("serving" = inference serving replica, read-only on customer surfaces); empty for a customer-launched VM

true = open endpoint (no data-plane auth); false = require an org API key

managed-service tag; empty for a plain VM

deploying, running, stopped, failed, terminated, or interrupted; a row can also carry the queued status pending. interrupted means it served and is not serving now: it keeps its node, GPU and disk, and is not billed. A VM is interrupted while its node is offline and resumes when the node returns; a pod is interrupted for that and for losing its supervisor or its job on a live node, which the platform recovers by re-submitting it. After 7 days interrupted a VM is stopped (disk kept) and a pod is deleted.

Cause of the current status. The machine-readable values are "node_lost" (the host went offline and is expected back, so the disk is preserved), "node_removed" (the host was decommissioned, so the disk is gone and a restart deploys fresh elsewhere), "vm_exited", "user_stopped", "user_terminated", "user_restarted", "spot_reclaimed_by_capacity_owner", "spot_preempted_for_reservation_tenant", "auto_stopped_insufficient_balance", and the prefix "container failed to start: " followed by the container runtime's own message. Anything else is free text for a human to read.

pods only: size in GB of the pod's persistent /workspace volume.