El nivel Always Free de Oracle le da a cada tenancy 1.500 horas de OCPU y 9.000 horas de GB por mes de VM.Standard.A1.Flex, que es una VM Arm de 2 OCPU / 12 GB prendida todo el mes. También da, en muchas regiones, la misma respuesta cada vez que apretás Crear:

Out of host capacity.

Tres días de eso en sa-saopaulo-1 produjeron el loop de abajo. No tiene nada ingenioso; el valor está en qué revisar antes de correrlo, porque dos de las razones por las que la gente espera semanas no son capacidad.

Los dos textos del mismo error, y cuándo aparece (crear, arrancar o redimensionar)

La CLI y la API devuelven Out of host capacity.; la consola muestra otro texto para la misma falta de lugar:

Out of capacity for shape VM.Standard.A1.Flex in availability domain AD-1

Es el mismo problema con otras palabras: no hay hosts libres para ese shape en ese availability domain. Yo vi los dos: el loop de abajo recibe el primero y la consola de São Paulo, el segundo.

Y no aparece sólo al crear. La página de Oracle sobre este error pide no especificar fault domain "cuando creás o arrancás una VM", y la de cambio de shape recomienda consultar la capacidad disponible (CreateComputeCapacityReport) antes de cambiarlo: arrancar una instancia detenida y redimensionar una flex también piden lugar en el pool, y pueden fallar igual. Con una A1 Always Free, la consecuencia práctica es no detenerla para "ahorrar" (ya es gratis) y, si pensás agrandarla, contar con que quizás haya que esperar otra vez.

Revisión 1: la cuota no es capacidad

El error dice que el pool de hosts no tiene lugar para tu shape. No dice nada del límite de tu tenancy, y el límite es lo que puede bloquearte para siempre mientras le echás la culpa al pool. Leelo:

T=<tenancy OCID> AD=$(oci iam availability-domain list --compartment-id "$T" --query 'data[0].name' --raw-output) oci limits resource-availability get --compartment-id "$T" \ --service-name compute --limit-name standard-a1-core-count \ --availability-domain "$AD" --query 'data.{available:available,used:used}'

Si available es 0, reintentar no sirve de nada: estás en el límite de cores A1 (2 OCPU en una tenancy Always Free) y algo, quizás una instancia a medio crear de un intento anterior, lo está ocupando. Si available es 2, el loop tiene sentido.

Revisión 2: la región home, no cualquier región

El cómputo Always Free sólo cuenta en la región home de la tenancy, y la región home queda fija cuando se crea la cuenta. La propia página de Oracle lo dice sin vueltas: "You must create the Always Free compute instances in your home region." Así que un reporte de que "Mumbai tiene capacidad" te sirve sólo si Mumbai es tu región home. En Pay As You Go el cupo Always Free sigue aplicando en la región home, y una A1 en cualquier otra región es una instancia paga a precio de lista, que para algunos es la respuesta correcta.

En regiones con más de un availability domain, la A1 se puede crear en cualquier AD; data[0].name arriba elige el primero. Rotá el AD en cada intento si tu región tiene tres.

El loop

El reintento de la consola vive sólo mientras la pestaña está abierta. Esto corre en cualquier máquina con un ~/.oci/config funcionando y se detiene en el primer éxito. Una llamada de launch fallida tarda unos 100 segundos en volver, así que con un sleep de dos minutos son unos diez intentos por hora, bien por debajo del rate limit de la API; ante un 429 espera cinco minutos.

#!/usr/bin/env bash # needs a working ~/.oci/config; fill T (tenancy or compartment OCID), SUBNET, IMAGE, PUBKEY set -u T=${T:?} SUBNET=${SUBNET:?} IMAGE=${IMAGE:?} PUBKEY=${PUBKEY:-~/.ssh/id_ed25519.pub} NAME=${NAME:-a1} SLEEP=${SLEEP:-120} AD=$(oci iam availability-domain list --compartment-id "$T" --query 'data[0].name' --raw-output) try() { local ocpus="$1" mem="$2" out out=$(oci compute instance launch \ --compartment-id "$T" --availability-domain "$AD" \ --display-name "$NAME" --shape VM.Standard.A1.Flex \ --shape-config "{\"ocpus\":$ocpus,\"memoryInGBs\":$mem}" \ --image-id "$IMAGE" --subnet-id "$SUBNET" --assign-public-ip true \ --ssh-authorized-keys-file "$PUBKEY" \ --query 'data.{id:id,st:"lifecycle-state"}' 2>&1) if grep -q '"id": "ocid1.instance' <<<"$out"; then echo "$(date -u +%FT%TZ) OK ${ocpus}/${mem}: $out" grep -o 'ocid1\.instance[^"]*' <<<"$out" > ~/a1-retry.ok return 0 fi echo "$(date -u +%FT%TZ) no ${ocpus}/${mem}: $(grep -o '"message": "[^"]*"' <<<"$out" | head -1)" grep -qi 'TooManyRequests\|429' <<<"$out" && sleep 300 return 1 } n=0 while :; do n=$((n+1)); echo "--- round $n" try 2 12 && break try 1 6 && break sleep "$SLEEP" done echo "instance: $(cat ~/a1-retry.ok)" oci compute instance list-vnics --instance-id "$(cat ~/a1-retry.ok)" \ --query 'data[0]."public-ip"' --raw-output

