I need two Azure VMs into different availability zones in the US region.
However when trying to put VM into the availability zone I get an error:
In the azure support console, there is no way to explicitly request the "availability zone" feature.
While doing the "quota increase request" you can only change the number of required VMs, but no way to specify that the issue is caused by absence of "availability zone" permission.
I've already tried the following:
fired 5 "quota increase request" support tickets during the last two weeks, all of them are "approved" but issue is still in place.
contacted azure chat support, who confirmed that the issue caused by the absence of "availability zone" permission and asked to create the same "quota increase request" and describe my problem in the summary. Done, with no success
contacted azure twitter support, who promised to escalate the "quota increase request" + add the description of the problem to it explicitly. Ticket is "approved", issue still in place.
So the question is: how do you unlock the VMs assignment to availability zone in the US East (or US East 2, or any other region).
I am sure it must be a pretty common task, I did it many times within different accounts. But on this particular new account it now seems impossible to do, and I wonder how other developers/administrators tackles this requirement.
I am from the Microsoft for Founders Hub team. Is your issue specific to this VM size and the region? Have you tried to select a different VM size or a different region to see if you get the same error?
Can you also try to run the following az cli command and see what you get?
az vm list-skus --location eastus --size Standard_B1s -o table
Also refer to the following documentation for further details: https://aka.ms/azureskunotavailable
Related
I have a new vm, Operating system Windows (Windows Server 2016 Datacenter).
When I try to enable backup and select new Recovery Service Vault, I get deployment error:
Deployment to resource group test failed.
Additional details from the underlying API that might be helpful: At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.
Resource
vault242/Azure/iaasvmcontainer;iaasvmcontainerv2;test;web01/vm;iaasvmcontainerv2;test;web01
Type
Microsoft.RecoveryServices/vaults/backupFabrics/protectionContainers/protectedItems
Status
Conflict
Status message
{
"status": "Failed",
"error": {
"code": "BMSUserErrorContainerObjectNotFound",
"message": "Item not found"
}
}
Can't find any information for code BMSUserErrorContainerObjectNotFound and why a protected item not created automatically
My apologies for the delay in the response.
Were you able to resolve the issue?
If not, let's review it.
As I understood, you are enabling the Azure VM Back Up by following the next steps:
There could be multiple reasons why you are getting this failure.
Did you perform these steps manually using the Azure Portal? Template deployment? Scripting? I suspect most likely you are doing the template deployment or any kind of scripting and this one is the syntax issue.
Second thought, it was the transmitted issue due to the load of request on the Azure end. In this case, you need to retry the operation.
Additional question to ask, do you get the failure on one specific machine or all machines? Specific region?
Do you get the same failure when you use the existing vault?
If you still can provide information above, it's going to be helpful to narrow down the root cause.
I ran into this error as well today and I think it is is a Azure portal bug when enabling the Backup from the VM blade.
Instead, you can initiate a Backup from the "Recovery Services vaults" blade and add the VM to it.
I have an Azure Storage Account of type "RA-GRS" as shown below
WEST US is being Primary and East US is secondary.
While trying to failover to East US it is failing as shown below
How to fix this?
Note: I have followed this article - Prepare for a failover
There is a known issue where account failover is not possible within 4 hours of account creation or the conversion to (RA-)GRS. Either one of these conditions will cause the error you mention.
we currently have an ongoing issue with account failover wherein it can only be initiated once LastSyncTime is more than 4 hours after account creation time or after the time the account was converted to (RA-)GRS. E.g. if the account was created at 1 pm, then the LST should be 5 pm in order for the failover to work. We're working on the resolution right now, but I don't have the ETA quite yet.
You should also check the last sync time just to make sure this is available.
$lastSyncTime = $(Get-AzStorageAccount -ResourceGroupName <resource-group> `
-Name <storage-account> `
-IncludeGeoReplicationStats).GeoReplicationStats.LastSyncTime
We have our corporate requirement ( due to pricing and whitelisting) to have Availability sets in our Azure subscription and resources like Compute should be spun inside that particular availability set. Since Packer while creating the Image spins up a temporary VM inside a temporary resource Group , I am confused (since did not find any documentation around it) if we can configure packer to spin the temporary VM inside the whitelisted availability set.
One possible way I can think of is to spin up the VM in the Resource Group which we created for the Availability Set (Since everything in Azure needs to be inside the Resource Group) that way I am guessing it will be tracked as part of billing but I am still not sure if the intermittent VM will be part of availability set.
Please help and suggest if there is an alternate way to the same .
Can't seem to figure out how to change the availability set of an existing Azure VM in the Resource Manager stack. There's no interface for it. Set-AzureAvailabilitySet does not exist in the Azure Powershell tools when in ResourceManager mode. It does exist in service stack mode. But that doesn't help me.
AFAIK, this feature may be addressed by the end of this year. It's a big challenge for the MS team to allow such operation. Changing the availability Set requires a review of the VM mobility architecture on Azure. Fore example, adding a VM in an Availability Set already containing a VM means putting it to different default domain. Becasue VM mobilty is a matter on Azure (No Live Migration), it's not an easy operation.
I have written a Powershell script which let you change the AS of an ARM VM by recreating it.
Give it a try and enjoy:
How to use it ?
1- Download the script and save it to local location
2- Run it and provide the requested parameters
or
2- ./Set-ArmVmAvailabilitySet.ps1 –VmName ‘The VM Name’ –ResourceGroup
‘Resource Group’ –AvailabilitySetName ‘As Name’ –SubscriptionName
‘The Subscription name’
To remove a VM from an AvailabilitySet:
./Set-ArmVmAvailabilitySet.ps1 –VmName ‘The VM Name’ –ResourceGroup
‘Resource Group’ –AvailabilitySetName 0 –SubscriptionName ‘The
Subscription name’
Download Link
Version 1.01 :
https://gallery.technet.microsoft.com/Set-Azure-Resource-Manager-f7509ec4
Source
That feature isn't implemented yet in the ARM stack, that's why you're not seeing the cmdlet...
Our Windows Azure roles need to know programmatically which datacenter the roles are in.
I know a REST API ( http://msdn.microsoft.com/en-us/library/ee460806.aspx) return location property.
And if I deploy to, let’s say, West US, the REST API returns West US as location property.
However, if I deploy to Anywhere US, the property is Anywhere US.
I would like to know which datacenter our roles are in even if location property is Anywhere US.
The reason why I ask is our roles need to download some data from Windows Azure storage.
The cost of downloading data from the same datacenter is free but the that of downloading data from the different datacenter is not free.
It is a great question and I have talked about it couple of time with different partners. Based on my understanding when you create your service and provide where you want this service to location ("South Central US" or "Anywhere US"), this information is stored at the RDFE server specific to your service in your Azure subscription. So when you choose a fixed location such as "South Central US" or "North Central US" the service actually deployed to that location and exact location is stored however when you choose "Anywhere US", the selection to choose "South Center" or "North Central" is done internally however the selected location never updated to RDFE server related to your service.
That's why whenever you try to get location info related to your service in your subscription over SM API or Powershell or any other way (even on Azure Portal it is listed as "Anywhere US" because the information is coming from same storage), you will get exactly what you have selected at first place during service creation.
#Sandrino idea will work as long as you can validate your service location IP address from a given IP address range published by Windows Azure team.
Two days ago Microsoft published an XML file containing a list of IP ranges per region. Based on this file and the IP address of your role you can find in which datacenter the role has been deployed.
<?xml version="1.0" encoding="UTF-8"?>
<regions>
...
<region name="USA">
<subregion name="South Central US">
<network>65.55.80.0/20</network>
<network>65.54.48.0/21</network>
...
</subregion>
<subregion name="North Central US">
<network>207.46.192.0/20</network>
<network>65.52.0.0/19</network>
...
</subregion>
</region>
</regions>
Note: It looks like the new datacenters (West and East US) are not covered by this XML file, which might make it useless in your case.
I had some services deployed in Anywhere US and in order to find out which data centre it was deployed in I had to log a support call with Microsoft. They were helpful and got me the information but even they had to go away and look it up. As a result of this I would never use and the the "Anywhere ..." locations. Knowing which data centre your services are running in is very important for knowing where to deploy things like SQL Azure and service bus which don't support affinity groups and don't have an Anywhere option.