Richard, there are good number of folks that -will- find this useful to an unbelievable level. Imagine having LPARs loaded with Linux guests - hundreds of them that cross all lines of business at a company. Any outage on any of those LPARs takes over six to eight hours and will only be allowed on Sundays starting at midnight, because everyone and their little sister has to be involved to check, fix and diagnose issues on their applications after things start back up (or don't).
Now imagine that company is growing the Linux LPARs because more and more work is going there, and every quarter they need to add 16-32G on each LPAR. Taking outages like that are painful. Very painful. The 'technical' part of the outage is the easy part; dealing with apps/servers that are not behaving well or application support that just don't understand how things work is the hard part. That company can now save the outage time, the time required for planning the outages, probable outages later due to miss-configured apps/servers, etc etc. With z/VM 5.4, you issue a command and the memory is there (assuming you have done good planning and set the reserve memory when you installed z/VM 5.4!) I do completely understand what you mean in your specific case though. You have spare memory on your machine you "could" use, but would have to give it back when those other LPARs need to run. Maybe there are others like you that require the "release the memory" and would consider entering a requirement to IBM for it. I am sure that concept was probably discussed at some point in the design - it had to be. Any z/VM'er worth their salt will ask "if I can turn it on, can I turn it off? Can I have different colors, hot coffee and an extra week off work with it too?" Just getting the ability to add real memory dynamically is a huge boon and lays the foundation for possibly more feature/function later on. Jim Vincent On Tue, Aug 5, 2008 at 12:38 PM, Schuh, Richard <[EMAIL PROTECTED]> wrote: > ...snip... The new capability is > absolutely useless to us. Nice boilerplate to show in sales pitches to > management, perhaps, but no practical value here. Our VM is as close to > 24 X 365.25 as we can make it. Taking it down to reconfigure the storage > is unacceptable. > > Regards, > Richard Schuh
