I have a Windows Azure VM running VS2013 Load Test Controller and a second Azure VM running 2013 Load Test Agent.
I have not been able to get the two communicating successfully. I added the hostname and IP of each VM to the other's HOSTS file. I also created a local admin account with the same username and password on both machines. Neither machine is joined to a domain. I have also created endpoints for each VM to port 6901/TCP. I am able to telnet from the agent VM to port 6901 on the controller VM.
When I apply the test agent configuration settings, it fails on "Test agent could not connect to the test controller." In the agent configuration log, I see:
Could not get the status from the test agent. Exception: Failed to
connect to an IPC Port: The system cannot find the file specified.
In the event viewer, I see:
Unable to connect to the controller on 'controllerVM:6901'. The agent
can connect to the controller but the controller cannot connect to the
agent because of following reason: A connection attempt failed because
the connected party did not properly respond after a period of time,
or established connection failed because connected host has failed to
respond 168.62.XX.XX:6910. Make sure that the firewall on the test
agent machine is not blocking the connection.
I have been completely unable to work around this issue so far. I need help please.
Can you Check your c:\windows\system32\drivers\etc\hosts file both agent and controler .
If there is an entry assigned to 127.0.0.1 remove that.
When you install the Agent/Controller, be sure to use the same user (Admin) Account (Run as...). This account have to be in the group TeamTestAgentService on the controller.
In addition, after setup, the wizard will try to connect agent to the test controller. What's the status ?
MSDN explains here how to install/configure the test rig in a workgroup.
There is also a complete troubleshoot guide here.
Related
I was trying to execute the JMeter jmx scripts in Microsoft Visual Team Services (VSTS), The scripts were working fine when executed using JMeter tool[GUI as well Non-GUI mode] but when tried to execute the same in VSTS, I was facing the below mentioned issues,
1) Non HTTP response message: Connection refused: connect – For localhost application,
2) Non HTTP response code: java.net.UnknownHostException – When used to run using IP address.
It looks like you're trying to test application deployed locally from Internet. Make sure you're using public IP address instead of private, you can determine it using service like What Is My IP?, however you need to ensure your application is not behind NAT and VSTS host(s) can reach it. It might be also a matter of firewall configuration preventing inbound connections from VSTS hosts(s).
See Top 3 Options for Running Performance Tests Behind Your Corporate Firewall article for more information and possible solutions.
I'm trying to install oracle on AWS redhat instance. Follow the steps given on this url: http://www.davidghedini.com/pg/entry/install_oracle_11g_xe_on And when I run config command as follows
/etc/init.d/oracle-xe configure
It gives following error.
Database Configuration failed. Look into
/u01/app/oracle/product/11.2.0/xe/config/log for details
When I check the log files it shows following errors.
ORA-01034: ORACLE not available Process ID: 0 Session ID: 0 Serial
number: 0
It seems specific issue on AWS cloud instance.
Is it because of swap memory?
Or is it because of port issue?
I'm using micro instance on it.
How can I get through?
this might be an EC2 security group issue and outbound access to the network on some port being used by the installer (license check, maybe?).
if your EC2 instance is very tightly locked down, you could test if it's a security group issue by adding a new Outbound security group rule to allow all TCP traffic out to anywhere on the internet (0.0.0.0/0)
for example, the install might be trying to hit a remote licensing server endpoint via HTTP or HTTPS but your security group doesn't allow that traffic out.
perhaps there's a 'verbose' flag that you can run the installer with that can give you more info about what it's failing on? HTH
Why would a Visual Studio Web Deploy have a failure of "unexpected error occurred on a send" when publishing to an intranet site that resolves as an IPv6 address? I am assuming IPv6 had something to do with it because adding the IPv4 address to the hosts file resolves the issue and the web deploy succeeds.
Details:
Initially the build error came from a TeamCity build agent, but the same issue occurs when attempting to publish (or just validate the connection in the publish profile) from Visual Studio.
A ping (successful) to the target machine resolves to an IPv6 address which is identical to the address found from running "ipconfig" on the target machine itself, except for a different Scope ID on the tail end.
Windows UNC share paths to the target machines work fine
The target machine is actually the host of the VM on which the build agent runs.
Below is the error from validating connection on publish profile.
And detail from the original build/deploy attempt.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4276, 5): Web deployment task failed. (Could not complete the request to remote agent URL 'https://tapserver:8172/msdeploy.axd?site=MealPlannerCIAPI'.)
This error indicates that you cannot connect to the server. Make sure the service URL is correct, firewall and network settings on this computer and on the server computer are configured properly, and the appropriate services have been started on the server.
Error details:
Could not complete the request to remote agent URL 'https://tapserver:8172/msdeploy.axd?site=MealPlannerCIAPI'.
The underlying connection was closed: An unexpected error occurred on a send.
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
An existing connection was forcibly closed by the remote host
Again I've fixed the issue, but it is a very baffling fix to me. What would break any of the msdeploy calls that is fixed by adding the IPv4 address to the hosts file when it is clearly already reaching that host using v6?
Have you checked the Option IP Address Restrictions in the Management Service-Configuration (IIS)?
Please be aware that you're always connecting with your local IPv6 address if you try to access an IPv6 target. If you have configured any restrictions, they won't apply for your IPv6 address as the restriction configuration is not compatible with IPv6. So your connection attempt will be declined automatically if you set Access for unspecified clients to Deny.
My setup is as following:
Domain A: Visual Studio 20120 on my local workstation, pointing to my controller via an IP address
Workgroup (non-Domain): Visual Studio 20120 test controller in Amazon's EC2 cloud
When trying to connect my Visual Studio to the controller I received the following error "Cannot connect with controller ... The server has rejected the client credentials. The logon attempt failed"
To deal with that issue, I've created, on my workstation, a new local (non-domain) user with the same name and password as the user/password combination on the cloud.
Once I did that, I started an instance of Visual Studio as that user (using "Run as") and tried again. That gave out a different error message:
"the requested name is valid but no data of the requested type was found"
Turns out that what Visual Studio is actually complaining about (in a very obscure way) is that it is able to connect to the controller by the IP address, but it is unable to connect to its via its hostname.
To resolve it, I had to connect to my controller computer and get its hostname. Then I went to my hosts file (C:\Windows\System32\drivers\etc) and added the hostname as well as the ip address.
With that done, Visual Studio successfully connected to the controller.
I had a similar issue. I've notice some weird quirks when having the test controller in the domain, and the agents outside my network in workgroup computers. The controller seems to try to connect back to the agents using their netbios name, so you need to add that hostname to your hostfile with the public IP address if it isn't in your internal DNS. The agent seems to try to connect to the controller using the FQDN (active directory domain, not internet domain) of the controller, so that needs to go in the host file of the agent. You need to have the same account name and password for the agents and controller. If your controller is on a separate computer from your test manager, you need to have the controller service account be a domain account with the same username/password as the local service account on the agents. I have a complete walkthrough of what I did to make it work at http://nerdsknowbest.blogspot.com/2013/10/how-to-setup-visual-studio-tfs-test-agents-cloud.html if it helps you, or anybody else. Also, if you have anything in the hosts file that points to 127.0.0.1, comment it out.
I have set up a Server and a BuildAgent on Amazon Ec2. I have configured the build agent to sit in the /home/ec2-user/build-agent directory (will this cause problems due to permissions?)
I then configured the build agent to point to the server through the public dns and port 8111. I have then started the build agent.
I used the Cloud Tab on the TC Web interface to setup the Build Agent on the server. I can see on the build agent host machine that a connection with the server has been established. Yet in the web interface I can see no build agents in either the unauthorized tab or the compatible tabs.
In short I cannot connect a build agent to the server?
Any help or ideas on this one would be greatly appreciated.
many thanks
Dermot