IBM introduced a process they call Upgrade in Place, for moving to a new release, when they introduced z/VM 6.3. At that time, the current release was z/VM 6.2, which was also the first release to support Single System Image(SSI). For customers that deployed an SSI cluster of up to four z/VM systems, upgrading all these systems can become time consuming, and the interdependencies between these systems made it necessary to develop a new way of upgrading z/VM.
In the past, upgrading z/VM was straight forward, albeit time consuming and prone to missing past configuration changes. The process involved installing a net new z/VM system, either second level under the existing z/VM system or in a different lpar. This would be just like installing z/VM from scratch, where you would need to make sure you applied all the current maintenance, and got enough of the environment up to enable you to communicate with the production z/VM system. After you had a system that was functional, then the fun started. As part of this migration, you would make all the needed modifications to all the components like, TCP/IP, RACF, RSCS, Dirmaint, etc., which of course you had fully documented (right?). You needed to migrate all your system/user minidisks and configurations over to the new system, while not interfering with production (different IP addresses etc.). At this point, testing would need to be planned and performed to ensure that everything worked properly, and that you didn’t miss anything. At this point, you could set a date for the cutover and go on with things as normal. The one nice thing about this process was, if done properly, you had a fool-proof fall back plan… just switch back to the old production system if your hardware still supported it, and you found the problems early enough. Now, imagine doing this with four or more systems.
IBM’s z/VM Upgrade in Place process takes a different approach. With this new process, you get to leave all your system and user changes in place, along with all your user’s data, and only upgrade the z/VM operating system code allowing for a smother and less error-prone approach to release upgrades. This new process accommodates single system image clusters and allows you to perform upgrades on each of the cluster members independent of the others. It also allows you to fit these upgrades and production cutovers into your schedule more easily because it can be broken up and tested without impacting other members of the cluster. For Linux workloads, you can move the Linux workloads to another member of the SSI cluster, while you upgrade this member and so on, allowing you to keep your Linux guests up and running without disruption. One of the other advantages of this new process is that it is backward compatible. This means, since the newest release of z/VM is 6.4, you can upgrade from either 6.2 or 6.3 directly to 6.4. This helps you get to the newest release, if you were unable to move to 6.3 for whatever reason, without having to upgrade to 6.3 first, and then to 6.4.
This entire process is fully documented in the z/VM Installation Guide. It also has references to other documentation that you may need to reference, depending on which components you have installed on z/VM. The upgrade process is still somewhat time consuming, but it is straight forward and well documented, and you should become familiar with this process.
I hope that IBM continues to improve and simplify this process. Hopefully, one day, we will have a single step UPGRADE exec, just like we have a SERVICE and PUT2PROD exec for streamlining the installation of maintenance. It’s a nice thought, at the least.
Mainline has extensive experience with z/VM and Linux on System z, so please contact your Mainline Account Executive to answer any questions you may have, or to set up a more in-depth discussion about what you can do with z/VM and Linux.
If you’re interested in having Mainline assist you in evaluating this or any other technology, please contact your Mainline Account Executive, or contact Mainline directly.