Technically: when you define a Linux virtual machine, you define how many
processors it can see. The default is only 1. Two statements in the CP
directory are important here:
1. MACHINE, defines how many virtual processors the virtual machine
can define. Example:
MACHINE ESA 4
means the guest can have up to 4
2. CPU, defines a virtual processor; if you don't code it, you get
CPU 0. The CPU record in the directory define whatr you when when logging
on, but with the CP DEFINE CPU, you can define others, up to the limit set
by the MACHINE statement.
So, if you run a 1-CPU Linux virtual machine in a VM LPAR with 2 IFLs, it
can use at most the power of one IFL. Only when you change the Linux
virtual machine to 2 processors, it will be able to use both IFLs
concurrently.
In practice, CP does not dispatch virtual machines, but it dispatches
virtual processors. If you have only one Linux, with the default of one
virtual processor and an LPAR with two IFLs, CP can dispatch this Linux
processor on IFL 0 and later maybe on IFL1, but never on both concurrently.
Even if you'd define your Linux as a 2-way virtual machine, nothing says CP
will dispatch both virtual Linux processors on both IFL's concurrently; it
can do it, but it doesn't have to.
Remember too that CP devides the SHARE of a virtual machine by the number of
virtual processors to set the SHARE of a virtual processor, the dispatch
unit. For example: for a 10-way virtual machine with a SHARE of ABS 10%,
each virtual processor gets a share of ABS 1%, consequently, when the system
is busy, a single task in that virtual machine may have a hard time to
consume more than 1% of a CPU.
Now, which SW licences you have to pay for is another issue
2007/11/23, Brian France <[EMAIL PROTECTED]>:
>
> Hans,
> See below...
>
> At 01:25 AM 11/22/2007, Hans Rempel wrote:
>
> Hi Brian. The fact you are planning on using HATS (Host Access
> Transformation services?) means you will be accessing 3270 screens, from a
> browser (IE or Firefox). This also means you are also running conventional
> (1 or more CP processors) for your CICS? (z/OS or z/VSE) system. You
> mentioned that you are now supporting two z/VM systems. I'm guessing
> management wants to buy one z9 with one or more CP engines to replace your
> old equipment running your conventional OS and at the same time purchase 4
> IFL for new z/LINUX workload.
>
>
> We're already there. We have two z9BC's with a CP each for z/OS and 2
> IFL's each. We had two z/890s with only IFL each and we have production
> linux servers on one vm system on one frame and a test system on the other.
> Yes to what I believe management wants to do here is run HATS for 3270
> screens.
>
>
> HATS is a WebSphere application and in your case WebSphere will be running
> in LINUX on an LPAR with 1 or more IFL engines. The number of IFLs will
> depend on the number of concurrent 3270 session you plan to support. You
> can run LINUX on bare metal (LPAR) without VM but that would NOT be my first
> choice.
>
>
> Any idea what the number of concurrent sessions is that a single IFL
> can handle?
>
>
> I'm guessing that NOT all IFL engines are planned for HATS but rather for
> future consolidation of LINUX or UNIX servers to z/VM LINUX. If you plan to
> have general z/LINUX servers on z/VM than you may create one LPAR and one VM
> for the remaining 3 IFL engines. BUT more than likely you'll want to run
> DB2, ORACLE or other applications and then the license charges for those
> applications come in play which if I recall is based on the number of IFLs
> in an LPAR. Now you need to decide (create business case to see which is
> more cost effective) how many LPARs and VM images you wish to run. The VM
> price will always be the same for 3 LPARS with one dedicated IFL each or 1
> LPAR with 3 IFL engines. Most vendors will now consider an LPAR as a
> physical box and only charge you for the engines dedicated to it. If you
> start sharing engines between LPARs consider being charged for all shared
> engines too.
>
>
> I believe yes on not all IFL engines will be for HATS since it
> appears we've come to the understanding that HATS is a charge per IFL. THAT
> is what I didn't want to here. I was hoping to find a way to have one VM
> LPAR with multiple IFL's but be able to assign an IFL to an image say
> running HATS and then the other images would have access to the other one.
> BUT, alas, I now understand that IF an LPAR has multiple IFL's then all the
> software that runs there see's that as multiple engines. I know from past
> experience here that IF we set this up, I'll end up having two IFL's, one on
> each frame probably, to support HATS. One would be test and one would be
> production. With that then I would now be supporting 4VM systems.
> Unfortunately, I am not that well versed yet in VM so I would have to run 4
> separate VM systems using up the DASD needed to do that.
>
>
--
Kris Buelens,
IBM Belgium, VM customer support
