Restore to Azure

[arosas]

Is there a way to filter or do a check that the VM is available in the region that was selected when performing a restore to Azure operation?

While testing a restore from on prem to Azure, I selected the Basic_A2 VM in West Central US.
The restore process continues and starts creating resources in the Azure resource group, once the data is there and it's time to create the VM, Veeam tries creating the VM, when it fails it retries about 10 times until it ultimately fails with the message: Restore job failed Error: The remote server returned an error: (409) Conflict.

Looking at the Azure side, the logs show it was due to the VM size not being available in the location:
The requested size for resource '/subscriptions/SUBSCRIPTIONNUMBER/resourceGroups/SDT-VeeamAzure-dev-rg/providers/Microsoft.Compute/virtualMachines/<VMNAME>' is currently not available in location 'westcentralus' zones '' for subscription 'SUBSCRIPTIONNUMBER'. Please try another size or deploy to a different location or zones. See https://aka.ms/azureskunotavailable for details.

If this was a large production VM, we would have had to wait until the data was restored then the VM would try to get created and fail then we would have to start over, so definitely room for improvement around the VM validation so we are not waiting so long for a failure.

Trying the restore again with a different size VM is successful.

Possible solutions from the Veeam side:

• Create the VM first, if the VM creation process fails, then abort and do not restore the data to disk, this should help with waiting so long for a failure.

• When selecting the VM size filter based on the selected region.

• Before submitting the restore job, run a validation to ensure the VM is available in that region.

I also opened a case for this asking if it should be filtering the VM size by region.
Case # 04864255

[Dima P.]

Hello Tony,

The information about available resources is periodically cached at Veeam B&R side. You can find all cache files C:\Windows\Temp\veeam*.json and delete those, then start Restore to Azure again to populate the cache with newly updated resource information from the Azure region. Hope this helps!

[veremin]

When selecting the VM size filter based on the selected region

We are doing this already, so kindly keep working with the support team on finding the root cause of the described issue. Thanks.

[arosas]

I did see that topic.
This was the first restore to Azure so the cache should have populated the very first time and should have populated ONLY what was available to be used in West Central, but it did not. The list had all VMs available including top end performance VMs that I know are not available in that region according to this link:
https://azure.microsoft.com/en-us/globa ... oducts=all

I checked in the C:\Windows\Temp\ for the file you mentioned and it does not contain any JSON files.
I did find the file you might be referring to in another directory.
C:\Users\veeam\AppData\Local\Temp
veeam-azure-sku-westcentralus.json
veeam-disk-resources-westcentralus.json
I went ahead and moved the files out of that directory and started B&R and attempted another restore to Azure, the files were recreated.
I selected from the list the VM size Standard_F2s_v2.
The restore started and the disk, Network interface and Network security group were created first.
The data restored to the disk.
Veeam then attempted to create the VM and failed with the same Azure message as above, Veeam then proceeded to retry 18 more times until the job ultimately fails with the 409 error.
The whole process took roughly 27 minutes and this is a small test VM.
If there was validation step, or maybe the VM created first, then we would not need to wait 27 minutes.

I tried again and this time selected standard SSD instead of accepting the default standard HDD, although standard HDD is available on all VMs in all regions.
https://docs.microsoft.com/en-us/azure/ ... isks-types

I think the main thing is there should be another validation put in as suggested above, in order to prevent waiting AFTER the data is restored to fail out, regardless if the cache is updated or not.

I will let support know the additional testing I have done.

[veremin]

Then it seems that the said validation mechanism (that should hide unavailable VM sizes) does not work for some reason, and this is what support team should probably investigate further. So continuing working with the support engineer sounds like the best idea. Thanks!

[arosas]

Thanks for the response, I'll continue engaging support.