vCenter Operations 5

Links to the various posts on vCenter Operations 5:

• A technical introduction to management in the virtual world
• How to create a hard or static threshold
• Concept: Demand and Supply
• 
  

vCenter Operations 5: hard threshold

By default, vCenter Operations uses dynamic thresholding for attributes. This is also what I recommend as there are many limitations with static threshold, especially in dynamic environment like vSphere 5. A hard threshold is static. A hard threshold changes _only_ when you change it.

You can set multiple static thresholds, each with a different criticality level, for the _same_ attribute.

You can also define the criticality level that a metric must violate for it to be considered a KPI breach. Hard thresholds that are not set as KPIs generate notification alerts if they are violated.

 

In the rare event you need to set a hard thresholds, the steps are below. In this example, I want to set threshold for Ready Time.

All metrics are grouped together into packages. So choose Attribute Packages from the menu, as shown below.

 

It will pop up the dialog box below.

 

I’ve filtered the list by choosing Virtual Machine.

 

After I clicked the above icon to edit it, it pops up the dialog box below.

 

From there, I chose CPU, then selected Ready%. It brings up the details.

I also clicked the Advanced Configuration to expand the section. It is hidden by default.

From the above, I’ve ticked that valuation of upper limit and lower limit are considered KPI.

 

vCenter Operations Manager multiplies the wait cycle value by the collection interval to calculate the number of minutes that a threshold must be out of bounds before generating an anomaly. So in my case, the warning Critical Level has to happen for 10 minutes (5 minutes interval x 2 wait cycle) before it gets triggered. In the same manner, the info Critical Level only gets triggered if it is sustained in 15 minutes.

 

vCenter Operations Manager multiplies the cancel cycle value by the collection interval to calculate the number of minutes the metric must be in bounds before canceling an anomaly. So in my case, it only waits for 5 minutes (1 internal) to clear it. If you want to be more certain that it is completely “gone”, you might want to wait for a few more samples (cycles).

 

Hope that helps.

 

vCenter Operations 5: Demand vs Supply for each VM

The screenshot below shows the "VM Inventory" view of vCenter Operations 5 (it is still in beta). It is showing performance data, not configuration data. To be precise, it is showing analysed data. It is showing the following info:

1.       Days Remaining. Based on the 4 components (CPU, RAM, Disk, Network), how many days before the VM hits the configured capacity.

2.       Demand. Demand ≠ Usage.

a.       Usage may mean passive usage. E.g. the RAM page is there but no write/read.

b.      So demand is a more accurate reflection.

3.       Contention.

a.       This is interesting. If you know the formula or how it derives this, would be grateful if you share.

4.       Disk I/IO demand and Disk I/O Contention.

a.       This will be useful as some Apps Owner may perceive that his application generates a lot of IO.

 

The screenshot was based on Full HD resolution. As you can see I still have to scroll to the left, as the network info is not shown. If you're managing a large farm (>1000 VM), I recommend you use 2x 24" screen (each is portrait). Now that would be really cool! J

 

 

Now, the table above does not show which element (CPU, RAM, Disk, Network) would run out. To do that, you need to drill down. The screenshow below shows that it is the Reservation that is causing the above to show 0.

 

The screenshot below shows the full details. The Legend on the right shows the actual counters used in the table. You can display them as Chart too.

 

 

Distributed virtual switch: Changing property for multiple port groups

You can change the property consistently across Port Groups. This can be handy when you have a lot of port groups or a lot of hosts. I don’t know how long it takes if you have 50 port groups and 500 hosts. If you do have the data for large scale deployment, kindly let me know at e1@vmware.com.

To make the changes, right click on the Distributed vSwitch, then choose Manage Port Groups….

 

The dialog box below appears. Pick the policy you want to change.

 

Choose which distributed port groups you want to change…

 

If you tick all the policies in the earlier screen, you will get the each policy shown. I’ve doctored the screen so they fit into 1 screen. In reality you will have to scroll down.

 

And that’s about it. Hope that helps.

 

 

 

 

vCenter Orchestrator appliance: installation

I have some problems configuring it, so I thought I document it.

Orchestrator needs 4 users with the following default passwords:

