Using the vmx pdf from last year as a rough guide, I have a centos 7 ec2 setup that connects to my local farm via openvpn. It’s working well for the most part, but the one issue I seem to be running into is that the slaves are using their eth0 ip’s when connecting to the repository rather than their openvpn ips. They still seem to operate regardless, but the one issue I’m running into is that I can’t get remote commands through to the machines because:
A) Hostnames and fqdns aren’t correctly resolving over openvpn
B) The IP addresses the slaves are reporting are their internal amazon ip’s rather than their openvpn ip’s
I’m using a bridge (tap) rather than a tunnel (tun), as it makes sharing local smb mounts pretty straightforward. I don’t run a local DNS or WINS server so I’m really leaning on being able to use the ip’s for remote commands.
It looks like it’s possible to manually override slave ip’s in the monitor, but that will end up being a lot of management and cross checking as new instances cycle in and out of the farm. Is there any way to have deadlineslave poll a different adapter for its ip address? Or is there any other variable or file that the slave is sourcing to determine the ip?
I’m also noticing that idle remote slaves are being called out as needing to be shutdown in Pulse, but the remote machines never terminate. Given that the remote machine commands can’t get through due from the Monitor, I’m guessing the Pulse shutdown commands are failing too. Also, the remote machines seem to be unable to connect to Pulse over the vpn (even with firewalls disabled on both ends).
Sounds like the best solution is to get the routing sorted so that the IPs make sense both from the cloud and through the VPN. This is rather hard to troubleshoot though text, so I think it would be best to schedule a support call, where we can TeamViewer in and help troubleshoot the configuration. Please send me a private message, and we’ll schedule a time that works.
After some internal discussion, I think I misunderstood the issue. I think you are right in your approach of overriding the Slave settings to use the tap0 IP address. There is currently no mechanism that I’m aware of to specify which adapter to use for the IP address. We will likely add this to the wish-list, but I want to have further internal discussion to explore various approaches. As a workaround, it may be possible to push the tap0 IP address to the Slave settings via a script that is run when the VM starts up. Let me look into that.
I have attached a workaround script for this issue. It’s a bash script that should be run on the virtual machine at startup, after the VPN is established and the tap0 IP has been assigned. It will tell Deadline to use the tap0 IP address.
This script requires 7.0.0.50 (RC4) or later, due to a minor fix to allow the SetSlaveSetting command to work properly. Please give it a try and let me know if it resolves the remote commands issue. setslaveip.zip (476 Bytes)
Success! I had to make a few adjustments to the script just due to a slightly different ifconfig output, but here’s what ended up working:
#!/usr/bin/bash
# This script sets the HostMachineIPAddressOverride value in Deadline to the IP address of the tap0 interface.
# This allows remote commands to work over a VPN.
# Run this script on virtual machine startup, after the VPN connection has been established.
function int-ip { /sbin/ifconfig $1 | grep "inet" | awk 'FNR==1 {print $2}'; }
TAP0IP=`int-ip tap0`
echo Found tap0 IP: $TAP0IP
echo Running: ./deadlinecommand SetSlaveSetting $HOSTNAME HostMachineIPAddressOverride $TAP0IP
RESULT=`./deadlinecommand SetSlaveSetting $HOSTNAME HostMachineIPAddressOverride $TAP0IP`
echo $RESULT
It’s working great and the EC2 machines are now able to be remote administered. Thanks for the support on this!