David, After reading your reply, feel free to pass yourself off as me anytime! :-)
Extremely well stated! And it is exactly where I was going with this thread. Bob Richards -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Friday, June 29, 2007 10:55 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes > could you please explain your pain points with GDPS/XRC in your Linux/VM > setup? While z/VM itself doesn't seem to timestamp its I/O Linux does and > z/VM would carry all Linux timestamps out to the storage control unit as > it re-issues the Linux I/O requests. Do you have problems with these > limitations? Other? While I'm not Bob, an observation: The problem here is a common one when having conversations with IBM about virtualization on Z at any real scale. The solution that is offered supports only part of the problem. You've addressed the Linux and z/OS layers, but the z/VM layer -- which is just as important, as it controls the resource allocation to the Linux layer and is directly critical to the cost and ROI cases for having Linux on Z in the first place, is completely left out of the management picture of the solution. If you're trying for a completely managed solution (which is what GDPS is supposed to provide), then omitting a major portion of the solution from the management integration pretty much torpedoes the argument for creating the solution in the first place. If I have to create exceptions to the IBM management infrastructure to *deal with a strategic product made by IBM*, then there is a fundamental design problem here. Having VM be unmanaged in that environment blows the whole premise of completely controllable failover. The same argument applies to EWLM, IRD, and many other things -- GDPS and the tools required to implement really highly-available managed solutions need to be actively cognizant of the presence of VM in scenarios like GDPS, and not treat it as a poor stepchild who can be ignored as a helpless invalid. Treat it as a client, but treat it you must, because it's a critical piece of the plumbing. LPAR isn't an acceptable alternative. LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] ---------------------------------------------------------------------- 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
