Validating Migratable VM and LSF Communications
Validation of Migratable VM Joined to Your LSF Cluster
The script test_createVm.sh exists for a quick validation that new compute resources can successfully connect and register with the scheduler.
./test_createVm.sh -h xvm0 -i <IMAGE_NAME> -u user_data.sh
The hostname specified with
-h xvm0is arbitrary.The Image Name specified with
-i <IMAGE_NAME>should correspond to the Image Name from theparse_helper.shcommand and the environment setup earlier.The
-u user_data.shis available for any customization that may be required: temporarily changing a password to faciliate logging in, for example.The
test_createVm.shscript will continuously output updates until the VM is created. When the VM is ready, the script will exit and you’ll see all the fields in the output are now filled with values:- CODE
Waiting for xvm0... (4) NodeName: xvm0 Controller: az1-qeuiptjx-1 Controller IP: 172.31.57.160 Vm IP: 172.31.48.108
With the
Vm IPabove,sshto the node and to inspect the compute node. This step is meant to provide a migratable VM so that sanity checking may occur:Have network mounts appeared as expected?
Is authentication working as intended?
What commands are required to finish bootstrapping?
Et cetera.
Iterate and validate as many times as required to satisfy all requirements.
Lastly, LSF services should be started at the end of bootstrapping.
It may take 5 minutes or longer for the LSF services to register with the LSF Master Host.
When the RC Execution Host is properly registered, it will be visible via the
lshostcommand.
To remove this temporary VM:
Replace VM_NAME with the name of the VM ,
-h xvm0example above.- CODE
curl -X DELETE http://${MGMT_SERVER_IP}:5000/v1/xcompute/vm/VM_NAME
When totally satisfied, place final versions of the
user_datascripts in the${LSF_RC_CONF_DIR}/exostellar/confdirectory.There needs to be a per-pool
user_datascript in that folder. It can be overwritten at any time a change is needed and the next time a node is instantiated from that pool, the node will get the changes.A common scenario is that all the
user_datascripts are identical, but it could be beneficial for different pools to have differentuser_databootstrapping assets. If they are identical, links can be placed in the${LSF_RC_CONF_DIR}/exostellar/confdirectory instead of individual files.The auto-generated
user_datascripts are initially located in${LSF_RC_CONF_DIR}/exostellar/scripts. After copying them to${LSF_RC_CONF_DIR}/exostellar/confand modifying them, be sure to set their permissions so LSF can use them, e.g.:CODEchown lsfadmin.root ${LSF_RC_CONF_DIR}/exostellar/conf/*_user_data.sh