Monitoring virtual environments - VM101

Monitoring virtual environments is highly important - we have built multiple products focusing on this.

Here is a diagram to help you better understand our products and how our solutions can help you based on your needs.

 

vm101-6.png

My focus in today’s blog is to explain this picture, as I lead you through this introductory course on how to manage your virtual environments.

 

To start with, let us understand why you need special software to monitor your virtual machines. Why is it not enough to monitoring your virtual machines's guest OS? Why is something more required?

 

To answer that I need to digress a bit here...

Let's not forget the premise for monitoring is to support business continuity. IT and monitoring teams need to ensure that all the business functions must run without failures that impact the business. Monitoring must make sure that there are no failures arising from machine downtime, or poor performing apps and/or operating systems. However, if monitoring is not applied in the right place, and in the right way, there's always possibilities that notifications are not raised in time, alerting potential / occurred problems. We've discussed some ideas in best practices for monitoring blog posts Monitor the job queue, ascertain system bottlenecks & Set threshold values correctly for good monitoring since not every day is Sunday earlier.

 

In the world of virtualization and resource sharing it is important to know how 1 VM affects another VM running on the same host.  This cannot be achieved just with monitoring the guest OS.

 

For virtual machines there are multiple ways and multiple aspects to monitor and some key things to keep in mind.

 

  • The first aspect to monitor is the machine itself - though it is a machine, it is all software (like thermodynamics is all hot air :) ). It is important and appropriate to monitor the machine. How do we have access to this software based machine? That's via the hypervisor/host as well as via management software like VMware vCenter / Microsoft SCOM.  It is important to note that the regular performance counters obtained from the guest OS (say via Windows perfmon) is not the same as performance counters obtained by querying the VMware ESXi host running the VM. Accurate metrics for performance are always obtained when querying the host or the element management software managing the VMs, not the guest OS.
  • The next aspect to monitor is the guest OS - Based on the point above, when is monitoring  the guest OS required? One must monitor within the virtual machine - to know the state of apps running on the VM and to obtain information like disk space left on the system. Is an agent or running agentless monitors always required on the guest? Not always.

          - If you are running crucial apps on the guest, you may choose to go with a full agent with the complete set of monitoring policies from HP OM/OMi or monitors from SiteScope for the app (agent-based or agentless - refer here)

          - With an agent it is possible to monitor and gain information about the system errors and app faults, using log monitoring too

          - If it is a dev-test environment, crash-and-burn lab, and app metrics inside the guest OS are not important, you could go with an approach to not monitor the guest OS

          - There's always approaches like using micro-instrumentation shipping with HP Virtual Performance Viewer (version 1.2 upwards) to obtain information from the guest OS and apps in a non-intrusive way

  • Availability monitoring / Uptime calculations - For node availability checking as well as uptime calculations, it is best to monitor the virtual machine from the host system or management software like VMware vCenter. System time inside a guest OS is not always correct as there can be delays in updating system time on the host process running the VM
  • Due to the way virtualization works and adds overheads to the running apps to interact with hardware, a VM is not always great with IOPS - so it is important to monitor the IO of a virtual machine's guest OS and apps - this has to be done from the storage perspective, in conjunction with the guest OS apps.
  • Reporting software must use a combination of metrics obtained from the hypervisor host as well as within, in order to provide the end-to-end perspective on VM and virtualized application health.

The good news is that this behavior is common to all virtualization whether it is Windows or Linux (x86) or on mission-critical UNIX platforms.

 

 

How can software help with these scenarios?

 

HP SiteScope is agentless monitoring for virtual and physical machines. One typically tends to use this to perform continual monitoring (say every 10 minutes or so) of machines. HP SiteScope is quick to setup and easy to get to work. HP SiteScope also provides a VMware vCenter Solution Template that provides rich metrics for monitoring of VMware hosts. 

 

HP Operations Manager is a systems monitoring tool monitoring virtual and physical systems, and it uses OM agents and SiteScope for monitoring the systems (a.k.a OM managed nodes). HP Operations Manager's Virtualization SPI (VISPI) allows one to monitor virtual systems and virtualization hosts. VISPI gives 24x7 monitoring of virtual environments including monitoring for UNIX virtualization (LPAR, HPVM, Oracle Solaris Zones).

 

HP OMi's Virtualization MP provides all of VISPI functionality for the OMi users. With Monitoring Automation, there's the added benefit of simplified deployment and use above what OMi already offers which makes it an good choice over just HP OM.

 

HP vPV is a  monitoring tool for x86-architecture based virtual and cloud environments with a visual interface to virtual performance, capacity, and health at-a-glance. You can also drill down into specific performance bottlenecks or capacity issues. With vPV 2.0, there is also service discovery and event integration to HP OM (and with that, to Ops-Bridge).

 

HP Service Health Reporter is HP's enterprise data warehouse software with pre-built cross-domain content and reports. You can use HP SHR with most of the software listed above to obtain the data, and report upon.

 

So to break it down in simple logic -vm101-7.png



(flowchart alongside - click to view in full size) 

 

  • If you have VMware, Hyper-V, Linux kernel-based virtualization or Openstack on x86 architectures, first choice for monitoring these is HP vPV. vPV offers you higher scale of monitoring (upto 6000 VMs)  and heterogeneity - see figure on top. vPV offers advanced monitoring capabilities, and capacity planning features. vPV does bring in additional overhead on vCenter - this is natural and any application doing this kind of data collection will impact the vCenter.

The next set of points are only if vPV does not work out for your x86-virtualized environments, for any reason. (I would like to know why, please comment if so).

 

  • The next choice for monitoring x86 virtualization is the HP OM VISPI with the approach to do monitoring using HP OA Virtual Appliance - this approach is best suited for teams used to monitoring via HP OM policies, and also interested in monitoring a smaller environment without need for too much drill-down or capacity calculations for virtual machines.
  • If vCenter is not accessible (it is controlled by another team), or on the other hand, if you just have a small set of ESXi/ESX hosts to monitor then you can go with the VISPI still, but use proxy-monitoring via the VMware vMA virtual appliance. NOTE: HP recommends to move towards using the HP operations agent virtual appliance as VMware vMA support may not be available for longer term.
  • If yours is an organization more driven towards using SiteScope for monitoring your systems and applications, SiteScope's  VMware performance monitor as well as the 'VMware Host' and ' VMware Storage' Solution Templates can be used.
  • If you have more than 20 systems, do not go with using multiple vMA devices to monitor these. Use the HP virtual appliance to make your deployment more simplified - 1 HP VA instead of 4 or 5 vMAs.
  • If you use resource pools for DRS in your vCenter, it is recommended to go with the HP virtual appliance,  as using VMware vMA causes duplicate resource pool CIs to get created in the central topology (RtSM) and data warehouse (SHR's PMDB) as represented on the ESXi hosts to which vMA connects for data collection.
  • If you have IBM LPAR based AIX instances, HP VMs or Solaris zones (containers) then you must use the HP OM VISPI to monitor these. For example, if you have x86-based virtual machines as well as AIX LPARs, then you could go for using a combination of tools

         - HP OM VISPI for monitoring the AIX LPAR, derive deep metrics from the OM agent running on one LPAR for each powerpc frame

         - HP vPV for monitoring the x86-based VMs

 

Hope your doubts in this area are now resolved. Feel free to pose further questions.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Ramkumar Devanathan (twitter: @rdevanathan) works in the IOM-Customer Assist Team (CAT) providing technical assistance to HP Software pre-sa...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.