virtuallyGhetto

vIN

Extracting VIN (vSphere Infrastructure Navigator) information using PowerCLI & vROps REST API

by 1 Comment

A request that I continue to receive from customers on a fairly regular basis is a way to extract the virtual machine application services and dependencies that is provided by vSphere Infrastructure Navigator (VIN) solution. Below is an example of what a VIN discovery might look like and in this case, it is actually mapping out the application and dependencies of itself.


Today, there is not a public API for VIN and although I have published several methods here, here and here on how to extract the information from VIN, the experience is still not very user friendly or easy to do.

Last week, while talking to a fellow colleague who works in our VMware Validated Design team, I found out that VIN actually has a vRealize Operations Manager (vROps) Management Pack and could potentially be useful in helping us retrieve the information generated by VIN.


Not having spent much time with vROps Management Packs, I understood at a high level they provided custom dashboards for vROps, but I was not sure if the data provided by the management packs could also be retrieved programmatically? It has also been some time since I have looked at the vROps REST API and specifically the "public" REST API which allows customers to retrieve the metrics collected from within vROps.

[Read more...] about Extracting VIN (vSphere Infrastructure Navigator) information using PowerCLI & vROps REST API

Configuring vSphere Infrastructure Navigator (VIN) To Manage An Alternate vCenter Server

by 2 Comments

When deploying vSphere Infrastructure Navigator (VIN), it is automatically associated with the vCenter Server from which it was deployed from and this behavior is by design. This means if you have two vCenter Servers, you will need to deploy two separate VIN instances, one for each vCenter Server as shown in the diagram below.

For scenarios where you have a separate management and compute cluster, each with their own vCenter Server, it can pose a problem if you want to run all your "infrastructure" virtual machines in the management cluster and not in the compute cluster. This very topic was recently brought up in an internal discussion and after explaining how VIN works, I safely assumed this behavior could not be modified. It turns out the discussion peaked the interest of one of the VIN developers and a suggestion was made on how one could potentially change this behavior. This un-tested (NotSupported) "workaround" would allow a user to deploy a single VIN instance under the management cluster and allow it to associate with another vCenter Server and its workloads. Below is a diagram on what this would look like.

Disclaimer: This is not officially supported by VMware, use at your own risk.

There was also one major issue with the workaround which was the changes would not be persisted after a reboot of the VIN instance, which meant you had to repeat the series of steps each time you needed to reboot VIN. After doing a bit of research and testing, I came up with a solution in which the changes will automatically be applied to ensure they are persisted upon each reboot. Basically we are going to do is deploy a VIN instance on each vCenter Server and initially and only configure the VIN instance in the compute vCenter Server which you wish to monitor. Once that is configured, we will then copy a few configuration properties and transfer that to over to our management vCenter Server.

Step 1 - Deploy and configure a VIN instance as you normally would to the vCenter Server in which you wish to manage. From my testing, you will also need to ensure you enable discovery using the vSphere Web Client before proceeding to the next step.

Step 2 - Login to the VIN instance via SSH and we will need to collect a few pieces of information from /opt/vmware/etc/vami/ovfEnv.xml which contains the vService Extension information for the VIN instance. You will need to record the following pieces of information from the file:

  • evs:URL
  • evs:Token
  • evs:X509Thumbprint
  • evs:IP
  • evs:Address


Step 3 - Download the updateVINvCenterServer.sh script and update it with the information you have collected in step 2. Once this is done, you can now power off the VIN instance you just deployed (we will delete this instance later).

Step 4 - Deploy another VIN instance into the management vCenter Server. Once the VIN instance has network connectivity, go ahead and scp the modified script to it. Login to the VIN instance via SSH and execute the script by running the following command: ./updateVINvCenterServer.sh This will take the information that was collected and update its ovfEnv.xml. Lastly, you will need to restart the VIN engine for the changes to go into effect by running the following command: /etc/init.d/vadm-engine restart

Step 5 - Login to your compute vCenter Server via the vSphere Web Client and re-enable discovery under the vSphere Infrastructure Navigator tab. You are now actually talking to the VIN instance running in your management vCenter Server!

Step 6 - Shortly after the discovery process has started, you should now be able to see VIN information for the virtual machines residing under your compute vCenter Server without having to actually run VIN under that same vCenter Server. At this point, you can delete the VIN instance located in your compute vCenter Server.

Step 7 - This very last step is needed to ensure the configurations are persisted upon a reboot as the ovfEnv.xml is dynamically regenerated upon each reboot. To do so, we just need to create a simple boot script that executes the script as well as restarts the VIN engine. We normally would add the commands under /etc/rc.local but since VIN is SLES based, that file does not exists. However, you can create /etc/init.d/after.local (which will execute commands after the initial init scripts) and add the following two commands:

/root/updateVINvCenterServer.sh
/etc/init.d/vadm-engine restart

Using this solution, you can now run multiple VIN instances and have them manage separate vCenter Servers all while running under a single vCenter Server compute cluster. Below is a diagram of what that would look like as well as a screenshot of the environment I have setup in my lab. Though this solution is not officially supported, I have seen a few folks ask for this functionality within VIN. Do you think this is something VIN should support and allow it to be decoupled from the vCenter Server  it is deployed from? If so, please leave a comment or if you have additional feedback on this which will help engineering decide whether this is something they should look into.

 

