Create reservations for VM instances in a specific zone, using custom or predefined machine types, with or without additional GPUs or local SSDs, to ensure resources are available for your workloads when you need them. After you create a reservation, you begin paying for the reserved resources immediately and they remain available for your project to use indefinitely until the reservation is deleted.
Use reservations to ensure that your project has resources for future increases in demand, including planned or unplanned spikes, migrating large number of VMs, backup and disaster recovery, or for planned growth and buffer.
When you no longer need a reservation, delete the reservation to stop incurring charges for it. Because reservations consume resources just like normal VMs, each reservation is charged based on existing On-Demand rates, which include Sustained Use Discounts, and are eligible for Committed Use Discounts.
Before you begin
- If you want to use the command-line examples in this guide:
- Install or update to the latest version of the gcloud command-line tool.
- Set a default region and zone.
- If you want to use the API examples in this guide, set up API access.
Benefits
Reservations provide the following benefits:
- Reserve machines so that they are always available even if you do not use them immediately.
Create a reservation at any time and delete it any time to stop paying for it.
Reservations are billed in the same way and at the same rate as the resources that they are reserving. As such, reserved resources qualify for committed and sustained use discounts.
Limitations and restrictions
Reservations have the following limitations and restrictions:
- Reservations apply only to Compute Engine, Cloud Dataproc, and Google Kubernetes Engine VM usage.
- Reservations do not apply to
f1-microorg1-smallmachine types, preemptible VMs, sole tenant nodes, or other services not listed above like Cloud SQL and Dataflow. - You can reserve up to 1000 VM instances per reservation.
- You must have sufficient quota in your project for the resources you are reserving. If the reservation is successful, quota for that resource will be charged accordingly.
- Resources are allocated when the reservation is created. If there aren't enough resources in the zone at the time of the request, the reservation will fail with an insufficient capacity error.
- When combined with a committed use discount:
- For committed use discounted pricing for GPUs and local SSDs, a reservation must be created when purchasing the commitment.
- If the reservation is attached to a committed use discount, the reservation cannot be deleted.
- You can only buy a 1-year commitment on K80 GPUs.
- Reservations that are not attached to a committed use discount can be held for any duration, but the same minimum charge of 1 minute applies as for regular instances.
How reservations work
Create reservations to reserve the VM instances you need. Once created, reservations ensure that those resources are always available for you to use. During the creation process, you can choose how a reservation is used. For example, you can choose for a reservation be automatically applied to any new or existing instances that match the reservation's properties (the default behavior), or specify that only a specific VM instance can consume a reservation.
In all cases, a VM instance can only use a reservation if its properties exactly match the prorperties of the reservation. Specifically, for an instance to consume a reservation, the instance must be in the same zone and have the same vCPU, minimum CPU platform, memory, GPU, and local SSD properties as the reserved instances.
If a VM instance does match a reservation's properties, the default behavior is
for all existing and new VM instances to consume the reservation automatically
unless otherwise specified. For example, by default, if you create a reservation
for 10 custom-8-10240 instances, and you already have 5 matching
custom-8-10240 instances, then those 5 instances will consume 5 of the
reservations. If you create an additional 3 matching instances, then another 3
reservations are consumed.
You can override this default behaviour by specifying certain options when creating reservations and instances.
- To create a reservation that should not be consumed automatically, use the
specificReservationRequiredoption. These reservations can now only be used if you explicitly specify the reservation during instance creation. - To specify that an instance should consume a reservation, use the
reservationAffinityoption . You can specify that an instance automatically consume any matching reservation, do not automatically consume from matching reservations, or only consume from a specific reservation.
If you stop or delete an instance that is using a reservation, the instance no longer counts against the reservation and the reserved resources are available again.
If you delete a reservation but do not delete the instances that are using the reserved resources, the instances persist and you pay for them as usual.
Creating a reservation
Create a reservation for VM instances using the gcloud command-line
tool or the API. It is not possible to create a reservation in the console. By
default, any VM instances that match a reservation will automatically consume
that reservation. To create a reservation that is not consumed automatically,
use the specificReservationRequired option.
gcloud
Use the gcloud beta compute reservations create
command to create a new reservation.
gcloud beta compute reservations create [RESERVATION_NAME] \
--machine-type=[MACHINE_TYPE] \
--vm-count=[NUMBER_OF_VMS] \
--zone=[ZONE] \
--accelerator=count=[NUMBER_OF_ACCELERATORS],type=[ACCELERATOR_TYPE] \
--local-ssd=size=[SIZE_IN_GB],interface=[INTERFACE] \
--require-specific-reservation
Where:
[RESERVATION_NAME]is the name of the reservation to create.[MACHINE_TYPE]is the machine type. For example,n1-standard-1. For custom machine types, use the formatcustom-[CPUS]-[MEMORY]where:[CPUS]is the number of vCPUs.[MEMORY]is the total memory for this instance. Memory must be a multiple of 256 MB and must be supplied in MB; for example, 5 GB of memory is 5120 MB:custom-4-5120. For a full list of restrictions, read the Specifications for custom machine types.
[NUMBER_OF_VMS]is the quantity of VM instances to reserve.[ZONE]is the zone in which to reserve resources.[NUMBER_OF_ACCELERATORS]is the number of GPUs to add, per instance.[ACCELERATOR_TYPE]is the type of accelerator.[SIZE_IN_GB]is the amount in GB of the local SSD to attach to each instance. The amount must be a multiple of 375.[INTERFACE]is the type of interface the local SSD should use. Valid options are:scsiandnvme.
Optionally, add the --require-specific-reservation flag to indicate
that only VM instances that explicitly targets this reservation can use it.
See How reservations work for more information
about configuration options for consuming reserved resources.
For example, to make a reservation in us-central1-a that can only be
used when this reservation is specifically targeted, use a command
similar to the following. This example reserves 10 custom machines, each
with 8 CPUs, 10 GB of memory, 2 V100 GPUs, and 375 GB local SSD:
gcloud beta compute reservations create my-reservation \
--machine-type=custom-8-10240 \
--vm-count=10 \
--accelerator=count=2,type=nvidia-tesla-v100 \
--local-ssd=size=375,interface=scsi \
--zone=us-central1-a \
--require-specific-reservation
To see a list of all available flags, see the
gcloud beta compute reservations create
reference.
API
In the API, construct a POST request to the
reservations.insert
method. In the request body, include the following parameters:
POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/reservations
{
"name":"[RESERVATION_NAME]",
"specificReservation":{
"count":"[NUMBER_OF_VMS]",
"instanceProperties":{
"machineType":"[MACHINE_TYPE]",
"guestAccelerators":[
{
"acceleratorCount":"[NUMBER_OF_ACCELERATORS]",
"acceleratorType":"[ACCELERATOR_TYPE]"
}
],
"localSsds":[
{
"diskSizeGb":"[SIZE_IN_GB]",
"interface":"[INTERFACE]"
}
]
}
}
}
Where:
[PROJECT_ID] is the project ID for the request.[ZONE]is the zone in which to reserve resources.[RESERVATION_NAME]is the name of the reservation that you are creating.[NUMBER_OF_VMS]is the quantity of VM instances to reserve.[MACHINE_TYPE]is a predefined or custom machine type. For example,n1-standard-1. For custom machine types, use the formatcustom-[CPUS]-[MEMORY]where:[CPUS]is the number of vCPUs.[MEMORY]is the total memory for this instance. Memory must be a multiple of 256 MB and must be supplied in MB; for example, 5 GB of memory is 5120 MB:custom-4-5120. For a full list of restrictions, read the Specifications for custom machine types..
[NUMBER_OF_ACCELERATORS]is the number of GPUs to add, per instance.[ACCELERATOR_TYPE]is the type of accelerator.[SIZE_IN_GB]is the amount in GB of the local SSD to attach to each instance. The amount must be a multiple of 375.[INTERFACE]is the type of interface the local SSD should use. Valid options are:scsiandnvme.
Optionally, include the specificReservationRequired boolean field
to specify that only VM instances that specifically target this reservation
by name can use this reservation. See
How reservations work
for more information about configuration options for using the instances in
your reservations.
For example, to reserve resources in us-central1-a that can only be
consumed when this reservation is specifically targeted, construct a request
similar to the following. This example reserves 10 custom machines, each
with 8 CPUs, 10 GB of memory, 2 NVIDIA® Tesla® V100 GPUs, and 375 GB
local SSD:
POST https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/reservations
{
"name": "reservation-1",
"specificReservation":
{
"count": "10",
"instanceProperties":
{
"machineType": "custom-8-10240",
"guestAccelerators":
[
{
"acceleratorCount": 2,
"acceleratorType": "nvidia-tesla-v100"
}
],
"localSsds":
[
{
"diskSizeGb": "375",
"interface": "SCSI"
}
]
}
},
"specificReservationRequired": true
}Consuming reserved instances
When you create an instance, you choose whether the instance uses any available matching reservation (default), uses a specific reservation, or uses no reservation at all, by setting the instance's reservation affinity flag. For an instance to consume from a specific reservation, that reservation must be created with the corresponding specific reservation required flag. See How reservations work for more information.
Consuming instances from any reservation
In this model, existing and newly created instances automatically count against the reservation if those instance's properties match the reserved instance's properties. This model is useful when you create and delete lots of VMs and you want the reservations to be utilized whenever possible.
When creating your reservations, exclude the --require-specific-reservation
flag so that instances can consume from these reservation without explicitly
targeting them.
gcloud
Create an open reservation.
gcloud beta compute reservations create reservation-01 \
--machine-type=n1-standard-32 \
--vm-count=2 \
--zone=us-central1-a
Create a VM instance that targets "any" open reservation and that matches the reservation's instance properties.
gcloud compute instances create instance-1 \ --machine-type=n1-standard-32 \ --zone=us-central1-a \ --reservation-affinity=any
API
Create an open reservation.
POST https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/reservations
{
"name":"reservation-01",
"specificReservation":{
"count":"2",
"instanceProperties":{
"machineType":"n1-standard-32"
}
},
"specificReservationRequired": false
}
Create a VM instance that targets any open reservation and that matches the reservation's instance properties.
POST https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/instances
{
"machineType": "zones/us-central1-a/machineTypes/n1-standard-32",
"name": "instance-1",
"reservationAffinity":
{
"consumeReservationType": "ANY_RESERVATION"
},
...
}
Consuming instances from a specific reservation
In this model, only new instances that target a specific reservation by name consume that reservation. This model is useful when you want to hold a certain amount of capacity as backup for special events.
To create a reservation that can be used only by instances that
target the reservation by name, include the
--require-specific-reservation flag when creating the reservation. Then
create VMs that target that
reservation using the --reservation-affinity=specific and
--reservation=[RESERVATION_NAME] flags.
For example, create a targeted reservation named reservation-01 and then
create an instance that uses up resources from that reservation.
gcloud
Create a reservation with resources that can only be used by instances that specifically target this reservation by name.
gcloud beta compute reservations create reservation-02 \
--machine-type=n1-standard-32 \
--vm-count=10 \
--zone=us-central1-a \
--require-specific-reservation
Create a VM instance that targets the reservation by name and that matches the reservation's instance properties.
gcloud beta compute instances create instance-2 \
--machine-type=n1-standard-32 \
--zone=us-central1-a \
--reservation-affinity=specific \
--reservation=reservation-02
API
Create a reservation with resources that can only be used by instances that specifically target this reservation by name.
POST https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/reservations
{
"name":"reservation-02",
"specificReservation":{
"count":"10",
"instanceProperties":{
"machineType":"n1-standard-32"
}
},
"specificReservationRequired": true
}
Create a VM instance that targets the reservation by name and that matches the reservation's instance properties.
POST https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/instances
{
"machineType": "zones/us-central1-a/machineTypes/n1-standard-32",
"name": "instance-2",
"reservationAffinity":
{
"consumeReservationType": "SPECIFIC_RESERVATION",
"key": "googleapis.com/reservation-name",
"values":
["reservation-02"
]
},
...
}Creating instances without consuming reservations
To avoid consuming resources from any reservation, set the reservation affinity flag to "none" when creating the VM.
gcloud
Create an instance which does not consume from a reservation.
gcloud beta compute instances create instance-3 --reservation-affinity=none
API
Create an instance which does not consume from a reservation.
POST https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/instances
{
"machineType": "zones/us-central1-a/machineTypes/n1-standard-16",
"name": "instance-3",
"reservationAffinity":
{
"consumeReservationType": "NO_RESERVATION"
},
...
}Listing and describing reservations
You can list your reservation using the gcloud command-line tool or the
API.
gcloud
List your reservations with the
gcloud beta compute reservations list
command:
gcloud beta compute reservations list [--filter="zone:('[ZONE]')"]
Name InUse Count Zone
reservation-04 25 50 us-central1-a
reservation-05 0 100 us-central1-b
Describe your reservations with the
gcloud beta compute reservations describe
command:
gcloud beta compute reservations describe [RESERVATION_NAME] --zone=[ZONE]
creationTimestamp: '2019-04-01T08:29:10.210-07:00'
id: '702162498650398927'
kind: compute#reservation
name: reservation-04
selfLink: https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/reservations/reservation-04
selfLinkWithId: https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/reservations/702162498650398927
specificReservation:
count: '50'
inUseCount: '25'
instanceProperties:
machineType: n1-standard-1
specificReservationRequired: true
zone: https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a
You can use the count and inUseCount values to determine the utilization of
your reservation. In this example 50 resources have been reserved and 25 of them
are currently being used.
API
In the API, list your reservations by making a GET request to the
reservations.list method.
GET https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/reservations
Describe a reservation by calling the reservations.get method.
GET https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/reservations/[RESERVATION_NAME]
{
"id": "702162498650398927",
"creationTimestamp": "2019-04-01T08:29:10.210-07:00",
"selfLink": "https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/reservations/reservation-04",
"selfLinkWithId": "https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a/reservations/702162498650398927",
"zone": "https://www.googleapis.com/compute/beta/projects/my-project/zones/us-central1-a",
"name": "reservation-04",
"specificReservationRequired": false,
"kind": "compute#reservation",
"specificReservation": {
"instanceProperties": {
"machineType": "n1-standard-32"
},
"count": "50",
"inUseCount": "25"
}
}
You can use the count and inUseCount values to determine the utilization
of your reservation. In this example 50 resources have been reserved and 25
of them are currently being used.
Modifying reservations
You can resize or delete a reservation if it is not attached to a commitment.
Resizing a reservation
You can resize the number of VMs in a reservation that is not tied to a
commitment by using the gcloud command-line tool or the API.
gcloud
Resize your reservation using
gcloud beta compute reservations update
cmd. For example:
Create a reservation for 2 VMs:
gcloud beta compute reservations create reservation-01 \
--machine-type=n1-standard-32 \
--zone=us-central1-a \
--vm-count=2
Resize the reservation from 2 to 10 VMs:
gcloud beta compute reservations update reservation-01 \
--zone=us-central1-a \
--vm-count=10
API
In the API, construct a POST request to the
reservations.resize
method and include the new specificSkuCount in the request body. The following
request body updates the reservation's VM count to 10.
POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/reservations/[RESERVATION_NAME]/resize
{"specificSkuCount": "10"}
The update request will succeed if there are enough resources in the target zone, and sufficient quota in the target region, at the time of the request.
Deleting a reservation
You can delete reservations that are not tied to a commitment by using the
gcloud command-line tool or the API.
gcloud
You can release reservations by using the delete command:
gcloud beta compute reservations delete [RESERVATION_NAME] --zone [ZONE]
API
In the API, construct a DELETE request to the
reservation.delete
method.
DELETE https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/reservations/[RESERVATION_NAME]
Once the delete command completes successfully, you will no longer be charged for the reservation and the resources will no longer be reserved for you. Deleting a reservation has no effect on any running instances that were tied to that reservation; you are still charged for those instances.
Combining reservations with Committed Use Discounts
A Committed Use Discount provides a 1- or 3-year discounted price agreement, but it does not reserve capacity in a specific zone. A reservation ensures that capacity is held in a specific zone even if the reserved VMs are not running. By combining a reservation with a commitment, you can get discounted, reserved resources.
By default, when you create a reservation, any applicable committed use discounts for cores and memory will automatically apply to your VM instances. However, to get committed use discount rates for GPUs and local SSDs, you must create a reservation for those resources when purchasing the commitment.
Once you purchase a commitment, it is not possible to cancel it. See Committed use discounts for more information.
Purchasing a commitment for GPUs or local SSDs
To purchase a commitment for GPUs or local SSDs, you must create a reservation
that includes those resources when purchasing your commitment. You can use the
gcloud tool or the API.
You must purchase commitments by specific GPU types. For example, you can purchase GPUs for either Tesla P100s or Tesla V100s, but you cannot purchase commitments for Tesla P100 GPUs and expect to apply them to other GPU types.
The amount of GPUs and local SSDs that you want to reserve must be equal to the amount that you commit to. For example, if you want to reserve 2 V100 GPUs, then you must also commit to 2 V100 GPUs. However, the amount of vCPU and memory can be less than the commitment.
gcloud
Use the gcloud beta compute commmitments create
command to purchase a commitment, and include flags to create a reservation.
For example, the following commitment includes 4 GPUs and a new reservation
for those 4 GPUs to be used across 2 n1-standard-32 instances in
us-central1-a.
gcloud beta compute commitments create commitment-01 \
--region=us-central1 \
--resources=vcpu=96,memory=624GB \
--resources-accelerator=type=nvidia-tesla-v100,count=4 \
--plan 12-month \
--reservation=reservation-01 \
--reservation-zone=us-central1-a \
--machine-type=n1-standard-16 \
--accelerator=type=nvidia-tesla-v100,count=2 \
--vm-count=2
You can also create multiple reservations when purchasing a commitment by using a YAML file.
gcloud beta compute commitments create commitment-01 \
--region=us-central1 \
--resources=vcpu=96,memory=624,local-ssd=750 \
--resources-accelerator=type=nvidia-tesla-v100,count=1 \
--plan 12-month \
--reservations-from-file=[YAML_FILE]
Where [YAML_FILE] contains the reservation properties.
For example, the following YAML file contains 2 reservations. The first
reservation, res-01, contains 1 n1-standard-1 instance with 1 GPU, and
it is a targeted reservation, which means that you must specifically target
that reservation by name to use its reserved instances. The second
reservation, res-02, contains 1 n1-standard-1 VM instance with 2 types
of attached local SSDs.
- reservation: res-01
reservation_zone: us-central1-a
require_specific_reservation: true
vm_count: 1
machine_type: n1-standard-1
accelerator:
- count: 1
type: nvidia-tesla-v100
- reservation: res-02
reservation_zone: us-central1-a
vm_count: 1
machine_type: n1-standard-1
local_ssd:
- interface: scsi
size: 375
- interface: nvme
size: 375
API
Use the regionCommitments.insert
API and include the reservations field to define the reservation's
properties. For example, the following commitment includes 4 GPUs and a
reservation for those 4 GPUs to be used across 2 instances in
us-central1-a.
POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/commitments
{
"name": "commitment-01",
"plan": "TWELVE_MONTH",
"resources":
[
{
"amount": "96",
"type": "VCPU"
},
{
"amount": "638976",
"type": "MEMORY"
},
{
"acceleratorType": "nvidia-tesla-v100",
"amount": "4",
"type": "ACCELERATOR"
}
],
"reservations":
[
{
"name": "reservation-01",
"specificReservation":
{
"count": "2",
"instanceProperties":
{
"guestAccelerators":
[
{
"acceleratorCount": 2,
"acceleratorType": "nvidia-tesla-v100"
}
],
"machineType": "n1-standard-8"
}
},
"specificReservationRequired": false,
"zone": "us-central1-a"
}
]
}The commitment will be successfully created only if there are enough resources in the target zone, and sufficient quota, at the time of the request.
When you create a commitment with an attached reservation, you cannot delete the reservation for the duration of the commitment. When your commitment expires, Compute Engine automatically deletes any attached reservations.
Modifying reservations that are attached to commitments
If a commitment has one or more reservations with GPUs or local
SSDs, you can use the gcloud tool or the API to transfer GPUs or local SSDs
across those reservations. For example, you might move GPUs from one reservation
to a second, new reservation.
Limitations:
- You can only move resources between two reservations, where one is the source reservation and the other is the destination. The source reservation must already exist; the destination can be an existing or new reservation.
- The source and destination reservations must be in the same zone.
- You cannot modify the resource properties in existing reservations; you can only transfer existing resources from one reservation to another.
- The total amount of GPUs and local SSDs must remain constant.
You can only change 100 VMs per request. If you want to update more, you can call the API multiple times or reach out to Google Cloud Support.
gcloud
Use the gcloud beta compute commitments update-reservations
command.
Create a commitment with one reservation: res-1 has 4 n1-standard-1
instances each with 1 P100 GPU (4 vCPUs and 4 P100 GPUs). The total reserved
resources includes 4 P100 GPUs.
gcloud beta compute commitments create my-commitment-with-reservations \
--region=asia-east1 \
--resources=vcpu=10,memory=32GB \
--resources-accelerator=type=nvidia-tesla-p100,count=4 \
--plan 12-month \
--reservations-from-file=one-reservation.yaml
Where one-reservation.yaml contains:
- reservation: res-1
reservation_zone: asia-east1-a
require_specific_reservation: true
vm_count: 4
machine_type: n1-standard-1
accelerator:
- count: 1
type: nvidia-tesla-p100
Update the commitment to transfer some resources from res-1 to a new,
second reservation, res-2. In this example:
- Modify
res-1to have 2n1-standard-1instance each with 2 P100 GPUs (2 vCPU and 2 P100 GPUs). - Add
res-2to have 2n1-standard-2instances each with 1 P100 GPU. (4 vCPUs and 2 P100 CPUs).
The total number of reserved GPUs within the commitment remains constant at 4.
gcloud beta compute commitments update-reservations my-commitment-with-reservations \
--region=us-central1 \
--reservations-from-file=two-reservations.yaml
Where two-reservations.yaml contains:
- reservation: res-1
reservation_zone: asia-east1-a
require_specific_reservation: true
vm_count: 2
machine_type: n1-standard-1
accelerator:
- count: 1
type: nvidia-tesla-p100
- reservation: res-2
reservation_zone: asia-east1-a
require_specific_reservation: true
vm_count: 2
machine_type: n1-standard-2
accelerator:
- count: 1
type: nvidia-tesla-p100
API
Use the regionCommitments.updateReservations
method.
Create a commitment with a reservation:
res-1has 4n1-standard-1instances each with 1nvidia-tesla-p100GPU (4 vCPUs and 4 P100 GPUs).
The total reserved resources includes 4 P100 GPUs.
POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/us-central1/commitments
{
"name": "my-commitment-with-reservation",
"plan": "TWELVE_MONTH",
"reservations":
[
{
"name": "res-1",
"specificReservation":
{
"count": "4",
"instanceProperties":
{
"guestAccelerators":
[
{
"acceleratorCount": 1,
"acceleratorType": "nvidia-tesla-p100"
}
],
"machineType": "n1-standard-1"
}
},
"specificReservationRequired": true,
"zone": "asia-east1-a"
}
],
"resources":
[
{
"amount": "10",
"type": "VCPU"
},
{
"amount": "32768",
"type": "MEMORY"
},
{
"acceleratorType": "nvidia-tesla-p100",
"amount": "4",
"type": "ACCELERATOR"
}
]
}
Update the commitment to transfer some resources from res-1 to a new,
second reservation, res-2. In this example:
- Modify
res-1to have 2n1-standard-1instance each with 2 P100 GPUs (2 vCPU and 2 P100 GPUs). - Add
res-2to have 2n1-standard-2instances each with 1 P100 GPU. (4 vCPUs and 2 P100 CPUs).
The total number of reserved GPUs within the commitment remains constant at 4.
POST https://www.googleapis.com/compute/staging_alpha/projects/[PROJECT_ID]/regions/us-central1/commitments/commitment-with-two-reservations/updateReservations
{
"reservations":
[
{
"name": "res-1",
"specificReservation":
{
"count": "2",
"instanceProperties":
{
"guestAccelerators":
[
{
"acceleratorCount": 1,
"acceleratorType": "nvidia-tesla-p100"
}
],
"machineType": "n1-standard-1"
}
},
"specificReservationRequired": true,
"zone": "asia-east1-a"
},
{
"name": "res-2",
"specificReservation":
{
"count": "2",
"instanceProperties":
{
"guestAccelerators":
[
{
"acceleratorCount": 1,
"acceleratorType": "nvidia-tesla-p100"
}
],
"machineType": "n1-standard-2"
}
},
"specificReservationRequired": true,
"zone": "asia-east1-a"
}
]
}
Viewing usage reports
You can export detailed reports of your Compute Engine usage to a Cloud Storage bucket using the usage export feature. See Viewing usage reports for instructions.
Used resources appear on usage reports as normal vCPU, memory, GPU, and local SSD resource usage. Unused resources appear as reserved resource usage; these usage report entries have reservation resource URIs with the following format:
https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/reservations/[RESERVATION_NAME]
For example:
Report Date,MeasurementId,Quantity,Unit,Resource URI,ResourceId,Location 2019-03-31,com.google.cloud/services/compute-engine/VmimageN1StandardCore,1207797,seconds,https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/reservations/[RESERVATION_NAME],[RESOURCE_ID],[ZONE] 2019-03-31,com.google.cloud/services/compute-engine/VmimageN1StandardRam,4.86323E+15,byte-seconds,https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/reservations/[RESERVATION_NAME],[RESOURCE_ID],[ZONE] 2019-03-31,com.google.cloud/services/compute-engine/VmimageN1StandardRam,6.82177E+15,byte-seconds,https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/[INSTANCE_NAME],[RESOURCE_ID],[ZONE] 2019-03-31,com.google.cloud/services/compute-engine/VmimageN1StandardCore,1694204,seconds,https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/[INSTANCE_NAME],[RESOURCE_ID],[ZONE] ...
Reservation billing
Reservations are billed at the same rate as the resources that they are reserving. Sustained use discounts, committed use discounts and custom pricing apply as they would to regular VMs.
Take the following example:
- You have a 3 vCPU commitment in
us-central1 - You are running 5 vCPUs in
us-central1-a - You have a 10 vCPU reservation in
us-central1-a
You will be billed as follows:
| Covered by | # of vCPUs |
|---|---|
| Committed Use Discount price | 3 |
| On-demand price (2 vCPU used reservations + 5 vCPU unused reservations) | 7 |
What's next
- Learn more about committed use discounts