• root. Password is vmware. This is for the base Linux appliance config.
• vmware. Password is vmware. This is for the Orchestrator config.
• vcoadmin. Password is vcoadmin. This is for Orchestrator administrator, in the Orchestrator client.
• The admin used to start the plug-in. I use my domain ID irahabok as it won’t accept vcoadmin and vmware in my case. It did accept vcoadmin until I changed the default LDAP with my MS AD.

The screenshot below shows where the 3 users are used.

If you click Orchestrator Configuration link, you get the screen below. User is vmware, not vcoadmin.

The appliance does not come with the vCenter plug-in enabled. You can see it is grey. Click “Apply changes” at the bottom corner.

Also notice that the default user name “vcoadmin”. This does not work in my case, and I have to use my domain ID. This because I configured MS AD after that and that changed the default LDAP.

It is enabled now. Next step is to configure it.

The message “will perform installation at next server startup” refers to the vCO server, not vCenter server. You don’t need to restart the vCenter servers, and it works for both vCenter appliance and Windows.

You need to do this for every vCenter servers.

From the manual: The user that you select must be a valid user with administrative privileges on your vCenter Server, preferably at the top of the vCenter Server tree structure. Orchestrator uses these credentials to monitor

the vCenter Web service, typically to operate Orchestrator system workflows. All other requests inherit the credentials of the user who triggers an action.

Need to restart the service. If it does not work, restart the entire VM.

To add the vCenter, you need to add the certificate. Else you get an error. To add it, simply add the IP address (or host name) of the vCenter. In my case, it is 172.16.100.11. Then click import. A screen will be shown, click import.

Once done, you will see the result like the one below.

Since I modified the LDAP to MS AD, I need to change the user.

To login to Orchestrator, launch the Java client.

I don’t have the fat client as you can use the standalone Orchestrator client installer on a 32-bit machine only. My admin client is 64 bit Windows 7.

You will see something like this when you launch the client. You can get multiple vCenters registered. It is not shown here, but I have 2 vCenter registered.

You should also see the workflow listed under Workflows. You can expand it, and see the list of workflows. The screenshot below shows a workflow for creating a custom VM.

vApp Options in a VM

In the VM settings, there is an option to add properties to it. A good use case will be to have IP address configured to the VM when it’s provisioned for the time first from a template.

 

Below is a VM (it is a vitual ESXi VM). When you choose “Enable” in the vApp options, the vApp Options get expanded. 4 more lines are shown right away as highlighted below.

Notice the Properties is still “Not Configured” as we have not configured anything.

 

Select Advanced, and then click Properties, as shown in the picture below.

 

Clicking Properties will bring up the dialog box below. As we have not configured any property, it will be blank.

Click the New button. It brings up another dialog box. I know… it can get deep.

In the example below, I’ve keyed in the Label, Description. Click on the Type field.

Since I want to set the IP address, I need to choose the right type. Clicking Edit will bring up the dialog box below

 

Below are the options for both Static Property and Dynamic Property. Dynamic means the value must be determined. Example, it can grab the value of vCenter IP address.  

In the Static Property, notice that there are “External IP Address” and “vApp IP Address”. vApp IP Address mean the value will come from the vApp, not externally. That means you need a mechanism to pass it. I will cover this a bit later.

  

 

I’ve chosen vApp IP Address as the type. Interestingly, I must specify the Network at this stage. If you know why, let me know.  In large environment, the template might reside on a network that is different to the VM, or there are many VM networks that are sharing the same template. So hardcoding only 1 VM network looks like a limitation to me. Do correct me if this is not the case.

 

I’ve keyed in 2 properties. The result is shown below. Notice the types are different, because for the Subnet Mask, I chose “External IP Address” instead of “vApp IP Address”. In the “External IP Address”, there is no network to be chosen.

 

Remember the “vApp IP Address” I mentioned earlier? How do we pass the IP address value? How do we tell vCenter where to get it from?

To do that, you need to select Advanced, then click on “IP Allocation” button, as shown below.

This will bring up the IP Allocation dialog box, as shown by the arrow.

From there, click on OVF Environment. So we tell vCenter to get it from OVF Environment, which can be CD-ROM or VMware Tools.

 

So where do we specify it, and how to see the value?

To do that, select “OVF Settings”. In the screenshot below, I’ve chosen ISO Image as the vehicle to pass the value. So the OVF Environment takes the form a virtual CD-ROM, which the Guest OS can get the value from.

