# Troubleshoot Compute

Fix common Compute problems - failed instances, refused launches and starts, impaired or unknown health, unsynchronized clocks, SSH failures and broken pod networking.

Each section starts from what you see. For the meaning of every `statusReason`, see [Status reasons](/docs/compute/reference/status-reasons).

## Find your symptom [#find-your-symptom]

<Symptoms>
  <Symptom href="#instance-status-is-failed" title="Instance status is FAILED" />
  <Symptom href="#launch-refused-with-insufficient_capacity" title="Launch refused with INSUFFICIENT_CAPACITY" code="INSUFFICIENT_CAPACITY" />
  <Symptom href="#start-or-change-type-refused-with-product_unavailable" title="Start or change-type refused with PRODUCT_UNAVAILABLE" code="PRODUCT_UNAVAILABLE" />
  <Symptom href="#guest_present-is-impaired" title="GUEST_PRESENT is IMPAIRED" />
  <Symptom href="#health-checks-show-insufficient_data" title="Health checks show INSUFFICIENT_DATA" />
  <Symptom href="#system-clock-synchronized-no" title="System clock synchronized: no" />
  <Symptom href="#cant-connect-over-ssh" title="Can’t connect over SSH" />
  <Symptom
    href="#running-and-available-after-a-machine-failure-but-unreachable"
    title="Running and available after a machine failure, but unreachable"
    proposal
  />
  <Symptom href="#pod-networking-broken-between-cloned-instances" title="Pod networking broken between cloned instances" />
</Symptoms>

Entries marked <ProposalChip /> describe what we ran into while testing on 12 October 2026. They are not on docs.origincloud.eu yet.

## Instance status is FAILED [#instance-status-is-failed]

<YouSee>

`get-instance` shows `status: FAILED` and a `statusReason`.

</YouSee>

<Why>

The host refused or never confirmed a start or a stop, or a volume, network interface or placement the instance needed failed. `FAILED` doesn’t mean the guest is stopped.

</Why>

<Fix>

- Read `statusReason` and look it up in [Status reasons](/docs/compute/reference/status-reasons).
- Fix anything the reason names, such as a quota or a full subnet.
- Start the instance with `origin compute start-instance`, or terminate it with `origin compute terminate-instance`. Don’t leave a `FAILED` instance sitting, because it can still hold capacity.

</Fix>

## Launch refused with INSUFFICIENT_CAPACITY [#launch-refused-with-insufficient_capacity]

<YouSee>

The launch or start fails with `INSUFFICIENT_CAPACITY` and a message such as `insufficient capacity for instance type gp1.core.16: no host has 16 vCPU and 65536 MiB memory free right now; retry later, …`.

</YouSee>

<Why>

No machine has room for that instance type right now, or no machine serves its kind. This is a refusal, not a fault. Nothing was created.

</Why>

<Fix>

<CapacityAdvice />

- Retry the same request in a few minutes.
- Or choose a larger type whose `available` is `true`, or a type of another kind. See [Instance types](/docs/compute/instances/instance-types).

The API message goes on to suggest a smaller type. For `gp1.core.2` there is none.

</Fix>

## Start or change-type refused with PRODUCT_UNAVAILABLE [#start-or-change-type-refused-with-product_unavailable]

<YouSee>

`start-instance`, `change-instance-type` or `launch-instance` fails with `PRODUCT_UNAVAILABLE`, naming an instance type or storage class.

</YouSee>

<Why>

The type or class is no longer offered, or isn’t on sale. A stopped instance whose type was withdrawn can’t start as that type.

</Why>

<Fix>

1. List the types and pick one whose `available` is `true`:

   ```sh
   origin compute list-instance-types
   ```

1. For a stopped instance, change its type, then start it. See [Change an instance’s type](/docs/compute/instances/change-type).

</Fix>

## GUEST_PRESENT is IMPAIRED [#guest_present-is-impaired]

<YouSee>

The instance is `RUNNING`, but `healthChecks` shows `GUEST_PRESENT` as `IMPAIRED` and `availability` as `IMPAIRED`.

</YouSee>

<Why>

The machine carrying the instance is reachable and no longer runs it. Waiting won’t bring it back.

</Why>

<Fix>

- Stop the instance and wait for `STOPPED`.
- Start it again. It can start on any machine, with its volumes and addresses unchanged.

See [Instance health checks](/docs/compute/instances/health-checks).

</Fix>

## Health checks show INSUFFICIENT_DATA [#health-checks-show-insufficient_data]

<YouSee>

Checks read `INSUFFICIENT_DATA` and `availability` reads `UNKNOWN`, often with `HOST_REACHABLE` as `IMPAIRED` first.

</YouSee>

<Why>

