This post reviews the Oracle Enterprise Manager Plugin for VMware from BlueMedora. This commercial (for-fee) plugin integrates into OEM 12c to provide visibility into your VMware environment for Cloud Control users. I have only had the plugin installed for two days so this will serve as more of a “first thoughts” report than as a full review of the product and all of its capabilities.
Prerequisites
The plugin, license and support are available directly from BlueMedora. They are also currently offering a fully-functional 30-day free evaluation copy. You will need to meet the following prerequisites in your environment:
- An active, functional installation of Enterprise Manager 12c (I used 12.1.0.2.0 + PSU2, but any EM12c release should work)
- A functional emcli installation. I run emcli out of the $OMS_HOME on my OMS server.
- An OEM user account with appropriate permissions to import and deploy plugins (I simply used SYSMAN)
- An Oracle Management Agent installed on some server other than your OMS server to host the plugin (per BlueMedora’s recommendation, which I followed)
- A login to your VMware environment with read-only access to vCenter, your cluster, datastores, ESX hosts, and virtual machines. If you use an account with permission to start/stop VMs that functionality is available for use in EM12c via the plugin, but I am using a read-only account and have not tested that part of the product
- At install time you will also need the hostname of your vCenter server and the SDK port if it has been changed from the default 443.
Installation and Configuration
After downloading the plugin from BlueMedora, installation is as simple as any other plugin you may already be using. Their support team will walk you through the install and configuration (over a webinar in my case), but the steps are just what you would expect: copy the plugin .opar file to a location accessible by your OMS and import it using the emcli import_plugin verb, then after the import completes, deploy the plugin to your OMS and finally deploy the plugin to a management agent.
Configuring the plugin (adding targets) is also simple. For the first step you will run an “Add Target Manually” step with the “VMware vSphere” target type to let the plugin know about your vSphere environment. Here is where you will provide your VMware login credentials, hostname and port (if non-default) in order to begin monitoring. After adding the vSphere target, access it through the All Targets view, and go to the “All Metrics” link to validate that your VMware login credentials worked and metrics are being collected. As an aside, a particularly interesting feature here that I have not seen in other plugins is that there is a metric group called “Collection Trigger” that, when clicked, triggers a collection. This is handy and I would like to see this implemented elsewhere; I find it much easier than going over to an agent and running emctl to force a metric collection.
Once that is done you will see a new auto-discovery module called “vSphere Discovery Module”, and after configuring that discovery module with the name of your vSphere target you will run auto-discovery on the management agent to which you have deployed the plugin. Auto-discovery identified our VMware cluster, ESX hosts (hypervisors), datastores and all of our virtual machines. From the auto-discovery results you then promote any targets you wish to monitor through Enterprise Manager. You may not want to promote all of your VMs (for management reasons, or to comply with your license terms) but you should promote all clusters, hypervisors and datastores, for the best overall view of your environment.
As with the other plugins I’ve used, after promoting targets you’ll need to wait a little while before metrics are collected and screens populate with data. In my case I had useful data appearing on screen within about 10 minutes after promoting the first VM.
What’s In It For Me?
For a good high-level overview of what the plugin can do, take a look at the white paper from BlueMedora, the product overview PDF and the product datasheet. I’ll only cover some of the additional items that these sources do not go into in detail.
Visuals
The plugin provides several nice visualizations. On top of the “CPU and memory usage over time” graphs you would expect to find, I particularly like the bar graphs that group your hypervisor CPU and memory load into quantiles, making it easy to see, for example, that one host has 75-100% CPU usage while the other hosts are all in the 0-25% bucket, indicating that you may want to allocate your VM load a bit more evenly. The datastore visualization showing the fill percentage on each datastore is also nice. Samples of these can be found in the product overview PDF.
Another useful visual is the integrated view of an Oracle database along with the VM on which it runs, the datastore(s) assigned to that VM, and the hypervisor on which the VM is running. You can quickly see if, for example, the hypervisor is under memory pressure even if the VM does not appear to be, along with the executions and IOPS per second and average active sessions metric for the database.
Centralized Data
I find it hard to click through the vSphere client to find information I’m looking for. I’m always in the wrong inventory view, or seeing only a subset of the data since I have a host selected rather than the entire cluster, and so on. This plugin provides an easy to use centralized view of information across the VMware environment. By going to the “Virtual Machines” view from the main vSphere target I can see a data grid showing each VM’s power status, provisioned disk, consumed CPU and memory, guest memory usage percentage, Even better, the grid includes a column indicating whether or not VMware tools are installed and running. There’s also an uptime column but I’m not sure how to parse it. I think it represents the VM’s uptime on the specific hypervisor currently running it, but I’ll be asking support to clarify that for me.
New Job Types
These will only be useful to you if you want to automate your VMware environment from within OEM, and if you grant permissions beyond read-only to your monitoring user. I do not expect to make use of this feature. But if you choose to do so, the plugin adds several new job types you can use for OEM jobs:
- vSphere Hypervisor Enter Maintenance
- vSphere Hypervisor Exit Maintenance
- vSphere VM Power Off
- vSphere VM Power On
- vSphere VM Reset
- vSphere VM Restart Guest
- vSphere VM Shutdown Guest
- vSphere VM Suspend
Metrics/Alerts
What use is an OEM plugin without metrics and alerting? Very little. This plugin provides a ton of metrics for your VMware environment. The list is too long to include here, but see this on pastebin for a quick view produced from the MGMT_METRICS table. You can also set warning and critical thresholds for many (although not all) metrics, and those alerts will go through the normal EM12c event framework to create incidents and/or notifications if configured to do so through incident rules. You can also view the same metric-over-time graphs as you can with the out-of-the-box EM metrics.
Other Items
The overview states that the plugin includes some integration with BI Publisher for reports. I do not have BI Publisher installed with my EM12c environment so I can’t speak to this feature.
Disclaimer
I am not employed by BlueMedora, VMware or Oracle and neither I nor my employer received any consideration or compensation from those vendors.
Pardy DBA 
Brian — in reference to your question about exactly what the ‘Uptime’ column is conveying in the VMware plugin – the ‘Uptime’ columns represents the total time since the Virtual Machine has been powered on in Day:Hour:Minute format. The user guide also does not convey that information and a defect has been entered into our defect tracking system to remedy that. Thanks for pointing out the issue.
Thanks for the response concerning the uptime column. I seem to be seeing something different in this column, as the two servers I’ve checked indicate an uptime different from what I see reported by the plugin. My guess is that this is a VMware issue rather than a problem with the plugin, but I’ll contact support directly to see what we can find.
Thanks for this write-up Brian – it’s great to see an independent view of this product.
Many of my customers have VMware estates to run Oracle now and, whilst I suspect the Virtualisation Admins will want manage it within their own tools, I can see the benefit of giving Oracle admins read-only visibility of the underlying platform. I haven’t looked into the licensing but it seems to me BlueMedora should charge different levels for “read-only” and “modify” configurations since this corresponds to different levels of functionality. Of course if the Oracle Admin *is* the Virtualisation Admin too then they may be even more interested 😉
Hi Simon,
Thanks for the comment. I’m glad you found the post interesting. I agree that the VMware admins won’t be eager to use another tool that’s aimed at DBAs, the self-service aspect has already helped me answer several questions without having to ask them.
If I’m not mistaken, the modify aspect is limited to starting, stopping and pausing VMs, but your idea of an additional license tier for some extra management capabilities is interesting. Something like adding RAM or vCPUs, or snapshots for VMDKs might be useful for sites that give their DBAs a bit more access than the rest!
Pingback: How to migrate EM12c R3 OMS and repository to a new host | Pardy DBA