Stopping and Starting an Instance

You can stop and start an instance as needed to update software or resolve error conditions.

For steps to manage the lifecycle state of instances in an instance pool, see Stopping and Starting the Instances in an Instance Pool.

Stopping or Restarting an Instance Using the Instance's OS

In addition to using the API and Console, you can stop and restart instances using the commands available in the operating system when you are logged in to the instance. Stopping an instance using the instance's OS does not stop billing for that instance. If you stop an instance this way, be sure to also stop it from the Console or API.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  you should work in.

For administrators: The policy in Let users launch Compute instances includes the ability to stop or start an existing instance. If the specified group doesn't need to launch instances or attach volumes, you could simplify that policy to include only manage instance-family, and remove the statements involving volume-family and virtual-network-family.

If you're new to policies, see Getting Started with Policies and Common Policies. For reference material about writing policies for instances, cloud networks, or other Core Services API resources, see Details for the Core Services.

Resource Billing for Stopped Instances

For both VM and bare metal instances, billing depends on the shape that you use to create the instance:

  • Standard shapes: Stopping an instance pauses billing. However, stopped instances continue to count toward your service limits.
  • Dense I/O shapes: Billing continues for stopped instances because the NVMe storage resources are preserved. Related resources continue to count toward your service limits. To halt billing and remove related resources from your service limits, you must terminate the instance.
  • GPU shapes: Billing continues for stopped instances because GPU resources are preserved. Related resources continue to count toward your service limits. To halt billing and remove related resources from your service limits, you must terminate the instance.
  • HPC shapes: Billing continues for stopped instances because the NVMe storage resources are preserved. Related resources continue to count toward your service limits. To halt billing and remove related resources from your service limits, you must terminate the instance.

Stopping an instance using the instance's OS does not stop billing for that instance. If you stop an instance this way, be sure to also stop it from the Console or API.

For more information about Compute pricing, see Compute Pricing. For more information about how instances running Microsoft Windows Server are billed when they are stopped, see How am I charged for Windows Server on Oracle Cloud Infrastructure?.

Recovering a Virtual Machine (VM) During Planned Maintenance

Oracle Cloud Infrastructure performs routine data center maintenance on the physical infrastructure for VM instances. This maintenance includes tasks such as upgrading and replacing hardware or performing maintenance that halts power to the host. When an underlying infrastructure component needs to undergo maintenance, you are notified in advance before the impact to your instances.

During an infrastructure maintenance event, where applicable, Oracle Cloud Infrastructure live migrates Standard VM instances to a healthy physical VM host without disrupting running instances. If a VM instance cannot be live migrated, then the instance is stopped on the physical VM host that needs maintenance, reboot migrated to a healthy VM host, and then restarted. If you have an alternate process to recover the instances, you can optionally configure the instances to remain stopped after they are reboot migrated to healthy hardware.

If VM instances are scheduled for a maintenance reboot, you can proactively reboot (or stop and start) the instances at any time before the scheduled reboot. Proactively rebooting lets you control how and when your applications experience downtime. Customer-managed VM maintenance is supported on Standard and GPU instance shapes, including Oracle-provided platform images and custom images that were imported from outside of Oracle Cloud Infrastructure.

To identify the VM instances that you can proactively reboot, do any of the following things:

Using the Console: To see which instances in the current compartment are scheduled for a maintenance reboot
  1. Open the navigation menu. Under Core Infrastructure, go to Compute and click Instances.

    If the instance has a maintenance reboot scheduled and can be proactively rebooted, a warning icon appears next to the instance name.

  2. Click the instance that you're interested in, and then check the Maintenance Reboot field for the instance. This field displays the date and start time for the maintenance reboot.
Using the API: To see which instances in a compartment are scheduled for a maintenance reboot

Use the ListInstances operation. The timeMaintenanceRebootDue field for the Instance returns the date and start time for the maintenance reboot.

