1 00:00:01,140 --> 00:00:04,940 Troubleshoot Azure VM Deployment Failures. 2 00:00:04,940 --> 00:00:08,320 Perhaps the most common two failures you may see 3 00:00:08,320 --> 00:00:13,000 occasionally with Azure VMs happen, first, when you're 4 00:00:13,000 --> 00:00:15,980 attempting to either create, restart, 5 00:00:15,980 --> 00:00:22,540 resize or perform some platform‑level change with your Azure VMs. For example, 6 00:00:22,540 --> 00:00:27,740 you might occasionally encounter allocation failed errors. 7 00:00:27,740 --> 00:00:33,010 What this normally points to is a capacity issue on Microsoft's side, and it's a 8 00:00:33,010 --> 00:00:37,480 reminder for us as hybrid cloud administrators that because we're never going to 9 00:00:37,480 --> 00:00:40,360 get within miles or kilometers of the Microsoft. 10 00:00:40,360 --> 00:00:41,940 Azure data centers, 11 00:00:41,940 --> 00:00:46,070 it's particularly important to be aware of the visibility that Microsoft 12 00:00:46,070 --> 00:00:50,440 does give. And here, the main pointer I want you to think of are tools 13 00:00:50,440 --> 00:00:55,720 like Azure Monitor activity log and also the resource health tool where 14 00:00:55,720 --> 00:00:57,800 you can get validation that yes, 15 00:00:57,800 --> 00:01:03,010 in fact, Microsoft may be having issues in that region and that data 16 00:01:03,010 --> 00:01:08,590 center. And I found in my experience that trying or retrying the operation 17 00:01:08,590 --> 00:01:13,840 after a pause can generally work past those issues. 18 00:01:13,840 --> 00:01:17,250 Another type of area you might see with creating, restarting, 19 00:01:17,250 --> 00:01:20,000 resizing Azure VMs is a provisioning failure. 20 00:01:20,000 --> 00:01:24,470 Now, this normally points to things like you're trying to do something that's 21 00:01:24,470 --> 00:01:29,430 just simply not supported. Maybe you're attempting to deploy an Azure VM and 22 00:01:29,430 --> 00:01:32,840 specifying a size that's not available in that region. 23 00:01:32,840 --> 00:01:35,650 This points to the fact that not every Azure 24 00:01:35,650 --> 00:01:37,670 service is available in every region. 25 00:01:37,670 --> 00:01:38,640 Some are, 26 00:01:38,640 --> 00:01:42,020 but many are not, and that definitely goes for 27 00:01:42,020 --> 00:01:45,040 Azure virtual machine image sizes. 28 00:01:45,040 --> 00:01:50,740 This points to your being tied in deeply to the Microsoft Azure docs 29 00:01:50,740 --> 00:01:55,590 and verifying that, in fact, your services are available in those 30 00:01:55,590 --> 00:01:58,380 regions. Remember that if worse comes to worst, 31 00:01:58,380 --> 00:02:01,960 you can file a support ticket with Microsoft Azure support. 32 00:02:01,960 --> 00:02:05,510 All right, so that's one VM deployment failure category. 33 00:02:05,510 --> 00:02:10,300 Another would be a validation issue with your deployment template. 34 00:02:10,300 --> 00:02:14,160 You could be using Azure Resource Manager JSON templates or 35 00:02:14,160 --> 00:02:18,830 Bicep templates. I've found, again, in my experience, 8 times 36 00:02:18,830 --> 00:02:21,230 out of 10 it's a syntax error, 37 00:02:21,230 --> 00:02:25,040 particularly with the JSON. Maybe you've missed a comma or a 38 00:02:25,040 --> 00:02:27,760 closing curly brace or square bracket. 39 00:02:27,760 --> 00:02:31,220 You also may have something simple like an invalid parameter. 40 00:02:31,220 --> 00:02:34,690 Maybe you're using an allowedValues array. For example, 41 00:02:34,690 --> 00:02:38,750 maybe you have for the location property of a deployment, you've got a 42 00:02:38,750 --> 00:02:43,380 parameter for location, and you've created an allowedValues array that 43 00:02:43,380 --> 00:02:48,310 restricts you to only say East US and East US2. One of your colleagues 44 00:02:48,310 --> 00:02:52,790 attempts to deploy the template by providing, say, West US for a 45 00:02:52,790 --> 00:02:54,300 location parameter value. 46 00:02:54,300 --> 00:02:57,070 Well, that certainly is going to bomb out the deployment. 47 00:02:57,070 --> 00:03:02,680 So, there's that. Lastly, there's circular dependencies. Fortunately, Bicep 48 00:03:02,680 --> 00:03:09,600 handles dependencies much more gracefully in my opinion than does ARM. In ARM 49 00:03:09,600 --> 00:03:13,720 JSON, you have that DependsOn property, but if you're not careful, depending 50 00:03:13,720 --> 00:03:18,140 upon how complex your deployment template is, you could create a circular 51 00:03:18,140 --> 00:03:22,200 loop where you've got a dependency on a resource, which in turn has a 52 00:03:22,200 --> 00:03:26,550 dependency on the first resource, and they just get caught in a terrible 53 00:03:26,550 --> 00:03:27,580 situation there. 54 00:03:27,580 --> 00:03:32,640 So, actually, I think all three of these deal with human error and 55 00:03:32,640 --> 00:03:36,100 speak to factoring and refactoring your templates, 56 00:03:36,100 --> 00:03:40,590 debugging your templates, inviting your colleagues in for code reviews. 57 00:03:40,590 --> 00:03:47,000 And the good news is once you've resolved those, the template should then work in perpetuity going forward.