Troubleshoot Compute

get-instance shows status: FAILED and a statusReason.

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.

• Read statusReason and look it up in 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.

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, ….

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.

• 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.

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

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

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.

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

   origin compute list-instance-types

2. For a stopped instance, change its type, then start it. See Change an instance’s type.

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

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

• 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.

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

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.

• 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.
• 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.

timedatectl inside the instance shows System clock synchronized: no.

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.

• 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.

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

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

• 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.
• 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.
• 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.

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.

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.

Query the instance’s CPU use for the last 15 minutes with the RATE of oc_compute_instance_cpu_seconds_total. See Query metrics. A guest that is up uses some CPU; values of 0 throughout mean it isn’t running anything.

1. Stop the instance and wait for STOPPED.
2. Start it again and wait for RUNNING. Then connect over SSH, or check the CPU metric again.
3. 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.

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.

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

1. Run cat /etc/machine-id on two affected instances. Identical output confirms the cause.

2. On each affected instance, generate a new machine-id and reboot:

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

3. Fix the image so new instances don’t inherit it. Clear the machine-id before you snapshot. See Create an image.