Hello, My personal vision: I think this model was planned for CMS (or equivalent) users, not for the new "plug and play" systems, like zVM itself and Linux. Example: when we attach a dasd to Linux or second level zVM, they recognize the new resource and puts it online, "automagically". So, the signalling mechanism already exist. Why don't extent it to changes in USER DIRECT (HCPDIR?), including memory changes? And left the decision how to process the interrupt to guest OS. Maybe it is material for another "Request For Change".... ______________________________________________ Clovis
|------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Alan Altmark <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |05/11/2010 12:16 | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: HCPGIR450W and HCPGIR453W after editing user direct | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Sent by: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Linux on 390 Port <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| On Friday, 11/05/2010 at 12:59 EDT, Shane <[email protected]> wrote: > We are talking about a hipervisor running (nominally) directly on the > hardware - not a user-space application like VBox. > In my naivety I would expect z/VM to be *very* aware of an interrupt > for a guest IPL. If there are changes in the (z/VM) environment why > wouldn't they resolved immediately at that point ?. It's all "smoke and > mirrors" after all. > Principle of least astonishment should prevail IMHO. During the development of the CIM models for (all) virtualization, it was recognized that a virtual machine has four states: o Defined - the virtual server is defined within the hypervisor, but is not consuming resources (an entry in USER DIRECT) o Active - the virtual server is running (logged on) o Paused - resources allocated, but virtual server is not running (press PA1 with SET RUN OFF) o Suspended - hibernated (saved state) with no real resources (other than disk) allocated. On System z, applies only to newer Linuxen. There are configuration settings associated with the definition of the virtual server, and there are settings associated with the running virtual server. The runtime settings can be constrained by the definition. Consider memory: it has a default and a maximum value in USER DIRECT. The current runtime value can be anything up to the maximum. It would be a Bad Thing if changing the directory changed a running virtual server. That would seriously hamper proper Change Management and would create havoc in a virtual machine. Some conditions are detected only at virtual server IPL and the virtual server has the expectation that they will remain that way forever, as there is no signalling mechanism to tell it that there has been a change. (Consider privilege class.) This is one of the reasons that revoking a virtual machine's access to a minidisk does not DETACH the minidisk from the virtual machine. It is a separate Act of Will to alter the runtime environment. So the question of who is astonished the least depends on who is more important in the equation: you or the virtual machine. :-) You're flexible and understanding, the virtual machine is less so. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 [email protected] 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/ ---------------------------------------------------------------------- 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/
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
