Hi folks,
I’m curious to know if there is a way to change the underlying connection from submission hosts to execution hosts to use “vglconnect -s” which would allow for an established tunnel over which to communicate VirtualGL Transport traffic.
Cheers
As you may already know, after submitting a job via qsub and when the job starts to run, there is no persistent connection between the compute node and the submission host. Unless, if you have started an interactive job via qsub -I or qsub -I - X . I am not sure, but you can start an interactive job in one command terminal, after knowing the compute node executing this interactive job, initiate a vglconnect -s to that compute node.
Thanks, Adarsh. I should have been more specific as I was referring to your example of the interactive jobs. I have permitted a user to have a direct vglconnect session to nodes that they have an established interactive session but, as the shell has a different session ID, there’s no way to track nor enforce their resource use, nor tie it to their Job ID. Some users you trust, others you don’t. For the latter, we look for technical, rather than policy, solutions.
If the underlying connection that establishes an interactive session could be a vglconnect, it would allow users to run 3D accelerated visualizations in their submitted jobs and we feel this would be of value, hence the question / proposal.
Regards
Scott
Thank you Scott for the explanation.
I would like to check with @scc and @mkaro for comments and solution.
If I understand your scenario correctly, you may want to try something like this:
qsub -l select=4:ncpus=1 -I -X -- /usr/bin/xterm
In your case you would want to replace xterm with whatever vglconnect command you use to open a window on your local display. Rather than invoking a shell, the pbs_mom will run the command you provide.
My question is whether you really care about the CPU usage of the vglconnect client itself, but rather the processes invoked from within the GUI? Assuming it’s the latter this is not unlike what happens in an MPI job. When an MPI application is launched from within a PBS Pro job the Task Manager interface is used to invoke processes on other nodes that are assigned to the job. Those processes are then tracked by the remote moms as being part of the job. One must first compile MPI with task manager integration for this to be possible. You may also want to explore pbsdsh as a means of invoking a remote process, but that may not work properly with GUI based applications.
Thanks for the lead, mkaro. From my understanding of the command you’ve suggested, that’s start an interactive session and then runs xterm from within it. The difference with “vglconnect -s” is that it would need to run on the submission host to initiate and and, on connection it kicks off a process on the execution host which listens for the VGL traffic and tunnels it back through.
vglconnect, itself, is a wrapper script which uses ssh under the hood so, once kicked off, the persisitent process is just an an ssh connection.
So the issue is not so much handling what’s running on the execution host but how the connection is initiated and maintained from the submission host.
Still, I’ll do some reading and testing and see if any other connection methods can get me what I’m after.
Cheers!