Could not connect to host, target machine refused...

[Zdravko]

20204 port is used by V-Ray to transfer information between the client and the nodes machines when doing distributed rendering.
You just need to add an exception in your firewall settings for that port number 20204.

[trixian]

I would like to add that I too am experiencing this "actively denied" problem. 3dsmaxdesign 2012 (latest updates) and Vray 2.30.01 running on W7 64bit enterprise on all machines. Spawner originally running as a service, logged in with its own account for maximum permissions on the local machines and the domain here at work.
I have 4 slaves (2 HP bladeservers and 2 prior workstations also from HP). After upgrading to Vray 2x, and reinstalling windows and all software fresh, DR and to some extent Backburner doesn't work. (This is not a complaint to Chaos, its more of a panicking cry for help) !!!
The really wierd thing is that one of the 2 identical Blade servers works fine, and they are identical in hardware and software. The rest just refuse. All machines have had the windows firewall disabled, and added the inbound and outbound rules for port 20204 TCP added.
Sometimes, (when the planets are aligned for a second) one of the machines might kick in if i quickly go into the firewall setting and enable and disable it, and run the spawner as an application, but even then, the render afterwards will get refused even if I have not changed any settings. The IT guys here at work don't really seem to be able to help me, except for moving the machines out of the regular Active directory policy group they were in. But that still didn't help.
I seriously need some assistance in finding out what is wrong, as I am the only one doing this kind of work, and there is nobody here to help me.
I know this is probably not a Vray only problem, as I can't seem to get Backburner to render reliably either, but I was hoping someone here might be able to give some tips.

[bardo]

the blade are controlled with remote desktop control??

Have you got some logoff timeout??

Have you some "green" setup to the network card??

Probably it's not actually related but I'm under domain too and I had some problems related with user permissions and hardware.

EDIT: I know I'm not very helpful...but I try to be...

[trixian]

All the machines are controlled by remote desktop, including the blades. I don't see how that affects anything though.
Logoff timeout? Not sure what you mean. Windows remote desktop times out after x amount of time like normal.
What is a green setup? The network cards in the Blades (in all the machines actually) are always on, if that is what you meant.

[bardo]

As logoff timeout I mean that in the domain policy there is rule to set a time after that not only the remote desktop time out but also a user time out (but I'm not sure because it was more than one year ago and our network guy did it...)

I'm not sure but this link seems related to "logoff timeout"
http://technet.microsoft.com/en-us/l...(v=ws.10).aspx


As "green" setup is that what you wrote....so... it's ok.

EDIT: Now I remember how to test the logoff timeout quickly.
In your blade, run an application (what you want)...wait and after some minutes reconnect and check if your app is On...if not...it means that your session was killed.
If you have just tested it or you noted that any app is killed...you are already ok and I haven't other ideas..

[trixian]

No session killing going on. Everything is running fine each time I log on.
Just tested a fresh machine install, and DR works fine. Quite irritating as all the slaves were freshly installed not too long ago.
I guess I'll just have to reinstall as nobody seems to actually understand the intricacies of networking here at work, especially not me.

[tricky]

This problem seems to have surfaced for us again, so just trying to troubleshoot things.

This port business: when we install vray, the default values for port are 30304, so we just leave them as they are. Some of these threads mention opening up ports for 20204 as a possible solution. Does that mean that the license settings for vray on each installation should be changed to 20204?

Our dongles are installed on a separate server by the way.

[svetlozar.draganov]

30304 port is reserved for License Server and it has nothing to do with 20204 port for DR spawners - nothing should be changed here.

When did you get this message : "Could not connect to host, target machine refused..."

* everytime (probably license issue)
* sometimes , and most ofter when the job is sent immediately when the previous one was finished/canceled ( spawners are not ready to accept new job - they need some time to clear the previous one)

Make sure that all the spawner's are correctly configured to get license from the machine where the dongle is plugged , and also try to give some time to spawners to release the current job before sending them another one.

Please let us know if you still have troubles with that - and let us know if it is possible to run a remote session on your machine in order to find out what's going on.

[DPS]

Any joy on a remedy?

I'm having this problem.

I can wait ten mins between a render and it still fails but one will work every now and then. I reinstalled vray on workstation and slaves today to try and fix. As first it worked and then stopped.

Note: I have an active support session on the go but I have no Internet access until next week so can't do Remote Desktop.

I added the in/out rules. Sometimes my slaves appear to have not cleared memory after render.

Restarting server, and spawner doesn't fix. Services are set to user logon.....

[DPS]

I just want to add - it appears to be rendering on slaves sometimes. I.e 100% CPU and vray message window indicates this but they're not affecting the buckets.

[tricky]

30304 port is reserved for License Server and it has nothing to do with 20204 port for DR spawners - nothing should be changed here.

When did you get this message : "Could not connect to host, target machine refused..."

* everytime (probably license issue)
* sometimes , and most ofter when the job is sent immediately when the previous one was finished/canceled ( spawners are not ready to accept new job - they need some time to clear the previous one)

Make sure that all the spawner's are correctly configured to get license from the machine where the dongle is plugged , and also try to give some time to spawners to release the current job before sending them another one.

Please let us know if you still have troubles with that - and let us know if it is possible to run a remote session on your machine in order to find out what's going on.

I am happy for you to remote into my machine right now if that is possible. I have a project which is at very early stages and therefore quite manageable that is giving me the same kinds of issues.

[DPS]

I think I've found the cause to atleast part of the problem in my scene. The reason I say part is that sometimes my nodes would appear to be rendering and I wouldn't get that message.

One itoo FPP item was being used as an exclude object for other forest objects.

Every time I tried to render my scene with any objects that had an exclude boundary referring that object, both DBR or backburner would fail.
Disabling those exclude boundaries and all will render.

I've tried so many other things the last few days that quite possibly I fixed the 'failed to connect to host' problem that may not (or may have) be related.

So disabling the layers of certain objects helped me troubleshoot but to contradict that, I also had problems with fresh new test scenes.

[tricky]

I seem to have found another part to a solution of this latest problem. We have just upgraded to Max2014 so installed the appropriate 2014 version of Vray. It seems that although the spawner service we had running doesn't work with the 2014 version of max/vray. Uninstalling the service and reinstalling the 2014 version of spawner service (which is still called spawner2013!!!) seems to have solved the latest problem.

Why oh why can't vray give more useful warning messages than 'server not responding' etc? Its a bloody nightmare to troubleshoot.

It would also be very useful if the spawner service was given the same name as the version you are installing (i.e. spawner2014 and not spawner2013)