Hello everyone,
I am wondering if anyone had any insights on how to get a succesful backup with veeam and nutanix and if there is something I am just overlooking. I know I am oversimplifying but I have followed the best practices setup and have checked all of the settings twice but somehow I still get the following error:
12/5/2015 1:30:11 PM :: Unable to allocate processing resources. Error: Provider [{89300202-3cec-4981-9171-19f59559e0f2}] does not support shadow copies of volume [\LSSHARE01LIFE_NTNX01].--tr:Failed to add volumes to the snapshot set.--tr:Failed to perform pre-backup tasks.
I could have sworn that if NOS is added to AD then the share can use the VSS. I am frankly not finding any information on this and have gone from logs, to accounts, to verifying the storage. Any insights would be greatly appreciated.
Solved
VSS Failure on VEEAM
+5Best answer by Prakash
Helped take backups using Veeam.
As we expected, the ncc Kerberos check indeed showed Kerberos authentication failure.
The computer object representing the NOS cluster was indeed present in their AD. It's likely that the group policy configured for the OU had some password-specific setting that caused authentication to fail.
As a resolution we unjoined the NOS cluster from AD using the hidden ncli command. Then we tried joining the NOS cluster back to their AD using the GUI. But this step failed saying "the server cannot handle directory requests". Since we were not sure why this message is showing up and since we wanted to get the customer quickly take backups of their production VMs using Veeam, we resorted to a 2-step cli process.
(1) First we created a computer object in AD using the New-NosClusterComputer Powershell command.
(2) Then we used hidden ncli cluster join-cluster-no-ad to configure the passord in NOS.
Then after clearing the (stale, cached) Kerberos tickets, diskshadow started working.
The customer restarted the Veeam job that was earlier failing and the job now succeeds.
View originalAs we expected, the ncc Kerberos check indeed showed Kerberos authentication failure.
The computer object representing the NOS cluster was indeed present in their AD. It's likely that the group policy configured for the OU had some password-specific setting that caused authentication to fail.
As a resolution we unjoined the NOS cluster from AD using the hidden ncli command. Then we tried joining the NOS cluster back to their AD using the GUI. But this step failed saying "the server cannot handle directory requests". Since we were not sure why this message is showing up and since we wanted to get the customer quickly take backups of their production VMs using Veeam, we resorted to a 2-step cli process.
(1) First we created a computer object in AD using the New-NosClusterComputer Powershell command.
(2) Then we used hidden ncli cluster join-cluster-no-ad to configure the passord in NOS.
Then after clearing the (stale, cached) Kerberos tickets, diskshadow started working.
The customer restarted the Veeam job that was earlier failing and the job now succeeds.
This topic has been closed for comments
+2- Nutanix Employee
- 3 replies
Hello ,
If VSS backups were working properly earlier and had suddenly stopped working, couple of things could have happened:
(1) The time in the CVMs of the Nutanix cluster could have gone out of sync with the AD causing Kerberos authentication to fail.
(2) The computer object representing the Nutanix cluster in AD/DC could have gotten deleted or disabled or could have had it's password reset.
If you are running NOS 4.5, running ncc will quickly point you to the problem. Even if you are running a older NOS release, please run ncc.
You can also try using diskshadow from any of the hosts in the cluster to isolate the problem.
If VSS backups were working properly earlier and had suddenly stopped working, couple of things could have happened:
(1) The time in the CVMs of the Nutanix cluster could have gone out of sync with the AD causing Kerberos authentication to fail.
(2) The computer object representing the Nutanix cluster in AD/DC could have gotten deleted or disabled or could have had it's password reset.
If you are running NOS 4.5, running ncc will quickly point you to the problem. Even if you are running a older NOS release, please run ncc.
You can also try using diskshadow from any of the hosts in the cluster to isolate the problem.
+5Hi
I will look into the suggestions. The problem is that this has not worked from our understanding. I did run the health check and it did show up that NOS Cluster computer object is not configured in Active Directory. I checked the clsuter account and it was there on AD as well as the hosts.
I have seen suggestions to run the hyper v host script to check if they need to be readded into AD but I fear that this might convolut things, not to mention that it will require a reboot and frankly these are in production and would hate to bring them down before the monday. Thanks for the suggestions so far.
I will look into the suggestions. The problem is that this has not worked from our understanding. I did run the health check and it did show up that NOS Cluster computer object is not configured in Active Directory. I checked the clsuter account and it was there on AD as well as the hosts.
I have seen suggestions to run the hyper v host script to check if they need to be readded into AD but I fear that this might convolut things, not to mention that it will require a reboot and frankly these are in production and would hate to bring them down before the monday. Thanks for the suggestions so far.
+2- Nutanix Employee
- 3 replies
Hello
Domain-joining the NOS cluster should not require reboot of any of the cluster components. So if you need help with this, please file a support ticket with Nutanix and we'll help to get the backups going.
Domain-joining the NOS cluster should not require reboot of any of the cluster components. So if you need help with this, please file a support ticket with Nutanix and we'll help to get the backups going.
1 person likes this
+2- Nutanix Employee
- 3 replies
- Answer
Helped take backups using Veeam.
As we expected, the ncc Kerberos check indeed showed Kerberos authentication failure.
The computer object representing the NOS cluster was indeed present in their AD. It's likely that the group policy configured for the OU had some password-specific setting that caused authentication to fail.
As a resolution we unjoined the NOS cluster from AD using the hidden ncli command. Then we tried joining the NOS cluster back to their AD using the GUI. But this step failed saying "the server cannot handle directory requests". Since we were not sure why this message is showing up and since we wanted to get the customer quickly take backups of their production VMs using Veeam, we resorted to a 2-step cli process.
(1) First we created a computer object in AD using the New-NosClusterComputer Powershell command.
(2) Then we used hidden ncli cluster join-cluster-no-ad to configure the passord in NOS.
Then after clearing the (stale, cached) Kerberos tickets, diskshadow started working.
The customer restarted the Veeam job that was earlier failing and the job now succeeds.
As we expected, the ncc Kerberos check indeed showed Kerberos authentication failure.
The computer object representing the NOS cluster was indeed present in their AD. It's likely that the group policy configured for the OU had some password-specific setting that caused authentication to fail.
As a resolution we unjoined the NOS cluster from AD using the hidden ncli command. Then we tried joining the NOS cluster back to their AD using the GUI. But this step failed saying "the server cannot handle directory requests". Since we were not sure why this message is showing up and since we wanted to get the customer quickly take backups of their production VMs using Veeam, we resorted to a 2-step cli process.
(1) First we created a computer object in AD using the New-NosClusterComputer Powershell command.
(2) Then we used hidden ncli cluster join-cluster-no-ad to configure the passord in NOS.
Then after clearing the (stale, cached) Kerberos tickets, diskshadow started working.
The customer restarted the Veeam job that was earlier failing and the job now succeeds.
+5Yes. This was indeed the issue. Thank you for all of your help today. Very happy that the backups are now working.
1 person likes this
+1Hello
I'm having also a issue with Veeam 9, NOS and Hyper-V 2012 R2.
For some VMs (those that have a database engine installed) the backup fails with the message
Unknown status of async operation Error The shadow copy provider had an unexpected error while trying to process the specified operation. Error --tr:Failed to create VSS snapshot. Error --tr:Failed to perform pre-backup tasks. (System.Exception)
I had reviewed and tried every Veeam KB and also followed the Best Practices document for Nutanix,Veeam and Hyper-V. Each host has the Hyper-V VSS Writer installed.
Backups jobs are not configured to use VSS, but still try to do it.
We appreciate any feedback/idea
Thanks
I'm having also a issue with Veeam 9, NOS and Hyper-V 2012 R2.
For some VMs (those that have a database engine installed) the backup fails with the message
Unknown status of async operation Error The shadow copy provider had an unexpected error while trying to process the specified operation. Error --tr:Failed to create VSS snapshot. Error --tr:Failed to perform pre-backup tasks. (System.Exception)
I had reviewed and tried every Veeam KB and also followed the Best Practices document for Nutanix,Veeam and Hyper-V. Each host has the Hyper-V VSS Writer installed.
Backups jobs are not configured to use VSS, but still try to do it.
We appreciate any feedback/idea
Thanks
+1Hello:
Well, thanks to Nutanix Support the issue was solved. No more than 1,000 files are supported by Nutanix in a SMB 3.0 share and the customer forgot to mention that they have "some" files there sharing space with the VHDX. Well, there were roughly 153,000 files in that share, so once the customer moved them out, the backup completed successfully.
Thanks.
Well, thanks to Nutanix Support the issue was solved. No more than 1,000 files are supported by Nutanix in a SMB 3.0 share and the customer forgot to mention that they have "some" files there sharing space with the VHDX. Well, there were roughly 153,000 files in that share, so once the customer moved them out, the backup completed successfully.
Thanks.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.