Monthly Archives: June 2016

Reclaiming CPU and Memory in vROPs 6.2

Hi there everyone, where I work we’re pretty lucky to have a really nice test lab. This is an environment that is for the most part isolated from production, development and certification. Its an Engineering only sandbox for proof of concept and testing; however its still a fully functioning data center and there are a number of infrastructure systems that are relied on to keep the lab running smoothly and even though we have a budget for adding virtual infrastructure capacity there comes times when we start to run hot on CPU and more so memory in our VMware environment. The cool thing is we can use the Reclaimable Capacity section in vROps to identify which resources are being consumed and which guests are the trouble makers and by configuring the vCenter Python Action Adapter we can modify objects in vCenter right from vRealize Operations Manager… how awesome is that!

I wanted to write up a nice walk through on how to configure the Python Adapter and use the Reclaimable Capacity section in vRealize Operations Manager to figure out which guests and how much capacity you can recover; however when I was doing some research on the subject I came across Jason Gaudreau’s blog where he expertly explains in detail everything I would of shared with you all. Jason and I have spoke on the phone a few times as he has helped me work out a couple things or given me direction. He’s really an expert so check out his post Right-Sizing with vRealize Operations 6.0

Advertisements

Come See Me at VMworld 2016 – Mandalay Bay Las Vegas

Hi Everyone! If you have never been to VMworld, you really should. There are a number of great sessions to attend as well as the solutions exchange and the always awesome VMworld party! I’m very honored to announce that I will be speaking at two sessions at VMworld 2016 in Las Vegas. Check out the session info below, and don’t forget to register for VMworld 2016. Shout out to my colleague and vExpert Tom Cronin who will be speaking with me. Tom will also be part of a panel session on VSAN. You can follow Tom on Twitter @Virtual_Tom. Thank you to Joe DePasquale ( @DePasqualeJoe) our VMware TAM for helping us submit our session abstracts and build our presentations. Don’t forget to follow me on Twitter too! 🙂 @anothergeek

vRealize Operations – Resource Interaction XML File

Hey everybody, so a few months ago I wanted to give our Operations team a quick and dirty dashboard to quickly view some very basic metrics to determine at a glance what’s happening to a guest. I knew I wanted an Object List, Top Alerts, Workload and a Metric Chart, the problem I was having is that the default view on the metric chart widget didn’t gave me the metrics I wanted to display. The good news is that you can create a custom XML file that you can choose in the Metric Configuration drop down menu when configuring the widget.

First off we need to make sure that to use the metric configuration dashboard and widget, configurations must be set up so the Widget Interactions are configured so that another widget provides objects to the target widget, like an Object List and the widget Self Provider is set to off. The custom XML file that we will choose from the drop down when configuring the Metric Chart widget needs to be imported into the global storage using the import command. Ill show you how to do that in the next couple steps.

Next we create our custom XML file with the metrics we want. vROPs offers so many metrics to choose from, so pick ones that make sense to you. I decided to use CPU Usage (%), Memory Usage (%), and Virtual Disk Aggregate of all Instances Total Latency. Below is the XML code I used.

After you have created your XML file, the next process is to save the XML file to your vROPs server and import it into the global storage. Depending if you are using a vApp/Linux server or Windows server the location will be different. Im running the linux appliance.
vApp or Linux – /usr/lib/vmware-vcops/tools/opscli
Windows – C:\vmware\vcenter-operations\vmware-vcops\tools\opscli

Now its time to import the file, pretty simple. run the following: (from the directory)
vApp or Linux – $VMWARE_PYTHON_BIN ./ops-cli.py file import reskndmetric YourCustomFilename.xml
Windows – ops-cli.py file import reskndmetric YourCustomFilename.xml

Lastly, when you create your dashboard and edit your Metric Chart widget, in the Metric Configuration drop down you can now select your custom XML file to display the metrics you want to see.

If you would like to use my XML file or dashboard, download it here:
dashboard.zip

vRealize Operations Manager – HA and Capacity Buffers

At my company, I work closely with our Capacity Management team. Their role is to collect data points from various teams (storage, VMware, etc.) and determine what the current state of capacity is. That is way over simplifying what they do and the value they bring to the teams they work with is very high, and the recommendation to purchase or when to delay purchase can save the company a lot of money. I use vROPs to publish weekly reports with a number of metrics that the capacity management team uses to determine what clusters need more capacity, what clusters dont and if we can shift capacity from one that has extra to one that is desperately low. Even though the reports they get from vROPs provide many metrics, we key in on average remaining vms that can fit in a cluster. A few weeks ago, I upgrade vROPs from 6.1 to 6.2 and we found out that the calculations were just a bit off from what we have normally seen and that caused me to dig deeper into what actually is happening to determine how many remaining VMs can fit in a cluster.

vROps calculates the remaining vms based on the HA and capacity buffers set by the vROPs policy and vCenter Admission Control. The reason why we see a difference from 6.1 to 6.2 is there is not a change in the way vROps deals with capacity rather there is a difference in how vROps integrates with Admission Control in 6.2 and this would account for the discrepancy. Before we dig a little deeper into the buffers, lets take a look at Admission Control

vCenter Server uses admission control to ensure that sufficient resources are available in a cluster to provide failover protection and to ensure that virtual machine resource reservations are respected. There are three types of admission control. For this explanation, we’ll just focus on vSphere HA. vSphere HA ensures that sufficient resources in the cluster are reserved for virtual machine recovery in the event of host failure. Admission Control imposes constraints on resource usage and any action that would violate these constraints is not permitted like powering on a VM, migrating a VM to a host, or increasing the CPU and memory reservation of a VM. Only one type of Admission Control can be disabled – vSphere HA.

This is why when we look in vROps at remaining capacity in a cluster we see “HA (0%)” in the buffers column.

It’s important to note that the reason why we see the “HA (0%)” is because enabled (by default) in the vROps policy is to use High Availability Configurations check box; however for this example Admission Control is disabled in vCenter and because of that the percentage remains 0.

If Admission Control is enabled, one option is to define failover capacity by a percentage, this would be represented in vROps by a number in the “HA (0%)”

If you unchecked in the vROps policy the Use High Availability Configuration option. The “HA (0%)” is removed from the buffer column in the remaining capacity section.

The other part of the buffers is the “+10%”. This is an additional capacity buffer controlled by vROps policy and by default it was set at 10%. We do have the ability to adjust that buffer if needed.

If we do that math in any cluster we can see that the usable capacity that vROps is reporting for CPU and Memory (as well as disk) is correct. For example: usable memory capacity is physical host memory times the overcommit minus buffers. This is how we can confirm that vROps is accurate. I also believe that the remaining number of VM left to fit is accurate because it uses these numbers to determine how much remaining capacity is left. I’ve asked VMware support if they can provide me the math behind determining the number of average VMs left to fit in a cluster so I can double check the calculations. I’m waiting their response. The discrepancy in the reports I wrote about in the beginning of this post, is due to VMware making general improvements to their product and the integration with the Admission Control setting in 6.2. There is nothing specific in the release notes from VMware that was specific to this; however support told me that they have had other cases in relation to these settings in 6.2. Roomer has it VMware is working towards more interoperability between the two products in Vsphere 6.5 Im assuming vROps version 6.2 is prepping for that integration.