Skip to main content

Hyperv Backups failed      

Failure Reason: Virtual machine (abc) disks are not accessible. Ensure that the access node (VSA proxy) can read the source VM disks. 

 

we are added Groups as access nodes on properties of Hyperv and those 2 groups are belongs to 2 clusters in hyperv .

when ever schedule backup got triggered it will pickup wrong VSA as a Backup agent and its failling with subjected error.

 

if i add manually those VSA proxies  in subclient level properties as a access nodes then backups are completing and working fine .

 

how to eliminate this wrong allocation of VSA while backup , i hope commvault should figureout the correct host and VSA allocation , if not correct me  and please advice how we can overcome and i would like to use group level association of VSA on node on properties tab instead of subclient level.

 

Thanks in Advance!!

The user must be part of the following administrator groups on the Hyper-V host:

  • Microsoft Hyper-V Server, versions 2016, 2019, and 2022

  • Local Administrators group (for Hyper-V Server 2008 R2 and Hyper-V Server 2016)

  • Any user that are part of Hyper-V Administrators group (for Hyper-V Server 2012 and 2012 R2)

  • For a Hyper-V cluster, the user account must have full Cluster Permissions (Read and Full Control).

Then check the vsdiscovery and vsbkp logs on the host(s) reporting the error. Usually there are WMI access denied errors that need to be addressed outside of CommVault. Hyper V uses WMI to communicate between the Hyper V hosts. If the user provided doesn’t have access that need to looked at internally. 

everything looks fine and when ever we added that particular cluster nodes (VSA) in subclient level properties its backup are pickup proper VSA and working.

 

if we inherited the VSA servers through client computer group on Vcenter properties its pickup wrong proxies and backups ended with failure.

Hello,

In our case, with same error (Error code: [91:397] Description: Virtual machine ***** disks are not accessible. Ensure that the access node (VSA proxy) can read the source VM disks.), the problem was in following permissions:

  • Microsoft Hyper-V Server, versions 2016, 2019, and 2022

  • Local Administrators group (for Hyper-V Server 2008 R2 and Hyper-V Server 2016)

  • Any user that are part of Hyper-V Administrators group (for Hyper-V Server 2012 and 2012 R2)

  • For a Hyper-V cluster, the user account must have full Cluster Permissions (Read and Full Control).

Reply


Terms & ConditionsCookie settings