Data Backup and Recovery Discussions
I'm setting up SnapManager for Hyper-V. All seems to be setup correctly however when I run the job manually (not scheduled) I get the following error.
[26/07/2013 7:41:09 PM, (18)] Preparing for backup of VM-Name[Hyper-V]
[26/07/2013 7:41:09 PM, (18)] Failed to take backup of VM VM-Name[Hyper-V] as storage system footprint for the VM is not available
I'm running on a 2x3210's running 7 mode in HA, all VHD's on a CSV lun via iSCSI, SMHV 1.2, SDW 6.4.1
Could you please upload the Snapdrive logs?
Did you ever find a solution to this I am seeing the same problem for some of my VM's
Could you please check if the SDW transport protocol settings are set correctly?
Also, could you please execute the command - "sdcli disk list" and see if shows VHD paths of the VM that failed.
I have ran that command, and have an interesting result. For your info I have 2 CSV’s in this cluster VM’s on CSV 2 are backing up fine but Vm’s on CSV1 are failing.
I can see both CSV from the command and I can see one difference , CSV2 is set to “Shared:Yes” and CSV 1 is Set to “Shared: No”, Also snap drive says this disk type is Dedicated rather than clustered.
Any ideas why they are different, and how I change CSV 1 to Clustered type.
Extrinsica Global Limited
T +44 1865 987 436
M +44 7899 940 872
Did you add a new node or remove the node in the cluster recently?
Also, what is Snapdrive version and the Windows OS version?
No we haven’t added any new nodes recently, but we have only just started using SMHV to back up the VM’s
Snapdrive is 6.5
OS is server 2012 core
I have read a few netapp forums that say backups will fail if the disk type is dedicated not clustered. Is there a way to change the disk type to clustered so it’s the same as the CSV that is working?
Were you able to figure this out? I'm having the same problem.
Having this same issue myself as well, surprised to see no comments over couple of years!
Seems to be intermittent, but going to have a look and see if I can find a solution! Will post any findings.
After running SMHV without issue for years, I now have discovered this issue on our cluster. Does anyone have an answer? Thanks.