Arrancalo con nohup ./a1-retry.sh > a1-retry.log 2>&1 & y olvidate. Prueba primero la 2/12 completa y después la 1/6. Tomar la chica cuando aparece suele convenir, pero agrandarla después es un cambio de shape: también necesita capacidad y reinicia la instancia, así que no lo des por hecho. El OCID de la imagen es por región (oci compute image list --compartment-id "$T" --operating-system "Canonical Ubuntu" --shape VM.Standard.A1.Flex lista las Arm).

Lo que me enseñó el hilo

Publiqué el loop en r/oraclecloud y las respuestas fueron más útiles que el script. Una persona esperó seis meses en Ashburn reintentando cada 30 segundos desde la consola, que es la versión de un solo AD y un solo shape de este problema y la razón para rotar ADs. Dos personas consiguieron A1 en Mumbai en cuestión de horas, una de ellas en Pay As You Go, lo que es consistente con la nota de Oracle de que pasar a pago "gives you access to more types of Compute resources". Y nadie, yo incluido, tiene una marca de tiempo de cuándo se libera São Paulo, por eso el loop registra cada intento: si alguna vez entra, el log dice a qué hora, y ese es el único dato que alguien tiene.

Preguntas frecuentes sobre "Out of host capacity" en Oracle Cloud

¿Qué significa "Out of host capacity" en OCI? Que en ese momento no hay lugar para el shape que pediste. La página de Oracle "Resolving Out of Host Capacity error" lo explica así: la capacidad es dinámica y depende del tamaño del pool (cantidad de hipervisores, y OCPUs y memoria libres en ellos) para un shape específico, en una región, availability domain o fault domain específicos. No es un error de tu configuración: el mismo launch puede entrar una hora después.

¿Qué recomienda Oracle? La misma página lista cuatro cosas: cambiar el shape, cambiar el fault domain, cambiar el availability domain y no especificar fault domain al crear o arrancar la VM, porque así OCI asigna el mejor disponible. Por eso el loop de arriba no pasa --fault-domain.

¿Sirve pasar a Pay As You Go? Ayuda, pero no es una garantía. La página de Always Free dice que este error en una instancia Always Free indica una falta temporal de shapes Always Free en tu región home, sugiere otro availability domain o esperar, y menciona el upgrade a Pay As You Go, que "gives you access to more types of Compute resources". Después del upgrade Oracle sigue sin cobrar los recursos Always Free y factura sólo lo que pase de ese cupo. En el hilo, uno de los dos casos que consiguió A1 en horas estaba en Pay As You Go: es un dato, no una regla.

¿Puedo crearla gratis en otra región que tenga capacidad? No. "You must create the Always Free compute instances in your home region", y la región home se elige al crear la cuenta. Una A1 fuera de la home se cobra a precio de lista.

¿Conviene reintentar por availability domain? Sí, si tu región tiene más de uno: según la misma página, la A1 se puede crear en cualquier AD salvo en South Korea North (Chuncheon). São Paulo tiene uno solo, así que ahí sólo queda reintentar en el tiempo y probar también 1 OCPU / 6 GB. Para rotar en el loop, cargá la lista una vez y elegí el AD según el número de ronda:

ADS=($(oci iam availability-domain list --compartment-id "$T" --query 'data[].name' --raw-output | tr -d '[]",')) # dentro del while, antes de llamar a try: AD=${ADS[$(( n % ${#ADS[@]} ))]}

¿Y si no es capacidad? Si oci limits resource-availability get devuelve available: 0 (la revisión 1), lo que bloquea es el límite de la tenancy, y ningún reintento lo cambia.

Cuando ya existe

Mantené la instancia ocupada. Oracle recupera las instancias Always Free inactivas después de siete días con menos de 20 % de CPU, red y memoria en el percentil 95. Y una instancia que te costó tres días merece estar en la lista de lo que corrés: yo construyo Control Cloud, que lee la tenancy por la API con una credencial de solo lectura y muestra la A1 junto a todo lo demás, incluido el boot volume que deja atrás si alguna vez la terminás sin marcar "permanently delete". Plan gratuito: 1 operador, 1 proveedor.