On Thu, Apr 2, 2009 at 4:38 PM, Scott Rohling <[email protected]> wrote:
> - it was nice to feed this data in the existing z/VM accounting which we > already had a billing process for. This is different from what I encounter in several installations. If the VM accounting data is used to feed into the corporate processes that deal with (actual) money, some care is appropriate. In fact, many installations require that those processes are well controlled and tested, and changes must be approved by accountants and others that you don't want to discuss computers with. :-) Fortunately with z/VM it is often easy to avoid running workloads in a single server that must be charged to different departments or customers. In most cases you just create another virtual machine and separate things like that. But my experience is that within a short period of time, folks will be standing in front of your desk argue their VM charges being "out of line" this month, where they really did the same as always or even less because the DBA was on vacation part of the month. Unless you own a big badge and mouth, it is attractive to show the customer detailed Linux process level data to augment the charges. In many cases it will become clear which process caused the excessive charges, and it can be addressed to avoid future incidents like that. Needless to say you want that process data to be *correct* and *complete* - you just make your case much weaker if you show them that the individual processes add up to even much more than what you charged them or add up to something like 20% of what you charged him... ;-) Even though the Linux CPU data would not be used directly in the accounting process, you do need that to be correct so you can show evidence of what you charge them. And yes, there's Performance Monitors that provide this information because our customers needed this. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
