> Has anyone ever known a "static environment" that has remained static?
We have had zVM for 10 years, and in the last 8 years we have only retired zLinux systems. Also, our largest zVM LPAR only has 6 zLinux guests with two zVM LPARs only having 1 zLinux guest -- almost no point in running zVM in those cases. > - what disk type do you use (minidisks and EDEV might be interesting to > migrate, new installations are of course always possible) Under zVM we use full-volume ECKD minidisks for zLinux storage. We will simply use full-volume ECKD for the LPARs as well. > - what bonding mode do you want to use on linux? With z/VM on z13 you > will be able to use LACP shared over different z/VM systems. On Linux > LPAR, if you want to use LACP, the ports must be reserved for the > LPAR. We are planning to use bonding mode 0 (active-backup) with primary reselect. Can you recommend a preferred mode for load balancing and failover? > - are your DR and backup procedures relying on z/VM? Nope. We use Netbackup and a nightly rsync for DR (both at the Linux level). > - Do you use OSA with multiple ports, and do you have requirements that > a system should not see the other port of the same adapter? On z/VM, > this can be done, on LPAR it will probably be difficult. Yes, we use OSA w/multiple ports but we do not have the visibility requirement. > That's an interesting direction for your company to take. Can you > elaborate a bit on what drove the decision to not exploit virtualization? Yes, we realize that this direction is generally against the normal flow. However, the overall business direction is to migrate off of the mainframe entirely, and we are under constant pressure to reduce costs in the meantime. Numerous years ago when the architects were looking at virtualization platforms for x86 workloads, the Z solution had a higher TCO, and several of our staple products did not have a s390 binary and refused to work with us or IBM to release one. > As long as you remove all z/VM dependencies from the guests (mindisks, > VDISKS, DIAG250 driver, EDEVs, DR, etc.) before you migrate them to their > own LPARs, then you should be fine. For example, minidisks allowed the > virtual machines to share an I/O configuration. Your IOCDS will need to > be changed to create limited I/O configurations for each LPAR. We set aside a pool of DASD/UCBs for the zVM environment and only gen that range to the zVM LPARs. We will give that same pool to the zLinux LPARs and carefully manage access via cio_ignore and /etc/dasd.conf. > Speaking of IOCDS, how do you plan to manage it? Standalone IOCP? Or is > z/OS on these boxes, too? Yes, we are primarily a zOS shop (so HCD). Actually, the application that we run on zLinux is CPU-intense assembly code that we cross-assemble with Tachyon390 to run in zLinux. We greatly reduced our zOS software costs by moving this CPU-expensive workload onto IFLs. > As usually LPARs have a lot of devices connected to them you might want to > start using cio_ignore if you are not already using it. > Not using cio_ignore can really slow down linux startup when the LPAR has a > lot of devices connected to it. We have cio_ignore=all specified in zipl.conf. We add all system-specific non-root DASD devices and HyperPAV aliases to /etc/dasd.conf We have already migrated our Sandbox, DR, and test zLinux systems into standalone LPARs. So far we haven't seen any technical limitations or really any "negatives" to this setup. Actually, our list of "pros" is much longer than the "cons". I appreciate everyone's responses so far. ---------------------------------------------------------------------- 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/
