VRO Azure Disks shorten name

[harbinger]

Hi all

I'm in the evaluation process of VRO and stumbled upon a problem with the recovery of Machines to Azure.
When deploying the Azure disks from which the Azure VM gets created afterwards, Veeam itself reserves already 44 letters for naming the disk, I think by a GUID followed by Disk-1, i.e. 5aab73f3-c3cc-4448-acc0-48396143bb82_Disk-1.
In the plan we specify a name to create the VM according to our Azure name convention and so the Name of the disk exceeds the 64 letter limit which is specified in Azure Resource Manager as a hard limit for resources (https://learn.microsoft.com/en-us/azure ... ate-limits)
This prevents us from managing these Disks and therefor VMs with Bicep in IAC which is using ARM for deploying resources.
Is there a way to shorten these disk names which are created by VRO? I can't see an option in the Plan Step "Create Cloud VM".

Best Regards
Philipp

[Alec King]

Hi Philip, I'll check with the dev team exactly where and when the GUID is applied. Of course we do it to ensure uniqueness, and there could be unpredictable results including failure or data loss if duplicate names were ever used.
Do you wish to apply your own choice of UID, or just that VRO uses a shorter one?
How many letters over the 64 character limit are the calculated disk names?
Thanks!

[Alec King]

Hi Philip, just an update; I've confirmed that it's the Veeam Backup server that actually inserts this GUID into the disk name, VRO only passes the vm name. The command we are using is

Code: Select all

Start-VBRVMRestoreToAzure

and I don't see any parameters there that enable or disable a GUID.
I've reached out to the relevant team to learn more.

[harbinger]

Hi Alec

Sorry for the late reply, been out of office for a few days.
In the short term, if VRO would use a shorter UID it would work for us, it shouldn't exceed the 20 characters limit in my opinion, because some organizations themselves have their own naming concepts for Azure Workloads.
In our case the length of the disks is now about 70 characters.
In the long term we'd like to see that these specific details for the Azure VM configuration could be specified in the VRO Job.
These would be:
- Azure VM Name
- Azure Disk Name (per Disk, if not specified, then use the vm name with the uid)
- Azure NIC Name
- Azure NSG Name (it would also be great if the NSG could be excluded from creation, because it is not always needed, especially if the Azure Network is managed by vWan or another firewall solution)

I hope there is a way to implement this UID workaround quickly in VRO because our Disaster Recovery will depend on it and we're using Bicep to manage all of our Azure VMs.

Thanks and Best Regards
Philipp

[Alec King]

Hi Philipp, thanks for this additional info. I'm still investigating with the Veeam Backup team because any change to this behaviour would have to be made there. As per above it's not specifically VRO that inserts this GUID. If we can arrange a change to this it would have to be delivered in an upcoming Veeam Backup update, not a VRO update.
I've noted your requests above - options to specify item names or use a default; option to skip creation of NSG. Do you have any other requests for the way Azure VMs are created using VRO plans?
Thanks!

[harbinger]

Hi Alec

My bad, I thought VRO is sending the variables for the restore in Azure to VBR which then creates the machine and resources to restore them. Thanks for clarifying the behavior.
Some other inputs:
- In the recovery location configuration to Azure the resource group has also to be specified, which would be better to specify also on the Recovery plan in the VM step. In the recovery location there should only be specified which subscription to use or even better, if possible, the Azure management group, but I guess that would be hard to implement. This way the VMs could be restored into a resource group specified in the VM job instead of all of them to the same resource group. I think most companies like us are using multiple subscriptions and are separating their workload in to corresponding resource groups.
- I'm not sure if it's possible to create the Azure disks with the possibility of Trusted Launch or if this is only possible at the creation of new VMs, but it isn't possible to activate this afterwards. Can you have a look in to this?
- Last but not least it would be great to configure the Azure NIC with a static internal IP instead of letting Azure IPAM assign it the next available IP. So if a VM is restored to Azure it gets the correct IP from beginning and will register itself to DNS correctly from the start.

Thanks and Best Regards
Philipp

[veremin]

The documentation referenced in the original post suggests that the limit of 64 applies to the number of variables (outputs), not the characters in the VM name. In Azure, VM names can have up to 80 symbols. So, I'm wondering if you have actually encountered any issues while restoring VMs with names set according to your policy.

We have still discussed this with the R&D team and have decided to shorten the GUID applied to virtual disk names of restored VMs. While we don't have a specific ETA at the moment, we will definitely address this in one of the upcoming product versions.

Thanks!