WilliamLam.com

How To Configure vCenter Server 5.0 To Work With VIN 2.0?

by // 8 Comments

Many of you know that I am a huge fan of VIN (vSphere Infrastructure Navigator) and the value it can bring to vSphere administrators and their organizations. With the latest release of VIN 2.0, there are even more exciting features and integration with both the vSphere and vCenter Operations Manager platforms. However, one of the prerequisites for using the latest version of VIN 2.0 is that you will need to be running a vSphere Web Client 5.1 Server which can be a challenge for customers still on vSphere 5.0.

There was a question raised internally awhile back ago on whether it would be possible to have VIN 2.0 function with a vCenter Server 5.0? In the VIN 2.0 release notes, there is a statement that seems to indicate this is possible:

The user interface of the vCenter Infrastructure Navigator 2.0 virtual appliance that is deployed on vCenter Server 5.0 can only be viewed from the vSphere Web Client 5.1

A feature that may not be very well known with the release of vSphere 5.1 is that the vSphere Web Client Server also supports vCenter Server 5.0 which must be manually added through the vSphere Web Client admin application. This means that vSphere administrators not only benefit from all the new feature enhancements of the new vSphere Web Client but will would also be able to get a single view of their entire vSphere 5.x infrastructure.

Given all this information, I suspect this should work and I had an idea on how I could implement this. Since VIN 2.0 can only be used from a 5.1 version of the vSphere Web Client, we can simply deploy a VCSA 5.1 (vCenter Server Appliance) and configure it to point to our vCenter Server 5.0 environment. This will then allow us to use VIN 2.0 with our vCenter Server 5.0 environment while still maintaining our vCenter Server 5.0 environment.

Note: Though I have opted to use the VCSA as that is the simplest method IMHO, you are not required to. The only requirement is access to a vSphere 5.1 Web Client Server which you can also install on a separate Windows server.

Here is a quick diagram of what this would look like:

For some background here is what the environment looks like:

  • VCSA 5.0 managing ESXi 5.0 hosts with running VMs
  • VCSA 5.1 (configured, but no inventory)
  • VIN 2.0 deployed onto the ESXi 5.0 hosts being managed by the vCenter Server 5.0

Here are the steps to get this working:

Step 1 - Deploy the VCSA 5.1 and configure the system as you would normally. We will only be using the vSphere Web Client from this VCSA.

Step 2 - Register your vCenter Server 5.0 environment using the admin app in the vSphere Web Client. If you are using the VCSA 5.1, you will need to follow the instructions here.

Step 3 - Deploy VIN 2.0 into the vCenter Server 5.0 environment if you have not already.

Step 4 - Open a browser and connect to the VCSA's 5.1 vSphere Web Client. The URL should be https://[VC-IP]:9443/vsphere-client and provide the vCloud Suite License key which is required to license VIN 2.0

Step 5 - Enable discovery for the vCenter Server 5.0 under the "Infrastructure Navigator" tab on the left hand side of the vSphere Web Client.

Step 6 - Once the initial discovery has completed, you should now be able to see VIN information displayed for your virtual machines.

So there you have it! VIN 2.0 functioning with a vCenter Server 5.0 environment with a bit of help from the 5.1 version of the VCSA. You will still be able to connect to the vCenter Server 5.0 environment using either the vSphere C# Client and even the 5.0 vSphere Web Client. Though with so many new features in the new vSphere Web Client, this a great way to start getting comfortable with the new interface and enjoy all the benefits from VIN.

Automating SSL Certificate Regeneration in VCSA 5.1 & 5.5 (vCenter Server Appliance)

by // 4 Comments

The VCSA (vCenter Server Appliance) provides a very simple way of regenerating the self-signed SSL Certificate by using the VAMI web management interface. This is extremely useful if you change the IP Address or hostname of your VCSA and want a proper SSL certificate with the correct common name, especially important if you are plan on using something like vCenter Orchestrator which validates this. To regenerate the SSL Certificate, you just need to login to the VAMI web interface by pointing your browser to the following address: https://[VC-IP]:5480 and under the Admin tab there is a option to "Toggle certificate setting".

After enabling this option, you will need to reboot your VCSA for the new SSL certificate to be generated. Once the VCSA is booted up, you will need to go back into the VAMI interface and disable this setting, else another SSL certificate will be generated upon the next reboot.