Using Search: To find all instances that are scheduled for a maintenance reboot
  1. In the top navigation bar, click Search for resources, services, and documentation, and then click Advanced Resource Query.
  2. Click Select Sample Query, and then click Query for all instances which have an upcoming scheduled maintenance reboot.
  3. Click Search.

If you choose not to reboot before the scheduled time, then Oracle Cloud Infrastructure will migrate your instances within a 24-hour period after the scheduled time.

An instance is no longer impacted by a maintenance event when the Maintenance Reboot field for the instance is blank.

VM Recovery Due to Infrastructure Failure

When the underlying infrastructure of a VM instance fails due to software or hardware issues, Oracle Cloud Infrastructure automatically attempts to recover the instance.

Standard and GPU VM instances are recovered to another physical VM host using reboot migration. During the reboot, instance properties such as private and ephemeral public IP addresses, attached block volumes, and VNICs are preserved.

Dense I/O VM instances are recovered by rebooting the instance on the same physical host. If recovering a Dense I/O instance on the same physical host isn't possible, Oracle Cloud Infrastructure notifies you to terminate the instance within 14 days. If you don't terminate the instance before the deadline, Oracle Cloud Infrastructure will terminate it. The boot volume and remote attached data volume are preserved.

Oracle Cloud Infrastructure notifies you by email or announcements of any VM infrastructure failure events, with the status of the recovery action that was taken. You can also monitor the instance status metric to stay aware of any unexpected reboots.

Optionally, you can configure your instances to remain stopped after they are recovered.

Hardware Reclamation for Stopped Bare Metal Instances

When a bare metal instance remains in the stopped state for longer than 48 hours, the instance is taken offline and the physical hardware is reclaimed. The next time that you restart the instance, it starts on different physical hardware. There are no changes to the block volumes, boot volumes, and instance metadata, including the ephemeral and public IP addresses.

However, the following properties do change when a bare metal instance restarts on different physical hardware: the MAC addresses and the host serial number. You might also notice changes in the BIOS firmware version, BIOS settings, and CPU microcode. If you want to keep the same physical hardware, do not stop the instance using the Console or the API, SDKs, or CLI. Instead, shut down the instance using the instance's OS. When you want to restart the instance, use the Console or the API, SDKs, or CLI.

This behavior applies to Linux instances that use the following shapes:

  • BM.Standard1.36
  • BM.Standard.B1.44
  • BM.Standard2.52
  • BM.Standard.E2.64

Using the Console

To start an instance
  1. Open the navigation menu. Under Core Infrastructure, go to Compute and click Instances.
  2. Click the instance that you're interested in.
  3. Click Start.
To stop an instance
  1. Open the navigation menu. Under Core Infrastructure, go to Compute and click Instances.
  2. Click the instance that you're interested in.
  3. Click Stop.
  4. By default, the Console gracefully stops the instance by sending a shutdown command to the operating system. After waiting 15 minutes for the OS to shut down, the instance is powered off.

    Note

    If the applications that run on the instance take more than 15 minutes to shut down, they could be improperly stopped, resulting in data corruption. To avoid this, shut down the instance using the commands available in the OS before you stop the instance using the Console.

    If you want to stop the instance immediately, without waiting for the OS to respond, select the Force stop the instance by immediately powering off check box.

  5. Click Stop Instance.
To reboot an instance
  1. Open the navigation menu. Under Core Infrastructure, go to Compute and click Instances.
  2. Click the instance that you're interested in.
  3. Click Reboot.
  4. By default, the Console gracefully restarts the instance by sending a shutdown command to the operating system. After waiting 15 minutes for the OS to shut down, the instance is powered off and then powered back on.

    Note

    If the applications that run on the instance take more than 15 minutes to shut down, they could be improperly stopped, resulting in data corruption. To avoid this, shut down the instance using the commands available in the OS before you restart the instance using the Console.

    If you want to reboot the instance immediately, without waiting for the OS to respond, select the Force reboot the instance by immediately powering off, then powering back on check box.

  5. Click Reboot Instance.