On Thursday, 08/20/2009 at 07:28 EDT, Michael Coffin <michaelcof...@mccci.com> wrote: > I actually scoured the z/VM 5.4 doc looking for a documented method of > doing this, but did not find anything specific. I had assumed it would > probably be the CPU directory record that we would use to do this, but > that did not turn out to be the case.
Now that we have the COMMAND statement, there is no longer a compelling reason to add or change directory statements if there is a SET or DEFINE command to alter the virtual machine configuration. Most changes will be in the OPTIONS statement. COMMAND SET and COMMAND DEFINE is precisely the way we intended you to configure such guests. See the DEFINE CPU command for details on knowing when you need SET VCONFIG and/or the TYPE option on DEFINE CPU. > PS: Yes, we've given each Linux server 5 virtual CPU's, which map to > two real IFLs. Our thinking on this is that the Linux guest "should" > dispatch more work simultaneously with 5 CPU's (and the two real IFLs > can more than handle the load). Comments? Good idea/bad idea? Having more virtual CPUs does not give the guest more access to the CPU; it is SET SHARE that does that. In general, the number of virtual CPUs should not exceed the number of logical CPUs that CP has at his disposal. In your configuration, each vCPU has 1/5 of the virtual machine's SHARE value and three of the five vCPUs *must* wait at any given time. But don't take this a "that's all there is" because Linux can manage idle CPUs in a way that avoids the "1/5" effect. However, you still will want to observe the "virtual/logical CPU <= 1" ratio unless you have measurements that justify > 1. And, as Rob says, you actually need an application that *effectively* uses multiple virtual CPUs. Alan Altmark z/VM Development IBM Endicott