The platform has lost contact with the machine carrying the instance, so it can’t observe the instance. It doesn’t know whether the instance is still running. Right after launch, checks also read `INSUFFICIENT_DATA` until the first observation arrives.

</Why>

<Fix>

- Wait a few minutes. If the machine comes back, the checks return to OK.
- If the machine failed, the platform records the instance as `STOPPED` with a `statusReason`. Start it again. See [When the machine under an instance fails](/docs/compute/instances/host-failure).
- If `HOST_REACHABLE` stays `IMPAIRED`, or the checks stay `INSUFFICIENT_DATA` on a running instance, contact Origin Cloud support. The `SYSTEM` category means there is nothing to fix inside the instance.

</Fix>

## System clock synchronized: no [#system-clock-synchronized-no]

<YouSee>

`timedatectl` inside the instance shows `System clock synchronized: no`.

</YouSee>

<Why>

Either the guest isn’t using the platform’s time service, or the physical machine’s own clock isn’t synchronized and the platform is telling the guest not to trust it.

</Why>

<Fix>

- Check that `NTP service: active` is shown. If it isn’t, enable the guest’s time service with `sudo timedatectl set-ntp true`.
- If you pointed the guest at an external time server, check that the instance has internet access.
- If the guest uses the platform’s time service and the clock stays unsynchronized, contact Origin Cloud support.

See [Guest environment](/docs/compute/instances/guest-environment).

</Fix>

## Can’t connect over SSH [#cant-connect-over-ssh]

<YouSee>

`ssh` times out, or fails with `Permission denied (publickey)`.

</YouSee>

<Why>

The wrong user name or key, a security group that doesn’t allow port 22, or an instance with no public address.

</Why>

<Fix>

- Check the user name. Use the instance’s `loginUser` from `get-instance`, not `root`.
- Check the key. Use the private key of the key pair the instance was launched with.
- Check that a security group on the instance’s network interface allows inbound TCP port 22 from your address. The VPC’s default group does, unless its rules were changed. See [Security groups](/docs/network/traffic-control/security-groups).
- Check that the instance has a public address, either assigned at launch in the default subnet or a floating IP you associated. See [Floating IPs](/docs/network/internet-access/floating-ips).
- Check that the instance is `RUNNING` and its `availability` is `AVAILABLE`.
- If every check passes and you still can’t connect, stop the instance, wait for `STOPPED`, and start it again. If that doesn’t help, contact Origin Cloud support with the instance URN and the time you last connected. The API and the CLI have no reboot operation and no console log to read.

</Fix>

## Running and available after a machine failure, but unreachable [#running-and-available-after-a-machine-failure-but-unreachable]

<YouSee>

The instance was `STOPPED` with a machine-failure `statusReason`. You started it, and it now reads `RUNNING` with `availability` `AVAILABLE`, but SSH and every other port time out.

</YouSee>

<Why>

The guest didn’t come back up after the start, although the instance’s status and health checks don’t show it. Moving the instance’s Floating IP off and back doesn’t help.

</Why>

<Check>

Query the instance’s CPU use for the last 15 minutes with the `RATE` of `oc_compute_instance_cpu_seconds_total`. See [Query metrics](/docs/observability/query-metrics). A guest that is up uses some CPU; values of `0` throughout mean it isn’t running anything.

</Check>

<Fix>

1. Stop the instance and wait for `STOPPED`.
1. Start it again and wait for `RUNNING`. Then connect over SSH, or check the CPU metric again.
1. If it’s still unreachable, contact Origin Cloud support. Quote the instance URN, the time of the machine failure, and the time of each start.

</Fix>

## Pod networking broken between cloned instances [#pod-networking-broken-between-cloned-instances]

<YouSee>

Instances launched from your own image can’t reach each other over VXLAN. Kubernetes pod networking with VXLAN or Geneve encapsulation fails between nodes, while the nodes reach each other directly.

</YouSee>

<Why>

The instances share one machine-id, inherited from the image. Their VXLAN devices then get the same MAC address and can’t exchange packets.

</Why>

<Fix>

1. Run `cat /etc/machine-id` on two affected instances. Identical output confirms the cause.
1. On each affected instance, generate a new machine-id and reboot:

   ```sh
   sudo rm -f /etc/machine-id /var/lib/dbus/machine-id
   sudo systemd-machine-id-setup
   sudo reboot
   ```

1. Fix the image so new instances don’t inherit it. Clear the machine-id before you snapshot. See [Create an image](/docs/compute/images/create).

</Fix>

## Related [#related]

- [Status reasons](/docs/compute/reference/status-reasons)
- [Error codes](/docs/platform/reference/errors)
- [Troubleshoot storage](/docs/storage/troubleshooting)
- [Troubleshoot networking](/docs/network/troubleshooting)