On Wednesday, 07/21/2010 at 05:20 EDT, Ed Long <[email protected]> wrote: > Thanks for thinking about our problem. > So does your construct > > COMMAND DEFINE CPU 00 IFL > > effectively tell VM to assign the first real IFL to this VM as CPU 00? On our > system, the first real IFL is CPU 02 (00 and 01 are the CP's).
No. A z/VM *mode* LPAR on a z10 or zEnterprise has separate pools of CPs, IFLs, ICFs, zIIPs, and zAAPs at its disposal, depending on what's in the LPAR activation profile. By placing the "IFL" keyword on DEFINE CPU, you tell CP to use a real IFL out of the pool when it dispatches the guest. The guest could be dispatched on any available IFL. If you SET CPUAFFINITY OFF for the user (default is ON), all of the virtual CPUs will be dispatched on the "primary" CPU type (CP's for a z/VM mode LPAR). And Ray is correct - in a z/VM mode LPAR you need COMMAND SET VCONFIG MODE LINUX first. Look at the table in the DEFINE CPU command. (VCONFIG MODE ESA/390 is the default for non-Linux-only LPARs.) The relationship between the LPAR *mode*, as defined in the image profile (ESA/390, Linux, z/VM), and the valid primary and secondary CPU types is part of the machine architecture and is important to understand. It can seem a little strange until you realize that the purpose of this part of the architecture is to ensure that an LPAR's CPU configuration (a) is useful, (b) avoids abends, and (c) ensures workloads run on the CPUs they are licensed for. The SET VCONFIG command simulates the LPAR configuration mode and so the virtual CPU configuration is dictated. Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
