I have ran that command from the terminal and it is showing the cluster, node 1 and node 2 and also the SVM as part of the aggregates. Like I said, this has worked before so I am not sure what's happened.
I have raised a case with NetApp for this but if you don't mind answering a few questions around this while the call gets picked up that would be very helpful!
When I try to restore to the proxy VM from our primary I get this error :
Unable to mount datastores: in Backup: 108.Failed to create volume clone for volume : Failed to create the volume clone. Cannot create volume. Reason: aggregate is not in aggr-list of Vserver
When I try to restore to the proxy VM from our secondary location I get this error :
Unable to mount datastores: in Backup: 100.com.vmware.esx.hostctl.default: Operation failed, diagnostics report: Unable to resolve hostname
Are these both the same issue as secondary location error would suggest a name resolution? Also what impact would there be if I had to re-add the aggregate? would the data be at risk or downtime occur?
Ok thanks for that, I will add that aggregate and hopefully that will solve the issue.
Is there a reason why all of the aggregates were de-selected as this has worked before? would all of the aggregates need to be selected in order to do a guest restore or just the aggregate with the proxy VM?
Don't know how it has worked for you in the past but in theory during restore/mount process (DB verification) 'volume clone' is created using flex-clone and in order for this to succeed, the containing aggregate must be assigned to the Storage Virtual Machine (SVM), so that SVM can delegate volume creation privilege. If this has not been configured, the clone/verification operation will fail. Thanks!