vcops

Automate forwarding of vRealize Operations Manager logs to Syslog Server

01/06/2015 by William Lam 3 Comments

Forwarding logs to a syslog server from vRealize Operations Manager has been greatly simplified with the latest 6.0 release. Instead of having to manually tweak syslog-ng.conf with past releases, there is now a new UI option under Administration->Support->Logs which allows you to easily configure syslog configurations. There are currently 4 loggers (Analytics, Collector, Web & SuiteAPI) that can be configured to be forwarded to a syslog server.

To configure using the vROps UI, you select the root logger folder and then click on the gears icon at the top. From here, you can configure the syslog server as well as the syslog port.

Though this is a nice UI enhancement, it would have been really nice to have been able to configure this using an API. In doing some digging, I found that you could still automate the syslog configurations by simply adding a couple of lines into the respective log4j.properties files:

vROps Logger	Configuration File
Analytics	/usr/lib/vmware-vcops/user/conf/analytics/log4j.properties
Collector	/usr/lib/vmware-vcops/user/conf/collector/log4j.properties
Web	/usr/lib/vmware-vcops/user/conf/web/log4j.properties
SuiteAPI	/usr/lib/vmware-vcops/tomcat-enterprise/webapps/suite-api/WEB-INF/log4j.properties

Here is a simple shell script called configurevROpsSyslog.sh that you can run against your vROps instance to forward your logs. There are two variables SYSLOG_SERVER and SYSLOG_SERVER_PORT that will need to be updated before running the script. Here is an example of running the script that can come in handy to forwarding your logs to your favorite syslog server such as vRealize Operations Insight.

UPDATE (01/17/15) - Thanks to Steve Flanders for letting me know there is one additional location for configuring syslog which is the Audit logs located in under Administration->Audit. It looks like the configuration also goes into the Collector log4j.properties and I have updated my script to ensure this is also configured as part of the script.

Automating Deployment & Configuration of vRealize Operations Manager 6.0 Part 2

12/12/2014 by William Lam 3 Comments

Continuing from Part 1 of this three part series, you should now have a fully deployed vRealize Operations Manager connected on the network. You should see the following "Get Started" page when connecting to vROps via a web browser.

In this article, I will demonstrate how you can perform the initial configuration of your new vROps instance which includes configuring a password for the "admin" account that will be used to access the UI interface afterwards. You will also have the opportunity to configure basic things like NTP settings as well as the role of your vROps instance. If this is your first deployment of vROps 6.0, you will need to create a new Cluster where other "Slices" or vROps Instances can join and contribute different functionality such as Admin, UI, Data, Data Collector and Replica roles. In this example, we will assume the installation will contain all roles within this single instance. In the future, you can easily expand and add other instances that provide specific roles and in a future post, I can show how that can be accomplished using the CLI/API if there is an interest.

To perform the initial configurations, I have created a simple shell script called configurevRops.sh which requires SSH connectivity to the vROps instance. Ensure that during your initial setup, you have either enabled SSH or have gone into the VM Console and enabled SSH access. The script will be using the following four commands found within the appliance:

/usr/lib/vmware-casa/bin/ntp_update.py
/usr/lib/vmware-vcopssuite/utilities/sliceConfiguration/bin/vcopsSetAdminPassword.py
/usr/lib/vmware-vcopssuite/utilities/sliceConfiguration/bin/vcopsConfigureRoles.py
/usr/lib/vmware-vcopssuite/utilities/sliceConfiguration/bin/vcopsClusterManager.py

There is only one mandatory variable VROPS_ADMIN_PASSWORD that needs to be edited prior to running the script which specifies the password for the "admin" account. There is also a CONFIGURE_NTP & NTP_SERVERS variables that can be edited to configure NTP. By default, I have this disabled this because the system will need to validate the NTP Servers. If you do not have valid NTP Servers or be able to reach the ones specified in the script, then you may run into an error.

Once you have saved your changes, you can simply run the script using the following command (please replace the IP Address with the IP of your vROps instance):

ssh [email protected] < configurevRops.sh

Note: If you would like to see more verbose details for each of these steps, you can remove the redirect to /dev/null for reach of the commands and can be useful in case something is not running correctly.

If everything was successfully configured, you should now be able to open a browser to your vROps instance and you should see the following screen asking you to now login:

Please login with the username "admin" and the password that you had set within the script. Once you have successfully login, you should now see the following wizard which will take you through the final steps of setting up your new vROps instance. Unfortunately, these last couple of steps could not be automated and will require some manual interaction before you are ready to start using your new vRealize Operations Manager.

If you do not wish to enable SSH by default and prefer a more programmatic approach on performing the initial configurations, stay tune for Part 3 where I will show you how to use the new vRealize Operations Manager Cluster Mgmt API also known as the CaSA API to perform this exact same configuration.

Automate Deployment & Configuration of vRealize Operations Manager 6.0 Part 1

12/10/2014 by William Lam 1 Comment

