Troubleshoot Compute

Each section starts from what you see. For the meaning of every statusReason, see Status reasons.

Instance status is FAILED

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

Cause: 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.

Resolution:

1. Read statusReason and look it up in Status reasons.
2. Fix anything the reason names, such as a quota or a full subnet.
3. 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.

Launch refused with INSUFFICIENT_CAPACITY

Symptom: 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, or launch a smaller type.

Cause: 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.

Resolution:

1. Retry the same request later.
2. Or choose a smaller type, or a type of another kind. See Instance types.

Start or change-type refused with PRODUCT_UNAVAILABLE

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

Cause: 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.

Resolution:

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.

GUEST_PRESENT is IMPAIRED

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

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

Resolution:

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

See Instance health checks.

Health checks show INSUFFICIENT_DATA

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

Cause: 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.

Resolution:

1. Wait a few minutes. If the machine comes back, the checks return to OK.
2. 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.
3. 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.

System clock synchronized: no

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

Cause: 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.

Resolution:

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

See Guest environment.

Can’t connect over SSH

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

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

Resolution:

1. Check the user name. Use the instance’s loginUser from get-instance, not root.
2. Check the key. Use the private key of the key pair the instance was launched with.
3. 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.
4. 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.
5. Check that the instance is RUNNING and its availability is AVAILABLE.

Pod networking broken between cloned instances

Symptom: 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.

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

Resolution:

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.

Related

• Status reasons
• Error codes
• Troubleshoot storage
• Troubleshoot networking