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
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.
I have a Google Cloud compute instance running with Ubuntu 18. We had wireshark running tracking another problem and we noticed that every minute something is accessing the meta data server. Three requests every minute:
GET /computeMetadata/v1/instance/virtual-clock/drift-token?alt=json&last_etag=XXXXXXXXXXXXXXXX&recursive=False&timeout_sec=60&wait_for_change=True
GET /computeMetadata/v1/instance/network-interfaces/?alt=json&last_etag=XXXXXXXXXXXXXXXX&recursive=True&timeout_sec=60&wait_for_change=True
GET /computeMetadata/v1/?alt=json&last_etag=XXXXXXXXXXXXXXXX&recursive=True&timeout_sec=77&wait_for_change=True
In call cases, the wireshark says the source is the IP of my instance, and the destination is the 169.254.169.254 which is the Google metadata server.
I don't have any code we have written that is accessing the server. The first one makes me think that this is some Google specific software that is accessing the meta data? But I haven't been able to prove that. What is worrisome is that the response for the third one contains ssh keys. Also, every minute seem excessive.
I see another post talking about scripts in /usr/share/google, but I don't have that directory. I do see that google-fluent is installed. I also see a installed snap for google-cloud-sdk. Could one of those be it? I don't recall installing them, AFAIK, I am not using it, so if that is it, what is the harm in uninstalling it?
You do not have a problem to worry about. The metadata server is private to your instance. The Google VM guest environment software and Stackdriver (fluentd) are making requests to the metadata server to get credentials, detect changes (new SSH keys), set the clock, etc.
The IP address 169.254.169.254 is an IPv4 Link Local Address. Only your VM has a route to that network.
Compute Engine Guest Environment
Do not attempt to uninstall the Guest Environment. You can remove Stackdriver, but I do not recommend that. Stackdriver provides logging and monitoring features that are very useful.
Ok, I have a quick question to ask all the veteran Wamp users on this board.
At work, we are currently working on a web application. We are trying to use Wamp to design everything, but we have a problem. All the computers right now have wamp installed to the default location (C:/wamp).
Our problem is, we all want to have access to the same MySQL database so we can edit it at the same time. Right now, only one person can edit it at a time to prevent losing the work of someone else.
When done, we just dump the mySQL folder onto a network drive so whoever wants to edit it next can take it and use it.
This isn't very time efficient, so we're wondering if its possible to install Wamp directly to a network drive in some way. We tried doing it just now but we can't get Wamp to start services.
So any type of advice will be helpful
i think these two thing would help you :
1: install wamp in only one system then in apache configuration file listen to his lan ip in order to others can access it in this way you have just one database server
2: as you've installed wamp to all systems choose one system's database as main and in mysql configuration define a new server wich server's ip is that system's lan ip
then users instead of using localhost for connecting to mysql will use that ip
I am a GIS tech trying to get migrate to Geoserver, unfortunately I am not very savvy on web hosting.
I installed the Windows version 2.3.1.
I was able to build by map and access it through localhost:8080\geoserver\www\
I take that to mean that the jetty server it working.
I understand that I should be able to replace my local IP address where "localhost" is and be able to access it from another computer via Http.
I can't figure out the next step. I have found great tutorials on every part of geoserver process except this. And the user guide does not get into this either.
My set up: Cable Modem > Router > PC with Geoserver
What I have tried: Setting up a virtual server on my router. I have tried changing by router to inbound port 8080 to private port 8080
I also tried 80 to 8080
and 80 to 80
I also tried windows firewall exception. and turning off windows firewall.
I read about using appache tomcat but I have not installed it because it seems that jetty is working (at least as a local host) and I don't want to put another program on 8080. And to my understanding it can work stand alone but I really honestly don't know no.
I am must be missing some vital piece of information on how to do this. I am hoping it is just so basic that it wasn't worth mentioning on tutorials.
Thanks
Karin
This would be a GeoServer configuration question, but since its deployed in jetty the solution is likely in the underlying jetty configuration. That being said it is a guess on my part (the jetty side of things) how they set up this distribution, but if you find a jetty.xml file, perhaps under an /etc directory then you should be able to edit that file and set a proper host in the configuration.
Seriously though, this has to be a pretty common GeoServer question so I bet they have some documentation floating around for setting this properly in their software distribution.
http://docs.geoserver.org/latest/en/user/webadmin/basics.html
That seems to indicate it might be dependent on your container configuration, in which case look through how ever they are configuring jetty for a Host setting that is likely hardcoded to 'localhost'
I'm pretty perplexed... I've got 5 different test computers, all relatively blank Windows XP machines running similar hardware specs. I run a silent install of the FireBird (Classic) database and my application. Some computers require "localhost:" (or 127.0.0.1) before the database location to make a connection, and some simply don't work at all! This is running the exact same software across the board. Does anybody have any suggestions as to what needs to happen to make the connection string universal, or what I could be doing wrong??
It's firebird version 2.1.1.17910 Classic
By the way, i tried connecting to the same database using FlameRobin (a small db management tool) and it worked just fine on the computers that don't connect.
Any more information necessary just let me know! Thanks a lot in advance
For anybody's future reference, the answer is in the services. Apparently it's not being registered as a service for some reason, and on the working computers, was at some point registered, probably through some sort of far earlier tests of Interbase is my best guess.
C:\Windows\System32\drivers\etc and opening up the file 'services' and adding the following line allows the server to run properly.
gds_db 3050/tcp
I'm not sure whether you are aware of that, but a connection string without "localhost:" or "127.0.0.1:" in front of the database name or alias will use the local protocol, which can't be used when connecting to Firebird Classic Server (see this link for more information). If a host name or IP address is given, then TCP port 3050 will be used for the connection.
If you have registered a server in FlameRobin, and did not leave the hostname field in the registration dialog blank, then the host name will be part of the connection string. That would explain why you can connect using FlameRobin.
As for the differences between the machines: You should first go to the Firebird Server Manager applet and make sure that the server is indeed running on all machines, and that the version is the same.
Does it have something to do with the hosts file on some of the computers? Or is that what you're referring to with your
Some computers require "localhost:" (or 127.0.0.1) before the database location...
comment?