There are many directions from which this topic can be explained. I'll use a fictional customer performance problem (hopefully this is not a regular issue) to illustrate the needs for extended virtualization monitoring. I'll try to use the customers view as a starting point and continue the way over the SAP support channels and all the interactions in between until a solution for this fictional customer call is found. Our fictional customer does not have an own IT but a hosted one. The hoster offered several low priced virtual machines which the customer is using right now to use with SAP software. Which virtualization technique is used does not matter, because the extended monitoring is needed for all available virtualization technologies.
Performance Problems
Now it is a normal Monday morning, and everything works find. But suddenly, exactly at lunch time, our fictional customer examines a serve performance problem, because the users start complaining about long GUI waiting times, print jobs taking hours ,never ending database selects and so on and so forth. The customer checks the system parameters and there are still the came amount of SAP and Memory configured as before. So a call is opened at SAP because the SAP software does not perform as it did before. The SAP support consultants now check the ST06 transaction for changes happened on the hardware layer. But actually nothing happened, the amount of memory is still the same and the number of CPU's also.
Maybe the SAP kernel or database teams are asked to dig deep into their coding to figure out what may caused the software to run this slowly. Such customer calls are very hard to handle, because several parties are involved and none of them is actually responsible, because the hoster just removed some physical CPU's, formerly assigned to the virtual machine of the customer. The customer still have the same amount of virtual CPU's left, but less physical ones behind them. Why the hoster removed the CPU's without telling the customer doesn't matter. Such things happen because they can happen. Without any chance of extended monitoring, which means monitoring the real hardware assigned to a virtual environment, virtualization in enterprise IT business is not ready to use.
Aren't there already available solutions
Yes, there are, but not on standard commodity hardware. IBM for example provides such information via the /proc interface. When running a ppc64 Linux in an LPAR, there is a separate /proc structure which provides all the needed information. Besides configuration values also runtime metrics regarding the virtual machine itself can be viewed through the /proc interface. It happens very often when talking to the open source community that they have concerns regarding the security of such an approach. All I can say is, that these values are only needed on a read only basis. Just knowing the physical details of the virtual machine is not a security issue. This information is also available on a native machine and there the values are correct (not like the mismatch between virtual and physical CPU's).
What does SAP need from virtualization vendors
SAP has a strict policy regarding the monitoring capabilities running in a virtualized environment. The DMTF (Distributed Management Task Force - homepage) provides a CIM model which covers all aspects which SAP needs for monitoring. The intension of relying on such a model is, that the DMTF has lots of members from all IT vendors, regardless if hardware, software or services and we expect all virtualization technologies vendors will support this CIM virtualization model.
I really hope that this blog does clarify the situation why extended monitoring is needed for enterprise businesses. If you have any questions, please feel free to ask it using the comment function below.
