Journey to the Virtual World

Monthly Archives: March 2015

You have a lot of ESXi hosts, and you know that traffic such as vMotion and VSAN can consume a lot of bandwidth. With vRealize Operations, you can see whether any of the vmnics (the physical NICs) across all ESXi hosts are hitting its limit. Since the network now sports full duplex transmission, we need to prove that neither Transmit (TX) nor Receive (RX) hit the limit. The limit can be 1 GE or 10 GE.

An ESXi typically has 2x 10 GE, or many 1 GE. In my example below, each ESXi has 4 vmnics. That means I need to check 4 x 2 = 8 counters, and make sure none of them hit a limit.

I will use vRealize Operations to implement the above idea. You can use either 5.x or 6.x for this. The example below uses 6.0.1

First step is to create a new super metric. Since I need to apply the formula to the ESXi in question, I need to use the Thisoption. Click on the little blue icon, above the formula bar, then double click on the formula you want. Follow the steps in the screenshot below, as it’s different to a super metric that do not use the This option.

Click the This icon. In the screenshot, I’ve clicked it.

Choose the Object Type: ESXi Host.

Choose any of your ESXi host. It does not matter which one, as the name will be replaced with “This Resource“.

Choose the counter you want to add to super metric. Double click on it.

I performed the above steps repeatedly. 10x to be exact. Yes, I added vmnic4 as I needed to verify whether the formula will result in an error since my ESXi does not have vmnic4. Why do I do this? In an environment with hundreds of ESXi globally, you may have variances. So you want to create 1 super metric, and apply to all.

I then did the usual preview, to verify that it works. Notice the actual numbers and pattern of the chart.

I know you don’t want to double click so many times, so here it is for you to copy-paste:

One habit that I recommend when it comes to creating super metric, is always verify the formula. In the screenshot below, I manually plotted each vmnic TX and RX. I have 8 lines. Notice the Max of these 8 lines, matches the super metric I created above. With this, I have the proof that it works as expected.

As usual, do not forget to associate it, and also enable it. You should know the drills by now 🙂 If you are not sure on the steps, search my blog on the steps.

The above is great for 1 ESXi host. You can enable alert, and since you have visibility at the ESXi level, you can know for sure which ESXi was affected.

You may say that with DRS and HA, you should also apply it at the cluster level. Ok, we can do that too. We just need to create another super metric. Since I already have the data for each host, all I need to do is applying Max to the super metric.

As usual, I did a preview on the above screen, and then verify it manually on the following screen. Notice the patterns and numbers match!

The above works for a cluster. What if you need to apply at the higher level? You need to adjust the depth= parameter. In the example below, I use the World object. Notice I set the depth=4 as the hierarchy from World to ESXi host is:

Cluster

vCenter Data Center

vCenter

World

There you go. You can now have the proof whether any of your vmnic has hit the limit on either TX or RX. And you can see it at the cluster level and ESXi level 🙂

Quoting from the official page at VMware.com, “The CTO Ambassador program is run by the VMware Office of the CTO. The CTO Ambassadors are members of a small group of our most experienced and talented customer facing, individual contributor technologists. They are pre-sales systems engineers (SEs), technical account managers (TAMs), professional services consultants, architects and global support services engineers. The ambassadors help to ensure a tight collaboration between R&D and our customers so that we can address current customer issues and future needs as effectively as possible.”

With that, here are your Ambassadors for the Asia Pacific region. We form a small community and work closely together. There are only 16 of us and we work closely with R&D. Reach out to them via LinkedIn, Twitter, or their personal blogs. If you need their email, you can drop me an email at e1 at vmware.com.

A couple of us volunteer to take product leadership role in APJ. What does it mean?

We serve as the contact person for APJ for the BU (read: product team in HQ)

We work closely with APJ Product Team, if any. We complement them as a virtual team in APJ region.

We work with the global PM on product input and enablement.

We manage an APJ specific Socialcast group, providing a common platform for Product Team and Field to connect on APJ specific matters.

The following Ambassadors have volunteered for these products:

VSAN:

Greg

Cloud Native Applications:

Roman

vRealize Automation

Sriram, Nathan, Taku

vRealize Orchestrator

Nathan, Taku, vRealize Orchestrator

vRealize Business

Sanjaya

vRealize Operations (including VIN, Hyperic, VCM)

Sunny Dua, Paul James

vRealize Log Insight

Iwan

vRealize Code Stream

Dan

NSX

Motonori, CK Kong

vCloud Air and vCloud Air Network

Paul James, Toru

EVO:RACK

Paul James, Travis

EVO:RAIL

