Question on valid command capability

I am trying to create a command to automatically identify a volume with a snapmirror and get the rather generic

Failed to connect to controller: <CONTROLLER>.

The requested name is valid, but no data of the requested type was found

Running workflows directly on this controller work fine and the "Test Connectivity" options returns a successful connection.

This is all 7 mode on WFA 2.1.0.70.32, build 2178337.

I suspect that I cannot connect to one controller execute code, then farther down in the same command connect to a different controller and execute code on that controller. This is basically a port of a powershell script that I am using, with the hopes of getting it into WFA for official logging.

Re: Question on valid command capability

I found the issue this morning and am posting full details for everyone to see

I was getting this error:

But connection tests succeed:

Certain jobs ran without fail, but I found one that did fail:

If you note there are consistency issues between lines. On some lines WFA is using 192.0.4.18(my lab frame IP) and on others it switches to gisnas99b(the lab frame hostname). Any workflow that was entirely IP based passed, anything with hostname failed. I updated my hosts file as that frame has multiple IPs and all is now well. Something for others to note if they have this issue.

Re: Question on valid command capability

‎2014-04-0107:15 AM

Thanks Anil,

I am good to go at this point with the hosts entry. The problem was manifesting because some of the WFA workflows/commands were not using IP and the hosts entry did not exist for gisnas99b. gisnas99a, the source worked without issue because it was listed in the hosts file. The command is still broken, but the workflow is fine now. This was especially confusing because the workflow would work fine with the source/destination reversed because of the way the workflow starts. The workflow calls the source by IP, and the destination is returned within the command by hostname. So 192.0.4.18 => gisnas99a worked as WFA had a hosts entry for gisnas99a, but 192.0.4.17 => gisnas99b failed with that error because gisnas99b was not in the hosts file.