Since we want the IP address to be set one time only, and not at every reboot, there is an option to do that.

 

After we do all the above, going from screen to screen, what does it look like at the end?

The Properties part is now properly configured. So now we have a way to specify IP address, and vCenter has a way to pass it to the VM upon first boot.

 

For more info, see this blog post: http://blogs.vmware.com/vapp/2009/07/selfconfiguration-and-the-ovf-environment.html

Kindly note that the post is based on vSphere 4.0 while mine is 5.0. There is some minor difference I notice.

 

Hopefully the above helps in automating further.

Virtual Switches comparison

The screenshot below shows a Standard Switch port groups and its associated tabs. The Summary tab is shown.

From the picture below, we can tell that the actual Standard Switches (e.g. vSwitch0) is not shown. The reason is it is on a per ESXi basis. The same port group can belong to different vSwitch in different ESXi host. Hence it does not make sense to show it. So what is shown on the Networking main page is the Port Group.

 

The Distributed Switch, on the other hand, exists outside each host from management point of view. Hence it is consistent across hosts, and can be displayed on the Networking page itself.

It has additional tabs: Networks, Ports, Resource Allocation, Configuration.

Networks means the port groups + 1 uplink port group. There is only 1 uplink port group.

It has no IP Pool because this is configured at Port Group level.

Distributed Switch supports DirectPath I/O Generation 2. The little icon next to the word Supported does not show additional info than what’s already shown.

The “Migrate VM Networking” allows the migration of VM from one port group to another.

 

Let’s go through the common Tabs first.

The Virtual Machines tab is identical. So Standard or Distributed Port Group have the same columns. The columns are shown below. It includes the custom attributes. In the example below, Owner is a custom attributes.

The only difference is with Distributed Switch, you can see the list of VM either at port group level or switch level. In the Standard Switch, you can only see at the port group level.

 

The Hosts tab is also identical.

The screenshow below shows the list of columns. The AutoDeploy attributes appears only when Autodeploy is configured.

 

The Tasks & Events tab is also identical.

 

The Events sub tab seems to have a lot more info for Distributed. Because of the hierarchy, we can see events at the entire Distributed Switch itself.

 

The Alarms tab is quite different because there is basically no alarm for Standard Switch. The alarm for Standard Switch is defined at the host instead.

The screenshot below shows that the default page comes with 0 defined alarm.

 

To create a new alarm, right click and choose “New Alarm…” from the pop up menu, as shown above. It brings up the dialog box below.

This is a generic dialog box, but it has filtered what it can monitor. In this case, it can only monitor Network. So no other object is shown. Notice that the state/condition option has been greyed out too, as it cannot be monitored for Network.

 

Clicking the Triggers tab shows the screen below. From here, it it clear that no meaningful alarm can be created as it has no event that it can monitor. The only options are for Distributed Switch, but we’re are Standard Switch here. Hopefully this gets fixed in future release as it’s not applicable.

 

For Distributed Switch, it also comes with 0 default alarm, as can be seen below. I was hoping it would come with some preconfigured alarm, considering how importance this switch is.

 

Clicking the Triggers tab shows the screen below. From here, it it clear that a lot of alarms can be created. You will notice the dialog box looks funny as I’ve extended the drop down menu, so it shows all the events. The actual dialog box only shows 8 events at a time, and it has 23 events in total. So we have 23 alarms versus 0.

 

You can create the alarm at Distributed Switch level, or at individual Distributed Port Group level. If you do it at individual Port Group level, surprisingly the list is not consistent. You can 1 more alarm (dvPort group renamed), but you lose a bunch of alarms. Hopefully in future release this is made consistent.

 

The Permissions tab also look similar on the surface, but very different underneath.

The Distributed Switch has additional privilege, categorised under “dvPort group” and “vSphere Distributed Switch”.

The remaining network related privilege seems to be shared by both.

 

So the above few screenshots show how the Distributed Switch properties are shown in the UI.

The Standard Switch “property” page is shown via just 1 dialog box. Here is the property page of a Standard Switch.

 

There is a lot more to share on the delta between the 2 switches!

 

Removing a distributed switch

Simply right click on the Distributed Switch, and choose Remove from the context sensitive menu.

 

The following dialog box appears

 

If you click Yes, you will see the task in the Recent Tasks bar. If there is no VM attached to it, it will succeed and it gets completed right away.