I have an application running in a VirtualBox VM that for testing purposes needs to connect to the host machine. The VM is started with Vagrant and managed by Puppet.
What is the best way to set-up this connection? For example, om my host machine the app runs on port 9200. So from my VM I'd like to go to myhostmachine:9200.
Currently I'm thinking of hacking in a small command that adds hostvm as a entry to /etc/hosts using a simple command like this to figure out my host ip (which is the same as the default route).
/sbin/ip -4 route list 0/0 | grep -m 1 default | awk '/default/ { print $3 }'
And just let Puppet run that every time using the exec functionality. However, I get the feeling there has to be a better way.
The guest OS is Ubuntu 12.04 and the Host is OS-X.
Thanks!
As far as I know, at the moment Vagrant always sets up a natted interface to connect to virtualbox, so I think that the ip of your host machine will always be the 10.0.2.2 address you mentioned. I reckon a puppet host declaration might be easier to manage than running that command each time.
host { 'myhostmachine':
ip => '10.0.2.2',
}
The puppet resource reference for hosts has all the other params you can set too.
I was then able to access the host using myhostmachine:9200
Related
I am new to mininet and I was trying to build a mininet topology which uses a remote SDN controller.
I tried using floodlight as the remote controller. I installed it and ran it and it is running on "localhost:6653". But it is also running on 192.168.122.1:6653 (And I have no idea why).
192.168.122.1 is my virbr0 interface's address. In my mininet VM which is in virtualbox i have two network adapters.
NAT
Host only adapter
And for host only adapter i have the following configuration.
Adapter settings:
Ipv4 address: 192.168.56.1 and net mask: 255.255.255.0
DHCP server settings: Sever ip= 192.168.56.100; net mask= 255.255.255.0; Lower bound Ip: 192.168.56.101; Upper bound Ip: 192.168.56.254
To avoid confusion i have added the screenshots as well.
I tried the following command to build my topology:
sudo mn --controller=remote,ip=192.168.122.1,port=6653
I get the following response from mininet
Unable to contact remote controller 192.168.122.1:6653
I have tried changing ip to 192.168.56.1 but that also didn't work.
Any kind of help will be appreciated.
Thanks.
As per your setup, I guess FLC is running on Host OS and mininet is running in Oracle VM.
Your Host-Only network is useful if you are trying to reach something deployed in VM from your Host Os.
It will not work other way around. Here you want to access FLC running on Host inside your VM.
I would suggest using Floodlight VM for Virtual Box. It has mininet and FLC inbuild.
Once imported. Start VM.
Credentials: floodlight/floodlight
Inside VM start FLC
Do ifconfig ithe n terminal and get IP
change to that IP in this
sudo mn --controller=remote,ip=192.168.122.1,port=6653
and execute, all will work fine.
You can access FLC in Host using above IP
While registering a host to the cluster of Ambari-server, I am getting the following error.
"Host checks were skipped on 1 hosts that failed to register."
I'm trying to install HDP 2.5 version on the instance of AWS.
I have tried to follow the documentation of Hortonworks.
https://docs.hortonworks.com/HDPDocuments/Ambari-2.5.0.3/bk_ambari-installation/content/set_the_hostname.html
I have added public ip address and public hostname to /etc/hosts file and change the name of host in /etc/hostname file on the server and on the host. Rebooted both, hostname got changed. Then I have stop iptables by
sudo service iptables stop
After doing everything, the host registration is still failing. Kindly help. I am stuck.
Background
From my experience with Ambari (Hortonworks) you have to explicitly setup your Hadoop nodes in each other's /etc/hosts file with the actual name/IPs that the Hadoop services will bind to. NOTE: hostnames should also be FQDN - fully qualified domain names.
For example if you're setting up the hosts as:
node01.mydom.com (10.0.0.2)
node02.mydom.com (10.0.0.3)
node03.mydom.com (10.0.0.4)
These entries should be in all 3 server's /etc/hosts and these should be the names used when referencing them within Ambari's installation/setup wizards.
If you do not pay special attention to this detail, Ambari's server will fail to find/manage any of the other node's that you're telling it to manage.
hostname of ambari-agents
The other item to look at is that the ambari-agent's and what hostnames they think they're going as.
$ ps -eaf|grep ambari_agent
root 3282 1 0 Jul30 ? 00:00:00 /usr/bin/python /usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py start --expected-hostname=node01.mydom.com
root 3290 3282 1 Jul30 ? 08:24:29 /usr/bin/python /usr/lib/python2.6/site-packages/ambari_agent/main.py start --expected-hostname=node01.mydom.com
Debugging further
In the screen where you're attempting to register the other nodes as agents, there's a full log of what's happening and you can typically get the commands from this area and attempt to run them directly. I've done this on a number of occasions. The commands will often be python ... commands which you can then copy/paste from the logs and run on the Ambari server where you're attempting to run the install.
My vagrant setup for the network is config.vm.network :private_network, ip: "192.168.56.101". If I'm accessing a php page with echo $_SERVER['REMOTE_ADDR']; I got 192.168.56.1 as result. The problem now is that I can't ping 192.168.56.1, so also the config for Xdebug with xdebug.remote_connect_back=1 will fail, because Xdebug tries to connect to 192.168.56.1. If I use my normal ip address with xdebug.remote_host=X.X.X.X everything works fine, but I want to use xdebug.remote_connect_back=1. What can I do that it will work?
I was having the same problem and then started up a Virtualbox manually and realized that I hadn't started a virtualbox since updating and the firewall had to updated. Once I restarted virtualbox I could ping 192.168.56.1 and not have to rely on a hard coded ip address. So, my guess, is that you probably have firewall issues.
Okay so I have my actual laptop which has vmware player installed. I am running lubuntu as a virtual machine and I installed django on the virtual machine and am testing my app so I did python manage.py runserver and I can access the app by visiting 127.0.0.1:8000 from my VM, however, If I go to 127.0.0.1:8000 from the actual computer (not the VM), it says 'chrome could not connect to 127.0.0.1:8000'.. Any idea how to fix it?
You can try running the server on 0.0.0.0
python manage.py runserver 0.0.0.0:8000
The IP address 0.0.0.0 means "all IP addresses on the local machine" (or all IPv4 addresses on the local machine).
Next, you will need the ip address of your VM. Visting http://<ip_address_of_vm>:8000 on other computers should access the django development server on your VM.
Note: If your VM only has an internal IP (e.g. 192.168.x.x) then only computers on the same network can visit the VM.
I was able to get #Kerberos answer to work. (not enough points to comment so I'm adding it as a seperate answer).
I am running Ubuntu 12.04 LTS in a guest OS in VMWare. The host laptop is running Windows 8.
As mentioned by Kerberos, in VMWare, go to Player ==> Manage ==> Virtual Machine Settings...
On the Hardware tab, select Network Adaptor, then select the radio button for Bridged: Connect directly to the physical network. Select OK
In the VM, the network connection information should now have the same IP address of the host OS internet connection. In my case: 192.168.1.141 (yours will vary).
In the VM, start Django using python manage runserver 192.168.1.141:8000
Using this method, I am able to access the webserver running in the VM at this IP address from within the VM, from host machine, and from other systems on the same 192.168.1.xxx network.
to access virtual machine (guest) from outside the host computer, you have to set the guest network mode to bridge
Bridge-mode connects the guest to the actual network so that other machines can connect to it
I have to do distributed testing using JMeter. The objective is to have multiple remote servers in AWS controlled by one local server send a file download request to another server in AWS.
How can I set up the different servers in AWS?
How can I connect to them remotely?
Can someone provide some step by step instructions on how to do it?
I have tried several things but keep running into connectivity issues across networks.
We had a similar task and we ran into a bunch of issues as well. Here are the details of the whole process and what we did to resolve the issues we encountered. Hope it helps.
We needed to send requests from 5 servers located in various regions of the world. So we launched 5 micro instances in AWS, each in a different region. We chose the regions to be as geographically apart as possible.
Remote (server) JMeters config
Here is how we set up each instance.
Installed java:
$ sudo apt-get update
$ sudo apt-get install default-jre
Installed JMeter:
$ mkdir jmeter
$ cd jmeter;
$ wget ftp://apache.mirrors.pair.com//jmeter/binaries/apache-jmeter-2.9.tgz
$ gunzip apache-jmeter-2.9.tgz;tar xvf apache-jmeter-2.9.tar
Edited the jmeter.properties file in the /bin folder of the JMeter installation and uncomment the line containing the server.rmi.localport setting. We changed the port to 50000.
server.rmi.localport=50000
Started JMeter server. Make sure the address and the port the server reports listening to are correct.
$ cd ~/jmeter/apache-jmeter-2.9/bin
$ vi jmeter-server
Local (client) JMeter config
Then we set up JMeter to run tests remotely on these instances on our local client machine:
Ensured to use the same version of JMeter as was running on the servers. Installed Java and JMeter as described above.
Enabled remote testing by editing the jmeter.properties file that can be found in the bin folder of the JMeter installation. The parameter remote_hosts needed to be set with the public DNS of the remote servers we were connecting to.
remote_hosts=54.x.x.x,54.x.x.x,54.x.x.x,54.x.x.x,54.x.x.x
We were now able to tell our client JMeter instance to run tests on any or all of our specified remote servers.
Issues and resolutions
Here are the issues we encountered and how we resolved them:
The client failed with:
ERROR - jmeter.engine.ClientJMeterEngine: java.rmi.ConnectException: Connection - refused to host: 127.0.0.1
It was due to the server host returning the private IP address as its address because of Amazon NAT.
We fixed this by setting the parameter RMI_HOST_DEF that the /usr/local/jmeter/bin/jmeter-server script includes in starting the server:
RMI_HOST_DEF=-Djava.rmi.server.hostname=54.xx.xx.xx
Now, the AWS instance returned the server’s external IP, and we could start the test.
When the server node attempted to return the result and tried to connect to the client, the server tried to connect to the external IP address of my local machine. But it threw a connection refused error:
2013/05/16 12:23:37 ERROR - jmeter.samplers.RemoteListenerWrapper: testStarted(host) java.rmi.ConnectException: Connection refused to host: xxx.xxx.xxx.xx;
We resolved this issue by setting up reverse tunnels at the client side.
First, we edited the jmeter.properties file in the /bin folder of the JMeter installation and uncommented the line containing the client.rmi.localport setting. We changed the port to 60000:
client.rmi.localport=60000
Then we connected to each of the servers using SSH, and setup a reverse tunnel to port 60000 on the client.
$ ssh -i ~/.ssh/54-x-x-x.us-east.pem -R 60000:localhost:60000 ubuntu#54.x.x.x
We kept each of these sessions open, as the JMeter server needs to be able to deliver the test results to the client.
Then we set up the JVM_ARGS environment variable on the client, in the jmeter.sh file in the /bin folder:
export JVM_ARGS="-Djava.rmi.server.hostname=localhost"
By doing this, JMeter will tell the servers to connect to localhost:60000 for delivering their results. This ends up being tunneled back to the client.
The SSH connections to the servers kept dropping after staying idle for a little bit. To prevent that from happening, we added a parameter to each of the SSH tunnel set up directing the client to wait 60 seconds before sending a null packet to the server to keep the connection alive:
$ ssh -i ~/.ssh/54-x-x-x.us-east.pem -o ServerAliveInterval=60 -R 60000:localhost:60000 ubuntu#54.x.x.x
(.ssh/config version of all required SSH settings:
Host 54.x.x.x
HostName 54.x.x.x
Port 22
User ubuntu
ServerAliveInterval 60
RemoteForward 127.0.0.1:60000 127.0.0.1:60000
IdentityFile ~/.ssh/54-x-x-x.us-east.pem
IdentitiesOnly yes
Just use ssh 54.x.x.x after setting this up.
)
I just went though this on openstack and found the same issues... no idea why the jmeter remoting documentation only covers half the required steps. You can do it without tunnels or touching the properties files.
You need
All nodes to advertise their public IP - on AWS/OS this defaults to the private IP
Ingress rules for the RMI port which defaults to 1099 - I use this
Ingress rules for the RMI "local" port which defaults to dynamic. Below I use 4001 for the client and 4000 for servers. The port can be the same but note the properties are different.
If you are using your workstation as the client you probably still need tunnels. Above Archana Aggarwal has good tips for tunnels.
Remote servers
Set java.rmi.server.hostname and server.rmi.localport inline or in the properties file.
jmeter-server -Djava.rmi.server.hostname=publicip -Dserver.rmi.localport=4000
Sneaky server on client
You can also run one on the same machine as the client. For clarity I've set java.rmi.server.hostname but left server.rmi.localport as dynamic
jmeter-server -Djava.rmi.server.hostname=localip
Client
Set java.rmi.server.hostname and client.rmi.localport inline or in the properties file. Use -R etc like so:
jmeter -n -t Test.jmx -Rremotepublicip1,remotepublicip2 -Djava.rmi.server.hostname=clientpublicip -Dclient.rmi.localport=4001 -GmypropA=1 -GmypropB=2 -lresults.jtl
When you go for distributed testing using JMeter in AWS, I would suggest you to use docker - which will help us with jmeter test infrastructure very quickly. This way we can also ensure that same version of java and jmeter are installed in all the instances of amazon which is very important of JMeter distributed testing.
Ensure that - you set below properties and ports are open for jmeter-server. [they do not have to be 1099,50000 exactly]
server.rmi.localport=50000
server_port=1099
java.rmi.server.hostname=SERVER_IP
for client
client.rmi.localport=60000
java.rmi.server.hostname=SERVER_IP - this step is very important as the container in aws instance will have their own IP address in the docker network - so master and slave can not communicate. So we explicitly set this property
More info:
http://www.testautomationguru.com/jmeter-distributed-load-testing-using-docker-in-aws/