- Hardware and software cost
- Uncertainty about support
- Lack of mainframe skills among the target market (distributed systems staff)
- Lack of administration tools.
The $1 billion Linux commitment let IBM respond to these in a fashion atypical of the Big Blue of old.
- IBM was able to reduce hardware costs for mainframe Linux through the introduction of the Integrated Facility for Linux (IFL) — a System/390 (and, later, zSeries) CPU restricted by microcode so it cannot run MVS, OS/390, or z/OS. VM didn’t initially run on IFLs; this restriction was soon eased with z/VM Version 4.
- With z/VM 4.1, IBM significantly lowered z/VM pricing. The biggest change in the pricing is a shift from monthly rental to an initial purchase, plus annual maintenance. This is more in line with typical distributed system pricing and is easier for customers to accept. Often, customers “stuck” back on hardware that cannot run z/VM can justify a hardware upgrade based solely on their software savings!
- With the growth of IBM Global Services, IBM was also able to assure customers worried about Linux support that IBM Global Services could provide what they needed. Consulting firms and other companies also offer such services and IBM has been open about helping customers choose support levels appropriate for their needs, even when that doesn’t involve IBM Global Services.
- IBM also revived their VM training, which had all but vanished when there were so few new VM installations, although the curriculum is hardly as complete as it was 20 years ago.
- For administration tools, IBM has encouraged third-party vendors to offer products and IBM’s Tivoli division is rumored to be working on solutions, too. Since administration is an area where one-size-doesn’t-fit-all, this seems an excellent solution.
Evolution Follows Revolution
While Linux on VM offers excellent value now, there’s room for improvement, and both VM and Linux are evolving.
Networking is an area of relative complexity. Linux guests typically use TCP/IP, and each is its own IP host. On VM, the entire system is traditionally a single host, with individual virtual machines providing services on specific ports, managed through VM’s TCP/IP stack. If a guest wishes to provide its own TCP/IP stack, it either owns a real Open Systems Adaptor (OSA) port, or connects to VM’s stack via virtual channel- to-channel adaptor.
For dozens or hundreds of Linux guests, this is unwieldy at best. The VM TCP/IP service isn’t designed for dynamic reconfiguration, so adding and deleting guests on-the-fly is difficult. Managing a separate channel-to-channel adaptor for each Linux guest is tedious.
z/VM 4.2 introduced Guest LANS and virtual HiperSockets. Like other real hardware virtualized by VM, these are constructs, built and managed by VM’s CP component, which emulate real LANs and real HiperSockets. Linux images running on VM are unaware whether the communications devices they’re using are real or virtual. One clue, should a guest care, is throughput. Since Guest LANs run at memory speed, they offer throughput of several gigabits per second!
Using virtual HiperSockets, tens, hundreds, or thousands of Linux guests can interoperate on a single z/VM system simply by plugging into the Guest LAN. Connectivity to the outside can be achieved through a real OSA or other device attached to a TCP/IP stack on VM or to a Linux guest, acting as a router. To configure Guest LANs, you can use the CP command, the SYSTEM CONFIG file, and individual users’ virtual machine entries in the VM user directory.
Guest LANs quickly proved a perfect fit for Linux on VM. Guest LANs make it trivial to connect Linux guests to internal and external TCP/IP networks. Their throughput means network latency between guests is almost zero, and collisions and dropped packets are nonexistent. When the other end of a connection is an MVS (OS/390, z/OS) system running on the same physical system, the high speed and reliability of the connection are even more attractive.
z/VM 4.3 improved Guest LAN support to enable services such as Dynamic Host Configuration Protocol (DHCP) and Samba, which require IP broadcast support.
An interesting cultural issue has been that IBM considers HiperSockets and QDIO technology proprietary, so the Linux drivers for these devices are OCO. This doesn’t sit well with the Linux faithful, but IBM has responded quickly to any problems with the drivers and issues have been minimal. Since all other mainframespecific changes have been submitted to the Linux kernel maintainers per normal practice, it’s clear that IBM is truly joining the Linux community.