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

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:

{

    "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.