Stay organized with collections Save and categorize content based on your preferences.
This document gives an overview of resize requests in a managed instance group (MIG). To learn more about other ways to add virtual machine (VM) instances to a MIG, see Add instances to a MIG.
Use MIG resize requests for the following benefits:
Create VMs in the MIG all at once. When resources are available, the MIG creates VMs all at once. This approach helps you avoid charges for partial capacity until all resources become available.
Obtain high-demand resources like GPUs. You can use MIG resize requests with the flex-start or reservation-bound provisioning models. These models give you the following benefits:
You're more likely to obtain GPUs.
You get a discount up to 53% for vCPUs and GPUs.
You can use resize requests in a MIG for the following:
Create VMs as soon as resources are available. You can request to create VMs for workloads that need to run for up to seven days, but can start at any time. When you use resize requests to create VMs as soon as resources are available, the following occurs:
The MIG schedules VM creation as soon as resources are available.
When the MIG creates the requested VMs, the VMs run until their run duration ends or until you delete them. You can't stop or suspend these VMs.
Create VMs by consuming a reservation. You can create VMs by consuming an automatically created (auto-created) reservation for a future reservation in calendar mode. When you use resize requests to consume a reservation, the following occurs:
The MIG creates VMs at or after the reservation start time.
The created VMs run until one of the following occurs:
Compute Engine deletes the reservation at its end time.
You stop, suspend, or delete these VMs.
The following sections explain how MIG resize requests work.
On creationTo create a MIG resize request, specify the following properties:
To define the number of VMs to create, use one of the following properties:
resizeBy: the number of VMs to create. The MIG automatically generates VM names.
instanceNames: a list of VM names. The MIG creates one VM for each name that you specify. This property is in Preview. Use it if your workload requires specific VM names.
requestedRunDuration: how long the VMs must run for. The run duration must be between 10 minutes and seven days. This property is optional. If you use MIG resize requests to create VMs as soon as resources are available, then this property overrides the run duration that is specified in the MIG's instance template.
After you create a MIG resize request, the request goes through different states. The following diagram shows these states:
The states shown in the preceding diagram are as follows:
CREATING: Compute Engine received the resize request, the MIG's target size increases by the number of VMs that are specified in the request, and the MIG creates managed instances that are in a CREATING state. These managed instances represent the VMs that the MIG creates when the resize request succeeds.
ACCEPTED: Compute Engine created and accepted the request. Based on your use case for MIG resize requests, Compute Engine does one of the following:
Create VMs as soon as resources are available. The Dynamic Workload Scheduler schedules VM creation based on availability and the run duration that is specified in the request. If you lack standard or preemptible allocation quota, or if resources are temporarily unavailable, then the Dynamic Workload Scheduler maintains the request until you have sufficient quota and resources become available.
Note: Even though a MIG creates VMs for a resize request only when all the requested capacity is available, in rare cases, the MIG might create only some of the requested VMs but fail to create the remaining ones. If this failure occurs, then the MIG automatically deletes these VMs as soon as possible to minimize unwanted charges. The state of the request remainsACCEPTED and the MIG retries creating the VMs all at once.Create VMs by consuming a reservation. If the auto-created reservation that you're targeting for consumption has reached its start time, then the request transitions to SUCCEEDED. Otherwise, the request persists until the reservation reaches its start time.
SUCCEEDED: the MIG created the requested number of VMs all at once. Based on your use case for MIG resize requests, the following occurs:
When the MIG creates VMs as soon as resources are available, the VMs run until the MIG deletes them at the end of their run duration, or until you delete the VMs. You can't recreate, stop, or suspend the VMs.
When the MIG creates VMs by consuming an auto-created reservation, the VMs run until the reservation period ends, or until you stop, suspend, or delete the VMs.
FAILED: the resize request failed due to a technical error. As a result, Compute Engine decreases the target size of the MIG by the number of requested VMs.
CANCELLED: a user canceled the resize request. When you cancel a resize request, Compute Engine stops the MIG from creating the requested resources. After you cancel a resize request, Compute Engine decreases the MIG's target size by the number of requested VMs and deletes the request after 14 days. Optionally, you can delete the resize request before Compute Engine deletes it.
If you delete a MIG that contains resize requests, then this deletion also removes any resize requests and VMs in the MIG. However, if you delete a MIG when the MIG creates VMs to fulfill a resize request, Compute Engine waits until the MIG has finished creating the requested number of VMs and the state of the resize request transitions to SUCCEEDED before deleting the MIG.
Based on your use case for MIG resize requests, you need quota as follows:
Create VMs as soon as resources are available. You must have sufficient standard or preemptible quota for the resources that you want to request. This requirement is because you use the flex-start provisioning model. If you lack quota, then the request remains pending until you have sufficient quota.
Create VMs by consuming a reservation. You don't need quota in this use case. This requirement is because you use the reservation-bound provisioning model to consume an auto-created reservation for a future reservation in calendar mode.
You don't incur charges when you create, cancel, or delete resize requests in a MIG. Instead, based on your use case for MIG resize requests, you incur charges as follows:
If you use MIG resize requests to create VMs as soon as resources are available, then you incur charges as follows:
Charges begin when the MIG creates the VMs. Google Cloud charges you for the VMs based on Dynamic Workload Scheduler pricing.
Charges end when the MIG deletes the VMs at the end of their run duration, or when you delete the VMs.
If you use MIG resize requests to create VMs by consuming a reservation, then you incur charges as follows:
When the MIG creates the VMs, you don't incur charges again for the consumed reservation resources. You only incur charges for resources the VMs use that aren't part of the reservation, such as disks or IP addresses.
Charges end at the reservation end time. At this time, Compute Engine deletes the reservation and any VMs that consume it. For more information, see the billing for reservations.
The following sections explain the limitations for MIG resize requests.
Limitations for resize requestsMIG resize requests have the following limitations:
You can only use MIG resize requests to obtain the following machine types:
If you use MIG resize requests to create VMs as soon as resources are available, then you can obtain any GPU machine type except A4X.
If you use MIG resize requests to create VMs by consuming a reservation, then you can only obtain A4 or A3 Ultra machine types.
You can only cancel resize requests that are in the ACCEPTED state.
You can only delete a resize request after it succeeds (SUCCEEDED), fails (FAILED), or is canceled (CANCELLED).
For the MIG's instance template, the following limitations apply:
You must specify to stop VMs during host maintenance events.
You can't specify placement policies.
Based on your use case for MIG resize requests, you must specify the following when you create the instance template:
To create VMs as soon as resources are available, you must specify the following:
To delete VMs at the end of their run duration by using the maxRunDuration and instanceTerminationAction fields.
To not use reservations.
To use the flex-start provisioning model (Preview).
To create VMs by consuming an auto-created reservation for a future reservation in calendar mode, you must specify the following:
To delete VMs at the end of the reservation period by using the instanceTerminationAction field.
To use the reservation-bound provisioning model.
For the MIG, the following limitations apply:
In a regional MIG, you can only use the ANY_SINGLE_ZONE target distribution shape.
You must turn off repairs in the MIG.
You must delete the autoscaling configuration.
You can't apply VM configuration updates to the VMs created through resize requests. To prevent automatic updates, set the MIG's update type to opportunistic.
You can't apply the all-instances configuration to VMs created through resize requests.
You can't define per-instance configurations in VMs created through resize requests.
You can only set the standby pool mode of the MIG to manual (default).
If a MIG contains accepted resize requests, then you can't do the following:
You can't add a second instance template to initiate a canary update in the MIG.
You can't change the target size of the MIG.
You can't delete or abandon the managed instances in a CREATING status that the MIG creates for a resize request. To delete those managed instances, you must cancel the resize request.
If you use MIG resize requests to create VMs as soon as resources are available, then you can't recreate, suspend, or stop VMs.
Learn how to create resize requests in a MIG.
Learn how to view, cancel, or delete resize requests in a MIG.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-07 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Resize requests in managed instance groups (MIGs) allow for the creation of GPU virtual machines (VMs) all at once, ensuring you get the exact number of VMs needed for a specific job or time frame."],["When creating a resize request, you must specify the number of VMs (`resizeBy`) and the duration for which they should run (`requestedRunDuration`), typically between 10 minutes and 7 days, after which the MIG automatically deletes the VMs."],["A resize request goes through several states, including `CREATING`, `ACCEPTED`, `SUCCEEDED`, `FAILED`, and `CANCELLED`, with `ACCEPTED` indicating that the request is scheduled for resource allocation, and `SUCCEEDED` meaning all requested VMs have been created."],["Resize requests have several limitations, such as only being applicable to GPU VMs, requiring specific instance template settings (like stopping VMs during host maintenance), and needing the MIG to have repairs turned off and autoscaling deleted."],["There are no direct costs for creating, canceling, or deleting resize requests, but you are charged for the VMs that are successfully created, from their creation until they are deleted, either automatically at the end of their run duration or manually."]]],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4