Home / OCI

OCITroubleshootingAdvanced

OCI launch fails with \"Out of host capacity\": get the instance running now and stop it happening during scale-out

Launching or resizing an OCI instance fails with InternalError Out of host capacity. Try other fault domains, ADs and shapes, use capacity reservations for critical workloads, and make instance pools spread placement.

Deepak Bhardwaj4 min read

Applies toOCI Compute (VM and bare metal, Flex shapes, GPU shapes), instance pools, compute capacity reservations, OCI CLI 3.x

Symptoms

  • Launch, start or resize fails with 500 InternalError and message Out of host capacity.
  • An instance pool or autoscaling scale-out stays below target with the same error in its work requests.
  • A stopped instance won't start again (stopping a VM releases its host capacity).

This is not a quota error. Quotas and service limits give LimitExceeded or QuotaExceeded. "Out of host capacity" means OCI has no free hosts of that shape in that availability domain (AD) or fault domain right now.

Step 1: Rule out limits

oci limits resource-availability get --service-name compute \
  --limit-name standard-e5-core-count --compartment-id $TENANCY \
  --availability-domain "XXXX:AP-MUMBAI-1-AD-1"

Limit names vary by shape; list them with oci limits definition list --service-name compute --compartment-id $TENANCY --all. If available is 0, request a limit increase; that's a different problem.

Step 2: Try a different fault domain or AD

Capacity is tracked per AD and per fault domain. If you pinned a fault domain, let OCI choose:

oci compute instance launch \
  --availability-domain "XXXX:AP-MUMBAI-1-AD-1" \
  --compartment-id $COMPARTMENT \
  --shape VM.Standard.E5.Flex \
  --shape-config '{"ocpus":4,"memoryInGBs":64}' \
  --subnet-id $SUBNET --image-id $IMAGE \
  --display-name app02
# no --fault-domain: OCI picks one with capacity

In multi-AD regions, try another AD (the subnet must be regional or exist in that AD):

oci iam availability-domain list --query 'data[].name' --output table

Many regions have a single AD; then fault domains and shapes are your only levers.

Step 3: Try a nearby shape

Capacity is per shape family. Often one family is exhausted while another is free:

If this fails Try
VM.Standard.E5.Flex VM.Standard.E4.Flex, VM.Standard3.Flex
VM.Standard.E4.Flex VM.Standard.E5.Flex, VM.Standard.A1.Flex (Arm, if your software supports it)
A large Flex size Smaller OCPU/memory per instance, more instances
GPU shapes Another region, or a capacity reservation

Check which shapes the AD offers to your compartment:

oci compute shape list --compartment-id $COMPARTMENT \
  --availability-domain "XXXX:AP-MUMBAI-1-AD-1" \
  --query 'data[].shape' --output table

Tip

Smaller Flex instances fit into fragmented capacity more easily. If a 32-OCPU VM fails, two 16-OCPU VMs may launch fine.

Step 4: For a stopped instance that won't start

You can't change AD on start. Options, from least to most effort:

  1. Retry start every few minutes for a short period (capacity frees up as others stop).
  2. Change the shape while stopped (oci compute instance update --instance-id ... --shape VM.Standard.E4.Flex --shape-config ...), then start.
  3. Create a new instance from the boot volume (or a boot volume backup) in another fault domain or AD.

Warning

Don't stop production instances casually in a tight region. A stopped VM gives back its capacity; you may not get it back when you need it. Use reboot instead of stop/start where possible.

Step 5: Reserve capacity for workloads that must start

Compute capacity reservations hold host capacity for you in an AD (and optionally a fault domain). You pay for reserved-but-unused capacity at a discounted rate (check current pricing).

oci compute capacity-reservation create \
  --compartment-id $COMPARTMENT \
  --availability-domain "XXXX:AP-MUMBAI-1-AD-1" \
  --display-name cr-app-prod \
  --instance-reservation-configs '[{"instanceShape":"VM.Standard.E5.Flex","instanceShapeConfig":{"ocpus":4,"memoryInGBs":64},"reservedCount":4}]'

Launch into it with --capacity-reservation-id. Use reservations for:

  • DR instances you must start during a regional event.
  • Batch or month-end workloads that scale out on schedule.
  • GPU workloads.

Step 6: Make instance pools resilient

An instance pool pinned to one fault domain and one shape fails as a unit. Configure placement across fault domains (and ADs where available):

"placementConfigurations": [
  { "availabilityDomain": "XXXX:AP-MUMBAI-1-AD-1",
    "primarySubnetId": "ocid1.subnet...",
    "faultDomains": ["FAULT-DOMAIN-1","FAULT-DOMAIN-2","FAULT-DOMAIN-3"] }
]

Check work requests to see failed scale-outs:

oci work-requests work-request list --compartment-id $COMPARTMENT --resource-id $POOL_ID \
  --query 'data[?status==`FAILED`].{op:"operation-type", time:"time-accepted"}' --output table

Keep a second instance configuration with an alternate shape ready, so you can switch the pool quickly (oci compute-management instance-pool update --instance-configuration-id ...).

Symptom → action

Situation Action
One-off launch fails Drop fault domain pin, try other AD, try another shape
Stopped VM won't start Change shape, or relaunch from boot volume elsewhere
Autoscaling fails at peak Spread across FDs, alternate instance configuration, reservation
DR launch must succeed Capacity reservation in DR region
GPU shapes Reservation or talk to your Oracle account team early

Prevent it next time

  • Don't pin fault domains unless you need anti-affinity; when you do, use all three.
  • Build images for two shape families (AMD and Intel, or x86 and Arm) so you can switch.
  • Reserve capacity for DR and scheduled peaks; test that launches into the reservation work.
  • Alert on failed instance pool work requests so scale-out failures don't go unnoticed until users complain.

Related fixes