Multicpu Rendering Using Network Storage (windows?)

[kodiak]

This is apparently a known issue, but someone could shed some light on it.

We are running the following configuration on the network: windows 2003 server/storage server (multiple servers) with samba shares mounted on workstations running windows xp 32/64bit (with service packs installed) and Houdini 8.2.13.

I have a test project setup on the network server and I'm accessing the assets/content using mapped drives (or UNC, doesn't make a difference). When I try to render on multiple CPUs on the local machine (using the -n switch) or across multiple machines (-H switch) I can't access the textures anymore (just red standin color).

If this is really a known thing and I can't do anything about it..anyone has tips to work around? It's kinda ok for asset creation, I could just check them out to local disk together with textures and some smart env variable massaging, but when it comes to lighting shots, this is not a workable solution.

Just out of curiosity..what's causing the issue (technically)? I can't imagine.

Also, is this the same on Linux (I mean either a *nix server or a pure Linux environment)?

thanks

Andras

[mtucker]

The problem is that when doing multi-host rendering (even if the hosts are all local), the "remote" mantra processes are run by the hserver service. Services on Windows are, by default, run as a special "LOCAL" user, that basically has no rights to access anything on the network. So the mantra processes started by hserver are also run as this LOCAL user, and therefore they can't access remote drives (even if you use UNC paths).

The solution is to have hserver run as a different user, one that has sufficient rights to access the remote network drives. To set this up, open the control panel -> administrative tools -> services. Then RMB on the Houdini License Client service, and choose "Properties". On the Log On page, change it to log on as "This Account", and specify the account name and password for some user with sufficient priveleges. You may want to set up a dedicated "RenderFarm" user which only has access to certain shared drives or whatever.

Then restart the Houdini License Client service, and your mantra renders should be able to access texture maps specified with UNC paths. Mapped drive letter still may not work in this situation, because I believe drive mappings are local to a particular session. So unless you set up hserver to log on as the same user account as is currently logged in to the machine (with the drive mappings set up), the drive mappings will be meaningless.

I don't know enough about Linux, but I'm sure there would be ways to set up your Linux environment to result in these same permission issues. But I guess the default method for running "services" on Linux like hserver result in sufficient permissions to access network drives.

I hope this helps clear things up.

Mark

[kodiak]

Thanks a lot Mark, that's a great step forward

Now there is one more thing that I will have to figure out. I don't have the hserver service installed locally as a service, because the idea is to have all the software installed on a network file (application) server. So my startup mechanism is a bit different. Basically what I'm doing is using hservice.exe to startup a hserver instance, then (put it this simplified way) setting all the environment variables for site/project/user config successively and then launch Houdini.

So basically if hservice.exe would allow me to run hservice as a specific user, that would be cool, but this way I'm not sure where it will inherit the user from. So what I can do is run a shell script using that user that maps the drives then starts hserver. I was doing this on the renderfarm before as well.

Anyways, I think I can figure it out from this point (I was not sure if it's our environment, Windows or Houdini causing the issue).

cheers

Andras

[kodiak]

Argh, this is still not ok..for some reason launching hserver using hservice doesn't seem to propagate the rights properly.

I tried the RUNAS command first, nothing.

Then I tried pstools (psexec) with the following syntax, it didn't help either, hserver still runs as SYSTEM user instead of Renderman (this is 1 line of code)

\\calimero\skynet\psexec \\superjudge -u DOMAIN\Renderman -p Password -i -d -c \\calimero\skynet\applications\houdini\services\hservice -i HoudiniServer "\\calimero\skynet\applications\houdini\services\hserver.exe" -s HoudiniServer

Any clues? Is there any other way to launch hserver without installing it as a service?

What if i write a wrapper in python and use the win32 services module?

If this is not possible, tips of administrating a large amount of Windows machines is also welcome..this hserver thing is bit of a pain in the ass.

Edited April 21, 2007 by kodiak

[old school]

Argh, this is still not ok..for some reason launching hserver using hservice doesn't seem to propagate the rights properly.

Any clues? Is there any other way to launch hserver without installing it as a service?

What if i write a wrapper in python and use the win32 services module?

You have to follow Mark T's instructions and modify the hserver in Services. Get one machine to work then propagate that user setup to the other machines.

Another thing to watch out for (with latest WinXP updates) is that firewalls can get in the way. A continual problem if your Windows Machines have auto-install updates on. Read the link that Ed gave you on the SESI equivallent thread. It's Misc Issues #2.

[kodiak]

Thanks for the hints, they did work in a normal situation (ie when Houdini is installed locally as it should be

On the other hand, my situation is slightly different. I would prefer to avoid both local Houdini and service installations as they have quite a big administration overhead.

What I wanted to do is launch the hserver as a service, but not having it installed. I've run into this rights problem, but apart from that it's working ok.

So you're saying is that there is no way not to have a service installed and I should just install Houdini manually?