503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http16LocalServiceSpecE:0x7fc8bad2f810] _serverNamespace = /vsphere-client _isRedirect = false _port = 9090)
This is the error i'm constantly getting when trying to connect to the vCenter Server Web Client.
Details :
I'v installed the vCS Appliance 6.0 on an ESXi 6.0 host. It's running on top of it along other VMs.
I can access the vCS appliance thourght an SSH client, but every attempt to access the web client ends with the error above.
I'v found that causes for this error are: the server being overloaded or under maintenance. However, I'm the only one to have access to this platform.
Any ideas ?
EDIT: Solved
I had a copy of the current vCenter appliance stored on the same ESXi. This created an IP conflict. I changed the IP address of the backup before its creation and the problem was solved
I found the answer:
The problem was that I made a backup of the current vCenter appliance and stored it on the ESXi 6.0 without changing it's IP address. This created an access conflict. All I had to do is to change the IP address of the backup during its creation and the problem was solved
I was getting that 503 error, but my case was a little different:
I changed the IP address of my VCSA 6.0 Update 2 plus its default gateway via the GUI (https://x.x.x.x:5480).
I was able to ping it and ssh into it afterwards, but I was not able to login using either the old (thick) client or the web client. Both were giving me the 503 Server error.
I tried rebooting, but nothing.
After the reboot, I SSHd into it and was able to see that the web client service was not running. The vpxd service was running though. So I started it:
vcsa6:~ # service vsphere-client status
VMware vSphere Web Client is not running.
vcsa6:~ # service vmware-vpxd status
vmware-vpxd is running
vcsa6:~ # service vsphere-client start
Last login: Sat Dec 10 23:40:00 UTC 2016 on console
Starting VMware vSphere Web Client...
Waiting for VMware vSphere Web Client......
running: PID:22433
vcsa6:~ # service vsphere-client status
VMware vSphere Web Client is running: PID:22433, Wrapper:STARTED, Java:STARTED
I was still getting the 503.
I found then this link, which basically told me to edit the /etc/hosts file of the VCSA and voila: the VCSA FQDN entry in there was still pointing to the old IP address. I changed it and rebooted and now both clients, web and thick, work as before.
I had 503 error issues on my lab/test vCenter 6.0 Update 1. I installed the integrated VCSA on a host that has limited memory, so I dropped the default 8G RAM and multiple CPU to 1 CPU and 4G. I would not go below those and use the default values if you can as webclient 503 errors occur and inventory service connection issues arise without the required RAM. I experienced no issues on the fat client.
I've solved it with:
/etc/init.d/vpxa restart
Then I had some problems with hostd.
/etc/init.d/hostd restart
It worked great after.
ESXi 6.5 here.
check to see if the vmware-vpxd is not stopped. If it is, start it.
-Putty into vcenter (VCSA)-
Related
I am installing VMware vSphre ESXi 7.0.2. But I cannot use web client (http://<ip_address>/ui)
When installed first time, I can connect with https://<IP_address> (It will be redirect to https://<IP_address>/ui ) and can create VM. But I found I cannot use some SDD/HDD. So I have re-installed ESXi after created the RAID partitions.
Re-Install was look OK, and I can see DCUI and set IP, DNS etc... After all set, I've tried to use https://<IP_address>. But it was timed out. (I have checked several things, then I found the ping does not work.)
I restarted the server then ping is OK. But when I try to connect with https://<IP_address> then the ping became "Destination net unreachable". (I have confirmed it with "-t" option.)
I thought it is firewall settings. So, I changed "--default-action" and "--enabled" but it still not working. Just in case, I have stop to use RAID disks and re-install it again (it is same as first installation), but it was same results.
There's likely still a networking-related misconfiguration. Use DCUI to verify IP/subnet mask/gateway/VLAN tag (if necessary) and that the appropriate NIC has been configured.
If those are set correctly, the DCUI also has some built-in testing options which allows you to do some outbound ping testing. By default it will check 3 hosts, including the gateway and usually two DNS names, but those can be changed to other options.
Recently our Sharepoint server 2013 database was upgraded from SQL server 2008 R2 to SQL server 2012 SP4. This has resulted in several issues.
There now two servers created in a single server farm one representing IP address and the other having host name. Both of the servers are having full set of services. Earlier it was only one server showing the host name
The search service is not running.
The Start and Stop of services on the server with IP address completes successfully, but on the server having the host name get stuck on starting or stopping stage.
Recreation of service applications like search service or user profile service also gets stuck and never complete
There are also two timer service instances, one for each machine, but starting or stopping any of them never gets completed and remains stuck.
What I want.
Only one server in the farm showing host name
All the services working i.e not getting stuck in starting stopping and service application like search and user profile working.
Server has just one application for port 80 and one for CA
This is a production server and each day 1500 to 2000 tasks are generated and similar number of workflows are run this means I cant risk outage.
Thanks in advance
Regards
Imran
Solved Search Service Issue
Stored the Search Service Application
$ssa=Get-SPEnterpriseSearchServiceapplication -Identity XXXXXXX
Stored Service instance
$si = $ssa.service.Instances
Noticed that the proxy for Search service application was also not created
created proxy
$proxy=New-SPEnterpriseSearchServiceApplicationProxy -SearchApplication $ssa
Set the admin component by
Set-SPEnterpriseSearchAdministrationComponent -SearchApplication $ssa -SearchServiceInstance $si
Noticed that Search Administration Web Service for Search Service Application was showing Stopped and Search Service Application was showing Error status, started by
$ssa.Provision()
Checked the status of both the Service Applications it was showing started
Checked the admin component by
$ssa.AdminComponent
It was showing server name
At least one of my problems was solved and my users are able to do searches. I still have to resolve other issues.
I am newbie to VMware. When I am longing into the VCenter I am getting "Connection time out" in first 3 attempts, after 3 attempts I am able to Login to VCenter.
I did some troubleshoot and in vcenter changed the Client to server time extended to 300sec. But still I am facing same issue. Can anyone please help me how to resolve this issue.
Thanks in advance
Are you connecting by IP or hostname? Make sure DNS is OK. Are you using a standalone MSSQL server? Windows server built-in MSSQL? Is this VCSA (linux appliance)?
If Windows, did you reboot everything? Slowness within vCenter can indicate a sql issue of sorts. Check all applicable items for available resources, including disk space on all partitions.
I'm using AWS to host my Chef server, and I've connected to it from my workstation using Knife. However, after shutting down and turning the server on, the Public DNS changed, and I'm unable to reconnect to the server, resulting in this message:
ERROR: Error connecting to https://*.compute-1.amazonaws.com/organizations/*/cookbooks?num_versions=all
Is there any way to change the address of the Chef server on the workstation without making the workstation think it's connecting to an entirely new server?
You need to reconfigure the Chef Server, possibly updating it's config file first to ensure the right hostname is in the right places. After that, make sure you update the chef_server_url in the knife.rb or client.rb of every machine.
I am migrating my vCenter Server 5.5 to a new server (databases have already been moved to a new SQL server and all is OK on existing vCenter Server 5.5 implementation). When I begin the simple install process on the new vCenter Server host the Single Sign-On component presents me with an IP address of 10.10.10.117 as the ip address of the FQDN file01.xxxxxxxxx.com. This is the iSCSI interface address. I need it to use the 10.1.1.17 ip address that is the address of the production NIC that the ESXi 5.5 hosts will be communicating with. I have already changed the binding order of the NIC cards and flushed the DNS cache. I also added file01.xxxxxxxx.com with the proper IP address to the hosts file and also file01 to the hosts file. Still, during the install, 10.10.10.117 is discovered. Thanks in advance! Babak C.
Just to get a quick clarification...are you freshly installing vCenter 5.5? Or are you migrating an existing vCenter server to a new host and using the update utility to upgrade? I am assuming you are doing a fresh install based on your details about the SQL server and SSO. Here is my suggestion, in case it is a fresh install.
We had a similar problem with 5.5 on a new install where the IP address that was discovered during the actual vCenter Server install was that of the public facing NIC which we never use for management traffic (it's for internet access on the vC server, for update manager, etc.)
The strange thing is that there had NEVER been an entry in ANY of our DNS servers for that interface. So, after looking into it a little bit, I started thinking the IP that was returned during install was not a DNS result at all. Rather, it was (most likely) simply gathered from the interfaces on the Server based on binding order (e.g. which NIC has the default gateway.)
In order to save having to uninstall and clean up a major mess if the install completed wrong, we stopped and got in touch with VMware support. They suggested we clear all of the temporary files both in the standard "temporary" folder on windows as well as under /ApplicationData/vmware/xxx, where 'xxx' would be whatever product is giving you trouble and HAS NOT been FULLY INSTALLED* (e.g. you started the install and noticed the incorrect IP, so you terminated the installer and there is metadata and cached files remaining from the partially run install).
Basically, what we had to do, was clear the temporary files and then make sure the NIC Binding Priority was correct (so you should check in Network Adapters|(press-alt)|Advanced Settings. Make sure the correct binding is checked (e.g. if you don't use IPv6 on the private network, clear it) and make sure that the Windows Network is at the top of the priority list on the second pane of the advanced settings. This helps tremendously with SSO by making sure the Windows Network stack is the first queried when you are signing in and SSO must submit a kerberos ticket to the AD DC for validation.
It is possible, that once you delete the partial install files and temporary files and fix the network settings (probably be a good idea to reboot as well), the next time you run the installer you might have success.
I will try to check this post later to see if it helped you at all... or it I just succeeded in making your life even more difficult (which I certainly hope not!) :)
One more thing...prior to initializing the installer, open up a PS session, perform ipconfig /flushdns and then ping the hostname of your vCenter server in order to get it in the DNS cache. You should also perform the following:
nslookup
NS>{your vcenter server IP address}
/* make sure the resulting hostname is correct..this ensures your PTRs and rDNS is working correctly. vCenter HEAVILY relies on accurate reverse DNS configuration...then do the following lookup for forward DNS */
NS>{your vcenter server FQDN}
Hope it helps. Best of luck my friend!
SIETEC