Troubleshoot reservation consumption

This document describes how to resolve issues with consuming reservations of Compute Engine zonal resources.

Difficulty tracking reservation consumption

Issue: It's not possible to track which VMs are consuming a reservation, even though you can view how many VMs are consuming a reservation by verifying the reservation consumption.

Resolution: If you can successfully create a VM that targets a specific reservation, then the VM is consuming the reservation specified in the affinity property (reservationAffinity) of the VM. Otherwise, creating the VM fails because the the properties don't match or there are no available resources in the VM's zone.

For more information about tracking reservations consumption, see Verify reservations consumption.

Fewer VMs available for consumption

Issue: The number of physically reserved VMs (the assuredCount field) doesn't match the number of reserved VMs specified in a reservation (the count field). This means that fewer VMs are reserved for your project and any projects with which a shared reservation is shared.

This issue can occur for one or more of the following reasons:

  • A shared reservation's consumer project was suspended or migrated to another organization. In this case, Compute Engine decreases the assuredCount field by the number of VMs that the consumer project is consuming.

  • The project in which the reservation was created was suspended. In this case, Compute Engine sets the assuredCount field to 0.

  • A host error impacted the reservation.

Resolution: Unless the project in which the reservation was created was suspended, Compute Engine makes best effort to automatically resolve a discrepancy between the assuredCount and count fields in a reservation within 24 hours. Additionally, until this discrepancy is resolved, Google Cloud bills you only for the physically reserved capacity.

Issues for VMs not consuming reservations

If a VM can't consume a reservation, then it might be due to one or more of the following issues:

This section describes how to identify each of these issues, resolve each of them, and verify reservations consumption.

Mismatched VM properties

Issue: A VM can't consume a reservation with different VM properties.

To identify which properties aren't matching between the VM and reservation, view the properties of the reservation and the VM by doing the following:

  1. View the details of the reservation

  2. View the details of the VM

Then, compare the two outputs to verify that the following properties exactly match:

  • project

    • If the reservation is shared with multiple projects (specifically, if the reservation has theshareType field set to SPECIFIC_PROJECTS), then the VMs can be located in the project where the reservation was created (the owner project), or in any projects that the reservation is shared with (consumer projects).

  • zone

  • machineType

  • guestAccelerators.acceleratorType (if any)

  • guestAccelerators.acceleratorCount (if any)

  • minCpuPlatform

    • The VM and reservation must have the exact same minCpuPlatform configuration. For example, setting minCpuPlatform to Intel Broadwell when creating a VM won't match the minCpuPlatform value of Automatic within a reservation.

  • localSsds.interface (if any)

    • The reservation and VM must have the same number of local SSD disks with a matching localSsds.interface property for each local SSD disk.

  • resourcePolicies (if any)

  • locationHint (if any)

    • Only if a reservation specifies the locationHint field. You can specify the locationHint field only when creating VMs using REST.

Resolution: After identifying the properties that don't match, try one of the following:

  • If the VM properties don't match the reservation, then do one of the following:

    • Delete the VM and create a new VM with properties that match the reservation's properties.

    • Update the VM to match the reservation's properties.

  • If the reservation's properties are supposed to match the VM's properties, then delete the reservation and create a new reservation that matches the VM's properties. Optionally, you can create a specific reservation. When creating VMs to consume a specific reservation, you encounter errors if the VM's properties don't match the reservation's properties.

After updating the VM or creating a new reservation, check if the VM is consuming the reservation by verifying the reservation consumption.

Reservation affinity is incorrect

Issue: The reservation affinity of the VM is misconfigured. The reservation affinity of a VM controls the reservations that a VM can consume. To check your VM's reservation affinity, do the following:

  1. View the details of a reservation and verify if the reservation is an automatically consumed or specific reservation. For more information, see Consumption type.

  2. View the details of the VM and verify the reservation affinity.

Resolution: If the reservation affinity of the VM and the reservation don't match, then do one of the following:

  • Create a new VM with a reservation affinity property that matches the reservation's type.

  • Update the reservationAffinity property in the VM to specify whether the VM can consume any matching reservation or a specific reservation. To finalize the VM's update, you must restart the VM.

To check if the VM is consuming the reservation, see Verify reservation consumption.

Reservation is already fully consumed

Issue: The number of VMs consuming this reservation matches the reservation's total number of reserved VMs. This indicates that the reservation is fully consumed.

Resolution: To verify if the reservation is fully consumed, view the details of the reservation, and then verify that the number of VMs consuming the reservation matches the total number of reserved VMs in the reservation.

If the reservation is fully consumed, then try one of the following:

If the reservation is not fully consumed but the VM is not consuming the reservation, then you can further troubleshoot the issue by doing the following:

  1. Create a specific reservation with matching properties.

  2. Create a VM to consume the reservation. If the VM and the reservation properties don't match, then creating the VM fails.

Resource quota exceeded for shared reservations

Issue: A VM isn't consuming a shared reservation because your project doesn't have sufficient quota for the resources that you're trying to consume.

Resolution: Shared reservations have additional quota requirements. If you need to increase quota in your project to consume the reserved resources, then see Request a higher quota in the Cloud Quotas documentation.

VM count not restored after stopping or deleting a VM

Issue: If you stop, suspend, or delete a VM that is consuming a reservation, then the operation must complete before the VM no longer counts against the reservation, and the previously consumed resources are again available for consumption.

Resolution: Wait for a few minutes for the stop, suspend, or delete operation on the VMs to complete. Then, to verify that the stopped, suspended, or deleted VMs no longer count against the reservation, check the total number of consumed VMs in the reservation by using one of the following methods:

  • Recommended: Monitor the reservation and look for a change in the measurements of the reservation.

  • View the details of the reservation and check if the value of the inUseCount field decreased. If its value didn't decrease, then one or more VMs have started consuming the reservation while the stop, suspend, or delete operation was completing.

VM unintentionally consuming reservations

Issue: When you create reservations that are automatically consumed (default), a VM might unintentionally consume these reservations.

Resolution: To avoid that one or more VMs unintentionally consume a reservation, do one of the following: