Hi James,
I just went through this exercise along with actually talking to one of the original developers of VMRM. After much testing I found as you are finding that VMRM in terms of being a Workload Manager does not quite cut it. I too wanted to use it as a way to control the importance of workloads based on my business requirements but it just never gave me a consistent warm and fuzzy. So after speaking with the developer and hearing his take on it, which was basically to use Relative and Absolute Share setting manually instead of depending on VMRM I decided to bag it. I did however express my opinion that with the advent of multiple Linux guests and the differing business requirements that there is a definite need for a Workload Manager type of software that will allow you to control the priorities of the workloads. Having a lot of experience with WLM on z/OS this is a must moving forward and I expressed that to IBM. Actually it even goes further than just z/VM at some point being able to control the priorities of the individual z/Linux processes would be great. Thanks, Terry From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Sterling James Sent: Thursday, January 07, 2010 11:59 AM To: [email protected] Subject: Using VMRM Hello, I'm starting to try to use VMRM to handle "meeting our business goals". I'm trying to; 1) Prioritizing workloads/guests; "most-loved", "not as much", least , and bottom-feeders 2) setting VMRM's config file to match this above list. Hoping that the highest will get as much as it needs (within reason), following down the list, and, if the CPU resources are sufficient, all will get enough to accomplish their tasks satisfactorily. We do not use VMRM for CMM, or setting DASD velocity goals. I am testing this on a low activity system (test lpar) so the results may be shewed because due to the lack of competition for CPU resources. The following is what I have seen about how VMRM determines when/how to adjust; A sample monitor interval of less than 1 minute or more than 5 minutes is not recommended. For CPU goals, all of the following must be true: The user has a Relative share setting. The user does not have LIMITHARD specified on the CPU SHARE setting. The user is not already within 5% of the goal for the user. The CPU velocity goal is the percentage of time that the workload should receive CPU resources when it is ready to consume them. This is computed by taking the time the users are running and dividing the sum of time the users are running or waiting for CPU. The variable target must be an integer from 1 to 100. If a user is within a reasonable percent of the target goal, they will be considered to have met the goal, and no adjustments will be made for this user – Workloads are selected first based on importance value – If a workload was selected in the last interval either for improvement or degradation, it is skipped and an attempt is made to select another – If there are workloads of equal importance, the workload farthest from its goal is selected – Eligible users within a workload will have their SHARE or IOPRIORITY adjusted appropriately based on how far they are from the workload goal • Individual users within selected workload may be adjusted based on calculations from monitor data – User must have Relative Share and I/O Priority settings – User does not have Limithard specified for CPU Share – Sum of wait and run deltas is > current sample size of 5 – Sum of I/O and Outprioritized deltas is > current sample size of 5 – CPU actual = run delta / (run delta + wait delta) * 100 – DASD actual = IO delta / (IO delta + outprior delta) * 100 • If above criteria is met and user is not within 5% of goal, then they can be adjusted How to adjust each user – relvalue = (CPU goal / actual) * User current share The current sample size of 5 is a threshold value. It used to determine if there is enough data to make decisions on for the user. For example; with monitor settings of; INTERVAL 1 MINUTES RATE 5.00 SECONDS a user would need to be active at least 5 of the 12 samples. From my testing, VMRM does not provide the results that I expected. After adjusting workloads, goals, and importance; VMRM sets relative shares for most-loved and bottom-feeders the same. My view may be tainted by past experiences with WLM on zOS, but I assume this may be due to VMRM just looking at the last interval vs a loner period for sampling. Also, I found VMRM logs and the PerfToolKit's display very lacking in helpful data in this area. Has anyone had a more positive experience with VMRM? Or am I missing something? Thanks, ----------------------------------------- Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