I was recently asked if it was possible to automate the SSL regeneration via the command-line without using the GUI which would be very useful for automated VCSA deployments. In looking into this, it turns out the process is quite simple and the present of a file within the VCSA will determine whether a certificate regeneration is required.

To enable certificate regeneration, run the following command which will "touch" (create) allow_regeneration file under /etc/vmware-vpx/ssl directory:

touch /etc/vmware-vpx/ssl/allow_regeneration

To disable certificate regeneration, you just need to remove the file after the VCSA has rebooted. Behind the scenes, this is what is happening when you are toggling the option in the VAMI interface and now you can automate this from the CLI without using the GUI!

UPDATE (09/04/13)

For the new VCSA 5.5, there is a new option that you can specify which will re-generate the SSL certificate and then delete the file without requiring manual intervention after reboot. You would still need to create the /etc/vmware-vpx/ssl/allow_regeneration file but if the contents of the file contains "only-once", it will delete the file automatically which is nice from an Automation perspective.

To re-generate the SSL certificate and automatically have it clean itself up, run the following command:

echo only-once > /etc/vmware-vpx/ssl/allow_regeneration

Dude, Where's My vCenter Server 5.1 Components Installed At?

by // 5 Comments

You would be surprised at the number of times I have heard this question get asked and this is not regarding the installation path but the specific server a given vCenter Server 5.1 component is installed on. I am just wondering if people are somehow miss-placing their infrastructure? I would hope that most organizations have some type of CMDB (Configuration Management Database) even if it is just a spreadsheet or at a minimum a memorable hostname. In any case, this question is only relevant for those of you who decided to separate out the vCenter SSO (Single Sign-On) Server, vSphere Web Client, Inventory Service and the vCenter Server and are now wondering where a given component is installed at.
To begin, you will need to know at a minimum where your vCenter Server is installed at. If you do not know that, then you should take the walk of shame and install this utility (be-careful with port scanning tools, as it may not be allowed by your Security Operations team). Go to the advanced settings of your vCenter Server and look up one of the following settings:
  • config.vpxd.sso.sts.uri
  • config.vpxd.sso.groupcheck.uri
  • config.vpxd.sso.admin.uri

All three of these settings should contain the same hostname or IP Address which is the location of where your SSO Server is installed. You can also find this information by looking at the vCenter Server configuration file located in the following location:

Windows vCenter Server: C:\ProgramData\VMware\VMware VirtualCenter\vpxd.cfg
vCenter Server Appliance: /etc/vmware-vpx/vpxd.cfg

Next, you will need to login directly to your vCenter Server (RDP or SSH) depending on the version you are using. Using the hostname or IP Address of our vCenter SSO Server, we will now connect to the Lookup Service which is installed alongside the vCenter SSO Server. This service will provide us with the location of all services registered to vCenter SSO and we will be able to identify the location of the remainder vCenter Server components.

For Windows vCenter Server, make sure you have the JAVA_HOME environmental variable set to C:\Program Files\VMware\Infrastructure\jre and open up a command prompt and run the following (subsitute in the hostname or IP Address of your vCenter SSO Server):

vSphere 5.5

"C:\Program Files\VMware\Infrastructure\VMware\CIS\vmware-sso\ssolscli.cmd" listServices https://winvc.primp-industries.com:7444/lookupservice/sdk

vSphere 5.1

"C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli\ssolscli.cmd" listServices https://winvc.primp-industries.com:7444/lookupservice/sdk

We can take a look at the serviceName which describes the specific vCenter Server component such as the vSphere Web Client or Log Browser and endpoints property will tell you which server it is installed on.

For vCenter Server Appliance, there is a similar command by running the following:

/usr/lib/vmware-sso/bin/vi_regtool listServices https://172.30.0.186:7444/lookupservice/sdk

The only vCenter Server component that we have not found is the Inventory Service. To find the server where this component is installed, we just need to look at the vCenter Server Extensions and and we can simply open up a web browser and connect to the following URL (substitute in your vCenter Server address):

https://vcsa.primp-industries.com/mob/?moid=ExtensionManager&doPath=extensionList[%22com.vmware.vim.inventoryservice%22].healthInfo

Hopefully at this point you are able to figure out where all your vCenter Server 5.1 components are installed at and you are also documenting all this information in your CMDB or spreadsheet 🙂