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 given the required type of access in a policy written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted 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
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
When an underlying Oracle Cloud Infrastructure component needs to undergo maintenance, you are notified before the impact to your VM instances.
During an infrastructure maintenance event, the instance is stopped on the physical VM host that needs maintenance, migrated to a healthy VM host, and then rebooted. If you have an alternate process to recover your instances, you can optionally configure your instances to remain stopped after they are migrated to healthy hardware.
If your VM instances are scheduled for a maintenance reboot, you can proactively reboot (or stop and start) your instances at any time before the scheduled reboot. This let 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:
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.
- 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.
- In the Console, append "/search" to the end of your base Console URL. For example, https://console.us-ashburn-1.oraclecloud.com/search.
- Click Select Sample Query, and then click Query for all instances which have an upcoming scheduled maintenance reboot.
- Click Search.
If you choose not to reboot before the scheduled time, then Oracle Cloud Infrastructure will reboot and 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:
- Open the navigation menu. Under Core Infrastructure, go to Compute and click Instances.
- Click the instance that you're interested in.
Click one of the following actions:
- Start: Restarts a stopped instance.
Stop: Gracefully shuts down the instance by sending a shutdown command to the operating system.Note
If the applications that run on the instance take a long time 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.
- Reboot: Gracefully reboots the instance by sending a shutdown command to the operating system, and then powers the instance back on.
Using the API
For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.
Use the InstanceAction operation to restart an instance.
The following actions are only available using the API: