Skip to main content
  • EN

AVS Cloudadmin role not working with Veeam VBR inside AVS.

 

The cloudadmin role was created using the cloudadmin@vsphere.local priviliges as the template. So any account you assign the cloudadmin role should also work if the cloudadmin@vsphere.local is working. 

 

Our Veeam VBR in AVS works if we use the cloudadmin@vsphere.local account but if we assign a service account to the cloudadmin role, it does not. The error is shown below:

Failed to open VDDK disk dvsanDatastore] c5ca9666-0633-ee72-8079-08c0eb414cda/
Logon attempt with parameters eVC/ESX: /vc.4bc149b438784b2e87ed53.westus2.avs.a
Failed to open disk for read.
Failed to upload disk 'vddkConnSpec>'
Agent failed to process method {DataTransfer.SyncDisk}.
 (System.AggregateException)
Failed to open VDDK disk K vsanDatastore] c5ca9666-0633-ee72-8079-08c0eb414cda/
   in c++: {
   in c++: VDDK error: 3014 (Insufficient permissions in the host operating 
 

From Veeam perspective, it is a permission error which I already raised with Azure support but they said also that there is no difference between the account cloudadmin and the role cloudadmin.

 

I sent this https://helpcenter.veeam.com/docs/backup/permissions/backup.html?ver=120 to Azure and they came back saying the disable/enable methods, and licensing (under the Global Privilege) are not allowed for tenants and the user cloudadmin account does not have those rights as well. There is only one local account in vsphere.local. So from what I can tell if we use a domain account, it does not work. However, Azure support does want to create another local account for testing. 

 

The reason we would like to be able to create a role that works with our service account is we want to implement granular permission for the backup account.

 

Wondering if anybody out there has encountered the same issue and what solution was implemented. 

 

Thanks

 

Finally, here’s an update on this issue.

The VMs that had backups failing were in a folder that has a subfolder. So even though the service account’s setting is set to global and its child objects. We still have to set the granularity on the both the sub-folder and the main folder. The AVS is on v8 and what we have on-prem is v7. We were told there should be no difference in the behavior but this is not what we are seeing from our end. So the main folder should have in Defined in, This object and its children. The subfolder has the value pointing to the main folder.

 

Comment


Terms & Conditions