IBM OS/390 manual Shared Dasd, New Users of VM

installed. This support exists in VM/ESA Version 2 Release 3 on Multiprise 2000, 9672 G3, and G4 processors.

If you are currently using VM/ESA as a hypervisor for your production VSE guest(s), as well as for test VSE guests, then proceeding with the migration process involves nothing more than defining additional guest virtual machines for OS/390 images. In this environment, you no doubt have already developed expertise in making sure that your production VSE images are not impacted by the performance characteristics of your test VSE images. You will want to apply that discipline also to the OS/390 guests that are installed, and begin execution on your system. If you want to limit the resource consumption of your OS/390 guests, you can do so through the SHARE CP command, or SHARE directory entry along with the HARDLIMIT operand. In addition, you will want to ensure that your physical system has the resources to support the additional guest workload. For example, you will want to review your current utilization of central storage (what is the paging load on the VM system), CPU resources (what is the CPU busy percent), and available DASD. You will also want to look at the utilization of paging areas on DASD, and spool space.

26.3.3.1 Shared DASD

To provide the most flexibility in sharing DASD, you may want to consider defining the OS/390 DASD devices as full pack minidisks rather than dedicated devices. This would allow for sharing among OS/390 images with VM/ESA′ s virtual reserve/release support, as well as for controlled sharing with VSE images. In fact, when sharing with VSE images, VM/ESA provides more protection that could easily be achieved in a native environment, by allowing for R/O links to be defined. One image can have a link defined to the minidisk as a R/O link, and the other can have the minidisk in R/W mode. For the image with the R/O link, the device appears to have the read inhibit switch set. There is no need to perform any manual activity within the guests, since if the guest having the R/O link attempts to write to the device it will be prevented by CP from doing so. Later, when the amount of sharing diminishes, and the need for better performance arises in the OS/390 guest, the devices can be dedicated to the OS/390 guest instead of accessed as full pack minidisks.

26.3.3.2 New Users of VM

If you do not currently use VM/ESA in your VSE environment, the introduction of VM/ESA will take more planning. Most likely you are currently running your VSE production images in separate LPARs, and have one or more test LPARs defined. The first choice you have to make is whether to continue running your CEC in LPAR mode, or run it in native mode with VM/ESA acting as the hypervisor for all of your VSE and OS/390 guests. The other choice you have is to continue to run your production workload in LPARs, and run VM/ESA along with the test VSE guests, and OS/390 guests in another partition. Given that the production environment is most likely well established in an LPAR mode, this latter suggestion would be the least disruptive to implement. The only caveat to be aware of with this approach is that it is not possible to run high performance preferred guests under VM/ESA when it is running in an LPAR. This however should not be a big impact since the use of guests under VM/ESA in this scenario is simply for testing. With this approach you would plan to run your production OS/390 image in an LPAR as is done currently with the production VSE image.

To be most effective, you would want to establish communication connections between the production VSE LPAR(s) and the VM/ESA LPAR, and then let

Chapter 26. Test Environments 425