geohernandez
Menu
  • HOME
  • ABOUT
  • CONTACT ME
  • WORK WITH GEO
    • Data Specialist
    • Speaker Events
    • Resume
  • English
    • English
    • EspaƱol
Menu

Database Migration Service – We do not have sufficient capacity for the requested VM size in this region

Posted on March 26, 2022August 16, 2023 by geohernandez

As the title of this post indicates, the Database Migration Service (DMS) could experiment with problems in very rare cases with the capacity to start/create a service due to not having enough resources in a specific region. It is interesting to start explaining why the provisioned number of Virtual Machines (VM) could impact DMS. If we ask Why? The answer is simple: behind the scenes, the VMs represent the “workers” in charge of executing ALL the tasks required by the migration service of DMS.

When you are configuring a new DMS instance, you can choose the Hybrid option, which means that you will be able for using your own machines (on-premises) to execute all the internal tasks associated with the migration process executed by DMS. As you can see in the following image:

In case you select the Hybrid, once the service is deployed and ready, it is mandatory to download and install the “worker” app inside of your machine set up for the migration.

Nonetheless, it is important to remind that Hybrid option is still in Preview stage, so, historically all the migrations have been done through the use of Azure Service mode. It is interesting to mention that only in a very reduced number of cases, we could face problems during the deployment of a new a new DMS due to a lack of VMs. In my case, it happened meanwhile I was working in Germany West Central region which is supported for this service as you can verify in the next link: https://azure.microsoft.com/en-us/global-infrastructure/services/?products=database-migration&regions=germany-north,germany-west-central,europe-north,europe-west

However, every time that I tried to create a new DMS service or start a service already created before, I got this error message:

1
2
3
4
5
6
7
8
9
10
11
12
13
{
 
    "status": "Failed",
 
    "error": {
 
        "code": "DeploymentFailed",
 
        "message": "The provisioning of deployment vm_b4papvh8j25s2f7easmrm4xs for service /subscriptions/xxxxxxxxxxxxx/resourceGroups/xxxxxxxx/providers/Microsoft.DataMigration/services/my-dms failed. State was Failed. VM-b4papvh8j25s2f7easmrm4xs (Microsoft.Compute/virtualMachines): AllocationFailed - Allocation failed. We do not have sufficient capacity for the requested VM size in this region. Read more about improving likelihood of allocation success at http://aka.ms/allocation-guidance Template output evaluation skipped: at least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details."
 
    }
 
}

The previous error is the most important source of information, when you start to review possible reasons associated, always is a good starting point to check if you do not have any quota restrictions in your subscrition for new VMs which is a good reason for getting this error. However, if you have verified and no restriction or the quota is so far to being reached, is feasible that simply the target region has not enough resources to provide the requested VMs, my assumption is that DMS is not a top priority at the time of getting resources(VMs) access for setting up a new service, it is very important to understand that DMS is stopped after 24 hours of inactivity. It means that it uses VMs on-demand and releases them after using them.

You could wait some hours and try to create the service again, hoping that the target region has some VMs available. If this is not an option, my recommendation is to open a ticket for Microsoft people, attaching all the details and explaining in a simple and clear way the necessity of increasing the VMs quota for that region, in my case, once Microsoft technical support contacted me for notifying that quota was increased I was able to create the new DMS without problem as you can see here:

Finally, I would like to give you the last recommendation. If you are going to do a migration, it is a good idea to start the service at least a couple of days before the planed migration date and try to generate smaller fake changes in a way that the Service is still active during the previous hours before migrating, get rid of any possibility of getting the error described in this article and wasting precious time and put in risk the migration.

Category: Azure, Chronicles from the trenches

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search for articles

Recent Posts

  • Quick Guide: BigQuery Service Account Setup Using gcloud
  • The Art of Data Modeling in AI times
  • Getting Started with Snowflake’s Snowpipe for Data Ingestion on Azure

Categories

  • Airflow (1)
  • Azure (6)
  • Azure DevOps (2)
  • Bash script (1)
  • Blog (1)
  • Cassandra (3)
  • Chronicles from the trenches (26)
  • Data Architecture (3)
  • Data Engineering (11)
  • DB optimization (2)
  • Events (2)
  • GIT (1)
  • MySQL (1)
  • Python (7)
  • Snowflake (3)
  • SQL Saturday (1)
  • SSIS (2)
  • T-SQL (5)
  • Uncategorized (2)

Archives

  • May 2025 (1)
  • March 2025 (1)
  • January 2025 (2)
  • October 2024 (1)
  • July 2024 (1)
  • May 2024 (1)
  • December 2023 (1)
  • November 2023 (1)
  • August 2023 (1)
  • June 2023 (1)
  • December 2022 (1)
  • November 2022 (1)
  • July 2022 (1)
  • March 2022 (1)
  • September 2021 (1)
  • May 2021 (1)
  • March 2021 (1)
  • February 2021 (3)
  • December 2020 (1)
  • October 2020 (3)
  • September 2020 (1)
  • August 2020 (1)
  • January 2020 (1)
  • August 2019 (1)
  • July 2019 (1)
  • June 2019 (1)
  • May 2019 (1)
  • April 2019 (1)
  • March 2019 (1)
  • November 2018 (3)
  • October 2018 (1)
  • September 2018 (1)
  • August 2018 (2)
© 2025 geohernandez | Powered by Minimalist Blog WordPress Theme