All the credit goes to to Boris Serebro, the VIN developer who suggested this neat workaround. Thanks for sharing!

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.

How to Update vSphere Infrastructure Navigator (VIN) After Changing vCenter Server IP Address

by 2 Comments

If vSphere Infrastructure Navigator (VIN) is deployed in your environment and you change the IP Address of the vCenter Server, VIN will no longer function even after a reboot. The reason for this is that when VIN first registers with the vCenter Server, information is generated and stored within VIN such as the IP Address as well as security thumbprint. Since the IP Address of the vCenter Server has changed, we simply just need to re-register VIN with the vCenter Extension vService.

In my lab I have VIN deployed and connected to a vCenter Server (note the IP Address 172.30.0.229):

I then update the vCenter Server's IP Address to 172.30.0.230 which will break communication with VIN. To resolve this, start off by shutting down the VIN appliance. Once it is shutdown, edit the settings and click on "Manage->vServices" and at the bottom click on the Edit button. Next change the Provider drop down to "No Provider" and then click OK.

Now we will reset the Provider back to the vCenter Extension vService by going through the same workflow again but now selecting "vCenter Extension vService" as the provider.

You will also notice at the bottom there is a validation message and you should also see the new IP Address of your vCenter Server. Once you are done, click OK to save the settings and then power back on your VIN appliance. Once VIN is up, connect to the vSphere Web Client and you should be able to see your VIN data again!

VIN 2.0 Supports New Export to CSV & Maps Feature

by 2 Comments

VMware just released the new vCenter Operations Management Suite 5.6 this evening which includes all new updates to the following products:

There are too many cool new features in each of these products to list them all out (I recommend you check out the release notes for each product). Though, two new features that I would like to point out is from latest vSphere Infrastructure Navigator 2.0 release (also known as VIN) which allows you to export the VIN data to CSV output as well as exporting the maps to PNG.

You have the option of exporting all virtual machines from a given vCenter Server or filter out a subset of the virtual machines by navigating to a specific object using the object navigator in the vSphere Web Client. In the screenshot below, I would like to export all virtual machines that VIN is collecting for a particular vSphere Cluster, so I select the Virtual Machines in that Cluster on the left and then select the Manage tab and then click on Application Services.

The export to CSV button is located right next to the filter box and this will export the entire table view that is seen to a CSV file which you can then save onto your local desktop. The filename will automatically be saved as vin-inventory.csv and here is a screenshot of the output file:

Note: If you filter the list of virtual machines using the Filter box, the export will still capture all virtual machines under this view. If you wish to capture a specific set of VMs, you will need to use the object navigator to filter out the specific objects before exporting.

To export the application dependency maps from VIN, you will need to be in the context of an individual virtual machine and again under Manage tab and then click on Application Services. The map export button is located right next to the zoom in/out option in the upper right corner as shown in the screenshot below.

I really like map export feature as you can sit back and let VIN do all the hard work of mapping out all the applications and VM dependencies for us in a graphical manner and then just export the picture which can then be used with documentation, CMDB diagrams, auditing, etc. These are just two out of the many new features found in the latest release of VIN 2.0. I highly recommend you give VIN a try if you are not already using it in your vSphere environment!

One additional note that I would like to point out, the data being exported to CSV does not capture all the application details such as the services, ports, processes, etc. that you might see from the VIN UI. If you wish to extract all this information from VIN for your own use, you can do so by taking a look at the following articles:

Alternative Way of Extracting VIN (vSphere Infrastructure Navigator) Information

by 2 Comments

Here is an alternative method of extracting the super useful information from VIN (vSphere Infrastructure Navigator) which I stumbled across while troubleshooting an earlier VIN 1.2 deployment. This method is much simpler from a data extraction point of view and has less prerequisites compared to the first method documented here and here, but it does require a bit more data processing.

Once VIN is up running, there are a set of zip files that are created in /var/log/vadm/results which are name with the virtual machines MoRef ID. We can quickly view the contents of one of these files (without needing to extract the zip file) by using zcat, here is the command to view one of the zip files: zcat /var/logs/vadm/vm-238.zip

From the screenshots above, we can see it contains the same set of information as displayed in the VIN UI. The information is broken down into several section including high level summary of the VM, individual processes running in the virtual machine, application/services known by VIN as well as a netstat table.

Instead of operating on these files directly, you should make a separate copy of the directory for further processing. Since the file name contains the VM's MoRef ID instead of the human readable VM display name, I wrote a quick script called extractVINData.sh which creates a copy of data and rename the files to VM display name.

To use the script, you just need to download it and upload it to your VIN appliance (make sure you set the execute permission on the script). Then just run the script and it will automatically copy the directory to /root/vin-results and translate the VM MoRef ID by correlating with the /var/log/vadm/engine.log file.

Here is a screenshot of the script output:

So if you do not mind some parsing, you can easily extract the data VIN is collecting by simply SSHing to the VIN appliance and periodically copying out /var/log/vadm/results directory. From my quick test, this directory is automatically updated as new VMs are brought online and inventoried by VIN.