Thanks John for your response. Unfortunately, setting the -l in the header did not keep the VMWare window open. Do you or anyone else have any other suggestions?
Thanks, Sean On Fri, Jun 2, 2017 at 10:59 AM, John Hearns <[email protected]> wrote: > Sean, > this sound slike the difference between interactive and non-interactive > shells. > > When you log in directly to the node, you have an interactive shell and > the environment is set up, and /etc/profile.d scripts are sourced. > Someone will be along in a minute with the correct answer, however try > submitting with #!/bin/bash -l > > > > > On 2 June 2017 at 01:18, Sean M <[email protected]> wrote: > >> Greetings, >> >> I am trying to schedule a VMWare VM to start automatically but once the >> slurm script is submitted and executed, VMWare launches, it's window >> appears, and closes immediately without launching the VM. When I run VMWare >> with "nogui", the VM also does not run. For these cases, there are no >> errors in the VMWare or slurm logs. Also, if I schedule just VMWare to >> open, it opens but requires human interaction to launch the VM, which is >> not feasible for my use case. >> >> On my base case, I have two machines: my node is running Ubuntu Desktop >> 17 and the controller Ubuntu Server. >> >> I have tried two methods. >> Method 1: My controller submits a script with the following command: >> vmrun -T ws start <path to the .vmx file> >> >> Method 2: My controller executes a bash script on the node. The node's >> bash script has the following command: >> vmrun -T ws start <path to the .vmx file> >> >> Both methods have the same result: the VMWare window appears briefly and >> then closes. The VM launches perfectly if I execute Method 2's bash script >> directly on the node; the bash script is owned by the same user and group >> with root access on the node and controller and has 777 rights. Here is a >> weird thing, if I change method 1's script (on the same line) to ssh into >> the node and launch the vmrun command, the VM successfully starts >> automatically. The ssh solution is not ideal because I will not know in the >> future which node will get the job. Any suggestions on how to resolve this >> issue? >> >> Thanks! >> Sean >> > >