Yesterday was a huge day for VMware's Management BU which released several updates to their product offerings within their vRealize Suite 6.x including some new products like the new vRealize Code Stream mentioned during this years VMware Europe Conference. Prior to GA, I had already received several Automation questions regarding the upcoming vRealize Operations Manager 6.0 (vROps). Luckily, I had a couple of days to play around with the new release before it was made public and I must to say, I am quite impressed at how easy and intuitive it is to deploy and configure the new vRealize Operations Manager 6.0.

To make it even easier for customers to evaluate the new release, I wanted to take a look at how you can easily automate both the deployment and configuration of the new vRealize Operations Manager. I have broken the process down into three parts: deployment using ovftool which will include both a non-Windows as well as a Windows solutions for my PowerCLI buddies, initial configuration using the command-line via a shell script and finally the same identical initial configuration but using the new vRealize Operations Manager Cluster Mgmt API (also known as the CaSA API which stands for Cluster and Slice Administration).

As mentioned already, this first article will focus on deploying the new vRealize Operations Manager OVA using ovftool. Previously, the vCOps VA was deployed as a vApp that contained two Virtual Machines. The new architecture provides a more dynamic approach and a new capability has been brought into the application that allows you to easily scale out the various vROps "roles" such as the Admin, UI, Data, Data Collector and Replica. This greatly simplifies the initial deployment which is always a plus in my book!

Disclaimer: These scripts are provided for informational and educational purposes only. It should be thoroughly tested before attempting to use in a production environment.

I have created a simple shell script called: deployvROps.sh and there are several variables that need to be edited based on your environment including the path to the OVA. Please take a look at the script prior to executing.

To execute the script, you simply just run the following:

./deployvROps.sh

You will be prompted to confirm the configurations you have specified before the OVA is deployed. If everything was successfully deployed, you should see your new vROps VM power up. Next, open a browser to either the IP Address or hostname of your vROps VM and you should see the following landing page as shown in the screenshot below. At this point, you have completed the deployment of vROps 6.0. As for next steps, you can either manually proceed to configure your new vROps instance or stay tune for Part 2 where I will demonstrate how you can easily automate the initial vROps configurations.

Note: There is a hidden OVF property called guestinfo.cis.appliance.ssh.enabled that will allow SSH to be enabled upon deployment. To be able to configure this property, you must add an advanced ovftool option called --X:enableHiddenProperties which the shell script already takes care of. Unfortunately, for PowerCLI's Get-OvfConfiguration cmdlet, these custom options have not been implemented and hence you will not be able to turn on SSH when using the PowerCLI method. I have already filed an FR internally for this and hopefully see this in a future release of PowerCLI.

Here is a Windows solution to deploying the vRealize Operations Manager called Deployment.ps1 using PowerCLI's Get-OvfConfiguration cmdlet and I have contributed a new sample to Alan Renouf's PowerCLI Deployment Repository. Before running the Deployment.ps1 script, you will also need to edit the variables in the script to match your environment.

Here is a screenshot using the Deployment.ps1 script:

Now that you have your new vRealize Operations Manager deployed, you can manually go through the guided wizard for the initial configuration or stay tune for Part 2 where I will demonstrate you how you can easily automate the initial vROps configurations using the command-line.

VMware Labs releases Proactive DRS Fling from last years Fling Contest

08/27/2013 by William Lam 1 Comment

Last year, the VMware Labs team ran an Open Innovation contest where users could submit ideas for Flings that they would like to see get built. In addition to that, one lucky winner will be selected and their idea will actually be sponsored internally within VMware R&D and VMware Engineers would then implement that idea. The winner of that contest was Mike Preston on an idea called Proactive DRS:

“What I would like to see is some sort of appliance/script that can hook into both the vCenter Operations API’s as well as the vSphere APIs and merge these two technologies together. By interpreting vCenter Operations predictions for what is going to happen within your environment and then leveraging vMotion/DRS/DPM to prepare for this before it happens we could be left with a more proactive approach. (I.E. Historically VM1 will utilize 100% CPU at 4am in the morning, let’s be sure these resources are available on the host at 3:45 by migrating other VMs off, rather than waiting for DRS to kick in at 4:05 – At 6am everyday my workload normally increases to the point where DPM kicks in and turns on some hosts, let’s turn these on at based on the vCenter Operations stats rather than having to manually configure a setting to do so).”

Today at the VMware R&D Innovation booth at VMworld, the VMware Labs team has just announced that they will be releasing the Proactive DRS Fling (download coming very soon!). I think this is pretty awesome, I mean how cool is that, an idea that you came up with was implemented by a group of VMware Engineers? Congrats on the awesome idea Mike!

Here is a bit more details on how Proactive DRS works:

It is a way for DRS to react to changes in the virtual cluster, and to act on predicted changes in resource demands before hosts become stressed. For example, if you have a VM that historically uses 100% CPU at 8am every morning, ProactiveDRS makes sure that the CPU resources will be available for that VM before 8am. These actions ensure that your cluster runs smoother and reduces the amount of reactive VM rebalances that occur.

Features

