So I finally decided to to decommission my old VCops 1.0 install and run fully on VCops 5. I've had VCops 5 monitoring our environment for a couple of months now and during my initial install had set it up to use DHCP just due to the fact that I didn't (and still really don't) know that much about IP Pools and how they interact with the VMs. So I went about the task of switching both VMs that come with VCops to a static IP. Honestly, I didn't think this was going to take much, and really it isn't…so long as you read the required documentation 🙂 (which of course, I didn't!) So, the following is basically derived from a couple of great blog posts; Duncan Epping's post about IP Pools and William Lam's post regarding 'vcops-admin'.
So as I said, my first problem was skipping the documentation and thought I would be 'smart' and just go and change the IP's from within both of the consoles. Not knowing much about IP pools and how they function this was probably a bad decision. I changed the IPs of both the UI and and the Analytics VM, restarted the networking services and quickly realized that I had lost connectivity between the two. A first I thought it was simply an advanced setting somewhere within the UI VM that specified the IP of the Analytics VM…well, wrong there. I couldn't find anything like that anywhere within the UI VM. So, I decided that a reboot was in order to have both VMs come up clean however on the power on operations I experienced the following error dealing with IP Pools.
I followed Duncan's post on getting my IP Pools setup properly making just a few adjustments. I wanted to only use the two static addresses (200 and 201) that I assigned to the VMs so I imputed my range as seen below. Also, be sure to move the Associations tab and actually associate this IP pool with your desired Virtual Machine Network or you will end up getting the same exact error as above.
 |
 |
So after making all of these changes and configurations I was able to get my VAPP to power on once again, however after coming up I seen the following in the UI VMs console. "SSH: connect to host secondvm-external port 22: No route to host". It was still trying to connect to my Analytics VM on its' old IP address. Knowing that I could not find a setting anywhere within the GUI (which I couldn't connect to anyways) I turned once again to Google and found a great article on William Lams blog about changing the IP's which outlined a command line tool called 'vcops-admin' which controls just that setting I was looking for. Only problem being is that I couldn't seem to get into the console (either through direct, failsafe or SSH) of my UI VM as it continued to display the no route to host.
So, the quick fix for me was to set the Analytics VM back to its original DHCP address, which in turn allowed the UI VM to once again connect to the Analytics engine. Then it was a simple as following the steps outline on William's blog post…
Once the UI VM had booted I went back to the Analytics VM and changed the IP back to the static address that I wanted using the 'Configure Networking' option on the console. Then, it was back to the UI VM to run the command to make it aware of the new Analytics IP. As per Williams post, if you experience any error such as 'This program must be executed as an admin user' then make sure you sudo to the admin account using 'su admin'.
First off, stop VCops if it is running with the following command
vcops-admin stop
Secondly, make the UI VM aware of the new Analytics IP using
vcops-admin repair –ipaddress [new.ip.of.analytics]
This will in turn do the updates from within the UI VM that need to be done and start the VCops services again. After this you will need to log in to your VCops administration page and click 'Update' on the registration page in order to update the registration with vCenter.
So, whether you are changing the IP of the analytics VM, the UI VM, or both of them, you will need to ssh into the UI VM and run that vcops-admin repair command in order to let the two VMs establish their trust. Basically, VCops established a secure tunnel or trust between its VMs inside the vApp and by simply changing these IPs breaks that trust.
