Un site que nunca se conectó

Capturado el 2026-07-28 desde un CE de este despliegue. sitecli/capture-manifest.json registra qué nodo, y scripts/capture-sitecli.sh --check vuelve a verificar la superficie de comandos contra un CE en vivo.

Confirme que está preguntando al tenant correcto. Esto cuesta un comando y va primero porque equivocarse hace que todos los pasos posteriores le mientan: una flota sana en el tenant que no está mirando es indistinguible de una flota que nunca se registró.
Ventana de terminal
```
cd terraform
terraform output -raw xc_tenant       # the tenant this deployment belongs to
terraform output -raw xc_env_tenant   # the tenant your shell is exporting
```
```
f5-sales-demo
f5-sales-demo
```
¿No coinciden, o una credencial que cree correcta devuelve un 401 sin más? Ese es el síntoma de un token emitido para otro tenant, y ya le ha costado a este despliegue una reconstrucción completa (issue 696).
Confirme qué piensa el tenant. Estar ausente de la lista de sites es un problema distinto a estar presente pero no ONLINE.
Ventana de terminal
```
curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
  "$XCSH_API_URL/api/config/namespaces/system/sites" | jq -r '.items[].name'
```
Si el site existe e informa ONLINE, el registro tuvo éxito y usted está en el flujo de trabajo equivocado.
Encuentre el registro del site y su estado. Un nodo puede registrarse y luego esperar aprobación, lo que desde fuera parece idéntico a un fallo.
Ventana de terminal
```
curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
  "$XCSH_API_URL/api/register/namespaces/system/registrations_by_site/<site>" \
  | jq -r '.items[] | "\(.name)  \(.object.status.current_state)  \(.object.spec.gc_spec.infra.hostname)"'
```
```
r-a97e20c8-b7e1-483d-bd76-34a64ff8bc78  ONLINE  f5-xc-ce-vm-01
```
Ningún elemento en absoluto significa que el nodo todavía no se ha registrado: vaya a la consola serie. Un elemento en un estado distinto de ONLINE significa que se registró y algo posterior falló, lo cual es una investigación diferente.

Para barrer todo el namespace en busca de cualquier cosa pendiente de aprobación, listregistrationsbystate toma el estado como un cuerpo POST:
Ventana de terminal
```
curl -sS -X POST -H "Authorization: APIToken $XCSH_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"namespace":"system","state":"PENDING"}' \
  "$XCSH_API_URL/api/register/namespaces/system/listregistrationsbystate" | jq -r '.items[].name'
```
En una flota sana eso no devuelve nada, porque la aprobación está automatizada.

Confirme que la VM está realmente en ejecución, antes de suponer un fallo de software.

az vm list -d -g <resource-group> --query "[].{name:name,power:powerState}" -o table

Name              Power
----------------  ----------
f5-xc-ce-vm-01    VM running
f5-xc-ce-vm-02    VM running
f5-xc-ce-vm-03    VM running
mcn-ce-ha-client  VM running

Conéctese a la consola serie. De forma interactiva esto necesita un terminal real; la conexión en sí puede automatizarse a través del websocket — consulte la consola serie.
Ventana de terminal
```
az serial-console connect -g <resource-group> -n <vm-name>
```
Si se rechaza, compruebe que el diagnóstico de arranque está habilitado en la VM antes de concluir que el nodo es inalcanzable; ese requisito previo y sus modos de fallo se tratan en la página de la consola serie.
Lea lo que muestra la consola, en este orden. cloud-init primero: un nodo cuyo cloud-init nunca se completó no tiene configuración con la que registrarse. Luego los propios intentos de registro, después DNS: si el nodo no puede resolver register.ves.volterra.io, nada de lo posterior puede funcionar.
Una vez que el nodo esté ONLINE, verifique con health y espere state: PROVISIONED.

Las causas habituales

Está apuntando al tenant equivocado, así que una flota que está bien parece ausente. Paso 1.
cloud-init no se completó, por lo que /etc/vpm/config.yaml está ausente o es incorrecto.
El token de registro ha caducado, ya se ha consumido o es de otro tenant.
No hay ruta de salida hacia register.ves.volterra.io.
Desfase de reloj lo bastante grande para invalidar certificados — rápido de descartar más adelante con chronyc-sources, pero inaccesible hasta que el nodo esté en línea. El banner de inicio de sesión de SSH informa NTP: Synced y el estado del resolutor antes de que ejecute nada, cuando SSH está disponible.