Given an advance forecast/prediction of each VM’s resource demands, e.g., CPU and Memory, ProactiveDRS seeks to reorganize the placement of VMs to best balance the current resource demands while taking early actions to accommodate the future/predicted resource demands.

Sample actions include, but are not limited to, proactive vMotions (migrations) and proactively powering on a new physical host to accept VMs whose resource demands are expected to spike beyond the available resources of their current physical host.

The VMware Labs folks did not stop there, they are also running a new 2013 Fling Contest and if you are at VMworld, you can drop by the VMware R&D Innovation booth which is behind the main VMware booth to submit your ideas. Another lucky winner will be selected and their idea will also be built by VMware Engineers which includes a free ticket to VMworld 2014. I recommend you either drop by the booth if you are at VMworld or go online to submit an idea and you could be the next person with their very own Fling!

How to Change the IP Address for vCenter Operations 5 vApp

02/04/2012 by William Lam 11 Comments

There was an interesting question on twitter from Matt Cowger yesterday asking how to modify the IP Address of the Analytics VM in the new vCenter Operations 5 vApp after it has been deployed. The new VC Ops 5 is actually composed of two virtual machines: UI and Analytics VM. As part of the initial deployment, they're is an exchange of information between the two VMs to properly get setup which includes the IP Addresses of each other. Simply modifying the IP Address of either VM will result in VC Ops not functioning correctly.

I personally have not had to re-IP my home deployment of VC Ops, but I did have some experience with CapacityIQ before it was combined into the VC Ops product and there was a nifty CLI tool called ciq-admin that was not very well known. I thought I check to see if the new VC Ops had something similar and to my surprise, an updated version of the tool exists and has been renamed to vcops-admin.

After a few minutes of looking around, it was clear that one could modify the IP Address of the Analytics VM and here are three simple steps.

Disclaimer: This is for educational purposes only, this is not officially supported by VMware. Please ensure you test and backup your system before making any changes in a real production system. Data that was previously collected will still be available after the change of an IP Address.

Modifying IP Address for Analytics VM:

Step 1 - First we need to shutdown VC Ops, you can do this from the administrator page by going to https://[vcops-ip]/admin and stopping the service under the Status tab. In this example, I will be showing you how to so using the CLI on the UI VM (this is primary system you use to access VC Ops)

You will need to sudo to "admin" user to run the command "vcops-admin stop". If you accidentally logged into the analytics VM and try to run the command, you will receive an error as the CLI is only available on the UI VM.

Step 2 - Log into the remote console of the analytics VM, this is required as you will be changing the IP Address and may possible impact network traffic. You will need to edit /etc/sysconfig/network/ifcfg-eth0 using an editor such as "vi" and specify the IP Address you wish to change to. Once you are done, you will need to restart the network interface for the changes to take effect. To so so, run the following command "service network restart".

Step 3 - Go back to the UI VM (you will need to sudo over to "admin" account if you are not already) and you will now need to "repair" the connection between the UI and Analytics VM to ensure they can communicate with each other. To do so, you will run the following command "vcops-admin repair --ipaddress [new-analytics-ip]". If the UI VM is able to successfully connect to the new IP Address of the Analytics VM, it will automatically start up the VC Ops service. Once the service has been started, VC Ops is now running and operational.

Now what if you want to change the UI VM's IP Address? I thought this should be pretty straight forward right? Well, it took me a bit longer than I was expecting but the process is just four easy steps.

Modifying IP Address for UI VM:

Step 1 - Stop VC Ops service, you can do this using the admin portal or via SSH as shown in Step 1 of Analytics VM

Step 2 - Login to the remote console of the UI VM this is required as you will be changing the IP Address and may possible impact network traffic. You will need to edit /etc/sysconfig/network/ifcfg-eth0 using an editor such as "vi" and specify the IP Address you wish to change to. Once you are done, you will need to restart the network interface for the changes to take effect. To so so, run the following command "service network restart".

Step 3 - Login via SSH to UI VM using the new IP Address (you will need to sudo over to "admin" account if you are not already) and you will now need to "repair" the connection between the UI and Analytics VM to ensure they can communicate with each other. To do so, you will run the following command "vcops-admin repair --ipaddress [new-analytics-ip]". If the UI VM is able to successfully connect to the Analytics VM, it will automatically start up the VC Ops service.

Step 4 - The last step is to update the vCenter VC Ops plugin information so when you navigate to the VC Ops extension, it knows the new IP Address. This step can be done by logging into the admin portal and under "Registration" tab, you will need to click on the "update" button for each and every vCenter that is attached to the VC Ops. In this example, I will show how to do so using the "vcops-admin" CLI. You will need to run the following command:

vcops-admin register update --vc-name [vc-name] --vc-server [https://vc-server/sdk] --username [vc-username] --password [vc-password] --force

Note: This process may take a few minutes for each vCenter that you need to update, also if you have a dedicated service account for the collector, you can specify --collection-user and --collection-password agruments.

Though the process of modifying the IP Address is not available through the UI today, it is a feature that I will be requesting as this should be a trivial task for users.