Yasunari

EUC

Travis

Full Name

Location

Blog

Twitter

Travis Wood

Australia (Brisbane)

Michael Francis

Australia (Brisbane)

Daniel King

Australia (Brisbane)

Paul James

Australia (Brisbane)

@prj32

Greg Mulholland

Australia (Melbourne)

@g_mulholland

Nathan Wheat

Australia (Melbourne)

wheatcloud.blogspot.com

@wheatcloud

Roman Tarnavski

Australia (Sydney)

blog.romant.net

@romant

Chengkai “CK” Kong

China (Shanghai)

@ckkong_sh

Sanjaya Kanungo

India (Bangalore)

vmpower.blogspot.in

Sriram Rajendran

India (Bangalore)

Sunny Dua

Singapore

vXpresss.blogspot.com

@Sunny_Dua

Taku Suzuki

Japan (Tokyo)

Toru Kaneko

Japan (Tokyo)

vmware.10rukaneko.net

@10rukaneko

Yasunari Saito

Japan (Tokyo)

Motonori Shindo

Japan (Tokyo)

blog.shin.do

@motonori_shindo

Iwan 'e1' Rahabok

Singapore

virtual-red-dot.info

@e1_ang

Prasenjit Sarkar

Singapore

stretch-cloud.info

@stretchcloud

You can easily find them on Twitter on this list. That lists contains our CTOs and the Ambassadors.

The steps to create a super metric have changed in version 6. I could not find a write up on this, even on my favourite sites such as Sunny Dua and Lior Kamrat blogs, so I’m writing one as my customer asked for it.

If you are not sure what super metrics to create, here are some of my customers’ favourite.

Here is a short video.

If you need it in writing (e.g. for your documentation), here we go:

To begin, click on the Content icon, then choose Super Metrics from the side list. You get something like this below. I have a few super metrics created already in the example screenshot below.

Click on the green Plus iconto create a new one. A dialog box will pop up. It’s pretty easy once you get used to it.

See that big red no 1. Give it a name. I use a naming convention, as you can see the previous screenshot. The naming convention I use is:

Function – Object – Element Type – Metric – in a Container.

Function can be Maximum, Minimum, Average, etc.

Object can be VM, ESXi, Cluster, etc

Element type is one of these: CPU, RAM, Disk, Network

Metric is the metric of the element. For example, a CPU can have Usage, Demand, Contention, etc.

“In a Container” means the container I’m applying the super metric at. I normally apply at the Cluster level.

See that big red no 2. That’s the place you choose the Object. You can choose any object from any adapter. Yes, your super metric is not limited just to vSphere objects. The list of objects are shown below the rectangle, hence you see a heading Object Types. Remember, an adapter brings many objects. The vSphere adapter gives you object like VM, ESXi, and Cluster.

Once you choose an object, its metrics will appear in the big red no 3. Now it is blank as I have not chosen any adapter yet. vRealize Operations call it Attribute. Don’t get confused with the term. Metric = counters = attributes.

See that big red no 4.That’s where your super metric will appear.

In the screenshot below, I’ve clicked on the Adapter Type drop down box. You can see from here the universal nature of vRealize Operations as data analytics tool. My friend Ronald Buder says it best, “It’s like a big data”.

I chose the vSphere Adapter from the list above. The list of objects are then filtered to just what the vSphere adapters bring. From the list, I then clicked on Virtual Machine. vRealize Operations automaticallylists all the VM metrics in the Attributes Types area.

From here, we are ready to choose the metric. Since there are many of them, I normally just search. So I typed “contention” and you can see the list is narrowed down.

To bring the metric into the super metric formula, simply double click on it. It will appear on the formula area. Naturally, you need to specify what transformation you want. You can choose from the list of Functions, as marked with the big red no 1. Most functions are pretty short, so I just type it. In this example, I typed the Max() manually.

Here is a tricky part. You are applying your super metric to an object. That object is normally the parent or children objects. In my case, I’m applying the super metric to a Cluster. A cluster is the parent of ESXi Host, which in turn is the parent of VM. So it’s 2 level higher. So I have to manually modify the “depth=1” to “depth=2”. This tells vRealize Operations to look up 2 level higher.

See the big red no 2. There are 3 icons there.

The 1st one is called This. This means you’re applying the formula to the object itself.

The 2nd one helps you visualize your formula. Click on it to see it in more readable format. In my case, it shows the correct formula. vRealize Operations automatically color code it. Nice!

The 3rd one is my favourite. This button is called the Visualize button. It lets me go back in time, and also verify if I choose the right metrics, because the result will “make sense” when I choose the right one.