Tim, I am not sure I have a good understanding of this.
Now, to your post. You actually hit a problem we have. We have a z/10 that is running 5 z/OS LPARs and memory allocation is not the best. You indicate that running z/OS under VM might be the answer. But, a few years ago, some testing made us discount z/VM for such. Maybe our testing was faulty.
We had a customer running OS/390 (yes, that old) on a z/800. We have since moved them to a z/10 which has worked well for over a year. During the initial testing of OS/390 on the z/10, we thought we would need to run it under z/VM. What we found was that simple backup processing (full volume dumps to tape) took almost twice as long under z/VM than in a native LPAR. A couple of posts on the z/VM list seem to tell us that using guests (either z/OS or z/VSE) with less than 2 real CPUs would affect I-O performance.
Maybe we misunderstood something. What are your thoughts on it? Tony Thigpen Timothy Sipples wrote on 07/17/2017 04:22 AM:
OK, I'll start offering some personal thoughts on today's major announcements, and in no particular order. I'll start in what might be an unexpected place: sub-capacity z/VM licensing. That announcement letter is available here: https://www.ibm.com/common/ssi/rep_ca/9/872/ENUSAP17-0259/ENUSAP17-0259.PDF I'm quite happy with this announcement, fundamentally because it provides you all with some interesting, useful flexibility in what you might call the "hybrid cloud journey." IBM is now allowing sub-capacity licensing of z/VM and of most IBM z/VM-related products and features. That's for all operating systems that z/VM supports. What this means in practice is that you can now configure your machine(s) with "anchor tenant" LPARs -- LPARs running Linux, z/OS, and/or other operating systems -- alongside z/VM LPARs. For example, let's suppose you have z/VM and use it to run Linux guests on your machine. But, sadly, you don't have z/VM for z/OS yet. Well, now you can license one additional engine (CP) of z/VM and run z/OS within z/VM on that engine -- even within a z/VM LPAR that spans CPs, zIIPs, and IFLs if you wish. So you can spin up lots and lots of z/OS guests for development, testing, system programmer fun, production, etc., etc. And you can do all that for not very much money at all. In fact, it'll probably save you money since z/VM can overcommit memory in many real world scenarios and since you can shrink (or cap) the number of LPARs to some extent. With z/VM you don't have to "pin" system memory as you do with LPARs. So you can do "some of all of the above": buy lots more memory (it's a lot more affordable), allocate more memory to your "anchor tenant" LPARs, and overcommit memory to some degree using z/VM. For example, you might have a couple of big, beefy, analytics and database workloads that make sense to run in LPARs. (Maybe they need a huge amount of memory, another area where the new IBM z14 excels.) Then, for smaller and more numerous Linux guests -- such as your developer cloud -- you have one or a couple IFLs running z/VM. That's fine, you can do that. You have sub-capacity licensing flexibility. You don't have to license every IFL and/or every CP on your machine(s). Whatever makes technical sense you should be able to do in a more financially attractive way. To net it out, if you haven't adopted z/VM yet -- or if your adoption is only for one operating system among the two or more than you run -- take a serious look at licensing at least one z/VM engine (or one more engine). It's a great deal. More reactions to come.... -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
