IFincremental bakcup VM fails with right access problem

[enkachu]

Hi everybody,

I have been facing a TSM backup VM problem for 2 weeks now.
My environment :

- PRODUCTION ENVIRONMENT : VMware 5.5
- TSM SERVER : Version7.1.1
- TDP for VE : Version7.1.1

ENVIRONMENT DESCRIPTION
My TSM server and the vStorage proxy server are both located in the same physical server. My TSM server is well zoned to see the VMWARE LUNs infrastructure. The VM transport method is NBD, over the LAN.


First Problem description
When I launched a "backup vm -vmlist=VM1,VM2,...,VMn -mode=ifincr", I got an error like "Data was unavailable on server and the action ws skipped".

In my research, it was related with the control files metadata of virtual machines. The answer was to eparate the VM data flow from the VM control files flow. So, I created two management class with a disk storage pool for the control files.

Second problem description
Without testing my first solution, a second problem occured. When I launch a "backup vm -vmlist=VM1,VM2,...,VMn -mode=ifincr", I systematically get the error below for every virtual machine :

04/28/2015 16:29:24 ANS9365E VMware vStorage API error for virtual machine 'VMname'.
TSM function name : VixDiskLib_Open
TSM file : vmvddksdk.cpp (1669)
API return code : 13
API error message : You do not have access rights to this file
04/28/2015 16:29:24 ANS1228E Sending of object 'VMname' failed.
04/28/2015 16:29:24 ANS5283E The operation was unsuccessful.

I troubleshooted :
- the DNS resolution for the vCenter Server (I tested both, with the IP address and FQDN) ==> OK, but the error persists
- the transport method, playing with all options (SAN and NBD)==> The error persists
- The rights for the VMUSER of the option file. It is a vCenter administrator account with all privilges ==> The error persists

Could you help me, please.

 

[marclant]

There are a few possible solutions. You might want to chech the first four Google hits for that:
https://www.google.ca/search?q=ANS9365E "You do not have access rights to this file"

The first one is a simple and common when getting this error.

 

[enkachu]

Hi Marclant,
Thank you for your reply.
I have ever googled and all links that result from your research above are all violet on my PC. I have read all of them without finding the true response.

Anyway, thanks a lot.

 

[marclant]

I'd retry setting the password for the vmcuser using "dsmc set password", just in case you had a typo when you set it the first time. The password is not verified when you set it, so it's possible to save the wrong one.

 

[enkachu]

Hi Marclant,
I also thought it could be the password and tried to set it again by spelling the caracters, but nothing happen after. The command I used :
[HASHTAG]#baclient[/HASHTAG]> "dsmc set password -type=VM vCenterIP domain\VCAdm VCAdmPwd -optfile=dsmVSTORAGE.opt"

dsmVSTORAGE.opt is the option file for the vStorage Proxy Server located in the same physical system then TSM server.

 

[marclant]

I see you are using a domain ID. I'm not sure if it makes a difference. Try putting the domain ID in quotes to see if it makes a difference:

dsmc set password -type=VM vCenterIP "domain\VCAdm" VCAdmPwd -optfile=dsmVSTORAGE.opt

Also, the VMCHOST and VMCUSER must be the same in the command as in dsmVSTORAGE.opt So using your example, dsmVSTORAGE.opt would have:

VMCHOST vCenterIP
VMCUSER "domain\VCAdm"

 

[enkachu]

It's now OK. All I did today was ever done before but perhaps in a wrong order.
1) I just tried a manual backup VM for one virtual machine VM1 ==> SUCCESFULL
2) For the same VM, I scheduled the backup. ==> FAILED
3) I tried a second manual backup VM for another virtual machine VM2 ==> SUCCESFULL
4) I scheduled the backup of VM2 ==> FAILED

So, I said to myself that perhaps the problem comes from "LOCAL SYSTEM", the account used by the scheduler.
5) I updated the credentials for the scheduler and mapped it with a domain account (a service admin account)
6) I gave to that service domain account, the rights to read and write on the different log files of the schedule
7) I restart the step 2) ==> SUCCESFULL
8) I restart the step 4) ==> SUCCESFULL
9) I lauched my main client_VM_schedule, which daily starts my backup VM. It is running now and seems to be OK....

I come back tomorrow.

Marclant, Thantks for your availability.

 

[tpesselier]

Hy

I have the same problem with hotadd

have you found the solution ?
best

 

[enkachu]

Hi tpesselier

Did you tried my solution above, posted on 04/29/2015?

 

[tpesselier]

Hi tpesselier

Did you tried my solution above, posted on 04/29/2015?

 

[tpesselier]

It s ok , just dns problem for me.
So be careful with 5.5 , i have many bug , install the patch 5.5.4

http://kb.vmware.com/selfservice/mi...102714443449228&cm_mc_sid_50200000=1444344922