1 / 35

Linux

Agenda. Introduction to S/390VM

clement
Download Presentation

Linux

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Linux/390 A tale of two Ports Subtitle: Any port in a storm. On December 18, 1999, IBM published its modifications and additions to the Linux 2.2.13 code base for the support of the S/390 architecture. This port is designed to run under VM/ESA and natively. The code has subsequently been rolled into the 2.2.15 level and is in the process of being incorporated into 2.3.x. This presentation will discuss the implementation of Linux on the S/390 architecture.Subtitle: Any port in a storm. On December 18, 1999, IBM published its modifications and additions to the Linux 2.2.13 code base for the support of the S/390 architecture. This port is designed to run under VM/ESA and natively. The code has subsequently been rolled into the 2.2.15 level and is in the process of being incorporated into 2.3.x. This presentation will discuss the implementation of Linux on the S/390 architecture.

    2. Agenda Introduction to S/390 VM & Open Source i370-ibm-linux s390-ibm-linux I/O layer & Virtualization Applications MVL - Virtual Penguin Power In this presentation I will be looking at the port of Linux to S/390. To do so I will provide: an overview of S/390 architecture and its genesis; the VM operating system which is an important part of the fledgling Linux/390 community; a look at the two porting efforts; a specific look at the I/O architecture which is the biggest difference between S/390 and the other ports; a look at the applications the community have started running; and, a vision for using Linux in S/390 which has been dubbed “Multiple Virtual Linuxes” or “Virtual Penguin Power”.In this presentation I will be looking at the port of Linux to S/390. To do so I will provide: an overview of S/390 architecture and its genesis; the VM operating system which is an important part of the fledgling Linux/390 community; a look at the two porting efforts; a specific look at the I/O architecture which is the biggest difference between S/390 and the other ports; a look at the applications the community have started running; and, a vision for using Linux in S/390 which has been dubbed “Multiple Virtual Linuxes” or “Virtual Penguin Power”.

    3. Linux/390 Background

    4. Introduction to S/390 Descendent of S/360 Upwardly compatible architecture EBCDIC character set Big endian 16 GPR, 4/16 FPR, 16 CR 2 tier paging schema Multiple address spaces The System/390 architecture has evolved from the original S/360 of the 1960s. In that time there have been radical changes and enhancements but a programmer from that era would recognize many of the facilities of the S/390. S/360, S/370, and S/390 (or ESA/390 as it is now known) are upwardly compatible. It was originally designed to allow programs written for earlier IBM hardware to be migrated to the “new” S/360. This required that S/360 was an EBCDIC machine. Above all else, this feature is what differentiated and separated the S/360 from the rest of the computing world. S/390 is a big endian architecture which has 16 GPR registers, 4 (older) and (now) 16 FPR (IBM and IEEE format), and 16 control registers which control machine operation (address spaces, interrupt masks etc.) Like many of the other platforms (e.g. i386, powerPC) S/390 uses a two-tier paging scheme: “segments” and “pages” as opposed to the 3 tier mechanism defined in Linux. In addition, ESA/390 allows for multiple address spaces (2GB each) and multiple TLBs. Theoretically, up to 16TB of address spaces can be controlled by the hardware. This feature is exploited in the Linux/390 port simplifying the copy_to_user() type process to a couple of instructions. A 64 bit version of the hardware is rumored for release in the near future.The System/390 architecture has evolved from the original S/360 of the 1960s. In that time there have been radical changes and enhancements but a programmer from that era would recognize many of the facilities of the S/390. S/360, S/370, and S/390 (or ESA/390 as it is now known) are upwardly compatible. It was originally designed to allow programs written for earlier IBM hardware to be migrated to the “new” S/360. This required that S/360 was an EBCDIC machine. Above all else, this feature is what differentiated and separated the S/360 from the rest of the computing world. S/390 is a big endian architecture which has 16 GPR registers, 4 (older) and (now) 16 FPR (IBM and IEEE format), and 16 control registers which control machine operation (address spaces, interrupt masks etc.) Like many of the other platforms (e.g. i386, powerPC) S/390 uses a two-tier paging scheme: “segments” and “pages” as opposed to the 3 tier mechanism defined in Linux. In addition, ESA/390 allows for multiple address spaces (2GB each) and multiple TLBs. Theoretically, up to 16TB of address spaces can be controlled by the hardware. This feature is exploited in the Linux/390 port simplifying the copy_to_user() type process to a couple of instructions. A 64 bit version of the hardware is rumored for release in the near future.

    5. Introduction to S/390 Huge range of processors supported: Cards that fit in a lap top Desktop and tower models 16-way SMP configurations Emulators for your PC Hercules Flex-ES The ESA/390 architecture is implemented on processors that range from a card that slips into your laptop to a 16-way SMP configuration that sits in a corner of the machine room not much larger than a refrigerator. IBM ships a 12-way SMP, HDS currently ships a 13-way with a 16-way ready to ship, and Amdahl also ship a 16-way. In addition, emulators like Hercules and Flex turn your PC into a machine capable of running any S/390 operating system and applications.The ESA/390 architecture is implemented on processors that range from a card that slips into your laptop to a 16-way SMP configuration that sits in a corner of the machine room not much larger than a refrigerator. IBM ships a 12-way SMP, HDS currently ships a 13-way with a 16-way ready to ship, and Amdahl also ship a 16-way. In addition, emulators like Hercules and Flex turn your PC into a machine capable of running any S/390 operating system and applications.

    6. Introduction to S/390 Initially, batch oriented O/S PCP, TOS, DOS & OS/360 OS/MFT OS/MVT OS/VS1, OS/VS2 MVS, DOS/VS OS/390, VSE/ESA In the early days computing was batch orientated and the Operating Systems first used on the architecture reflected this. There were O/S called Basic Operating System; Tape Operating system; and Disk Operating System. These evolved into the predecessors of OS/390 and VSE/ESA. As they evolved time-sharing and real-time capabilities were added to themIn the early days computing was batch orientated and the Operating Systems first used on the architecture reflected this. There were O/S called Basic Operating System; Tape Operating system; and Disk Operating System. These evolved into the predecessors of OS/390 and VSE/ESA. As they evolved time-sharing and real-time capabilities were added to them

    7. Introduction to S/390 Time-share & Hypervisors CP-40, CP-67, VM/370, VM/SP, VM/ESA Virtualize a real machine Padded cell for multiple users “Guest” operating systems Even run VM under VM In order to build its batch operating systems without having to buy tens of real boxes, which were extremely expensive, some developers came up with the concept of a virtual machine. They took this concept and instantiated in operating systems called CP-40 and CP-67 which were the predecessors of today’s VM/ESA. In the interim the system has been completely re-written (in the early 90s) such that the internals are vastly different from the early days but the concept of the virtual machine remains. In these virtual machines you can run anything that you could run on the bare iron, including a copy of VM/ESA (and a copy running in that copy and so on). Virtual machines have found renewed interest in things like VMWare and Java Virtual Machines.They provide a “padded cell environment” that isolates one user from another while providing them with access to both the real resources of the machine and the virtual resources of the VM operating system. You can define multiple virtual CPUs when only one or two real ones exist or virtual disks.In order to build its batch operating systems without having to buy tens of real boxes, which were extremely expensive, some developers came up with the concept of a virtual machine. They took this concept and instantiated in operating systems called CP-40 and CP-67 which were the predecessors of today’s VM/ESA. In the interim the system has been completely re-written (in the early 90s) such that the internals are vastly different from the early days but the concept of the virtual machine remains. In these virtual machines you can run anything that you could run on the bare iron, including a copy of VM/ESA (and a copy running in that copy and so on). Virtual machines have found renewed interest in things like VMWare and Java Virtual Machines.They provide a “padded cell environment” that isolates one user from another while providing them with access to both the real resources of the machine and the virtual resources of the VM operating system. You can define multiple virtual CPUs when only one or two real ones exist or virtual disks.

    8. Previous UNIX Attempts True ASCII with major APIs AIX/370 (defunct) AIX/ESA (defunct) UTS (alive and kicking) OSIRIS $$$$

    9. VM & Open Source VM/370 totally source maintained with significant user input VM/SP owned by IBM but source available VM/ESA most source but OCO and OCM pieces IBM now have “rediscovered” Open Source VM started out in IBM but was soon adopted by the user community who soon started providing new functions, enhancements and fixes to the operating system. The code was a licenced program product of IBM but was free of charge and came with complete source. Gradually, what had been public started to become more and more private. By 1991, the time Linus was releasing his first Linux efforts, IBM made major parts of VM OCO and OCM Everything that Richard Stallman was advocating in Open Source was opposite to what IBM was doing Finally, after working its way through the beast that is IBM bureaucracy (and the bottom line was starting to hurt) IBM have rediscovered Open Source. VM has long been the bastard child of IBM. It is extremely efficient which means you don’t need as much hardware to run which doesn’t please those who sell the hardware. Every so often IBM attempts to kill it off but it proves more resilient. Now with Linux/390 it will again come into its own.VM started out in IBM but was soon adopted by the user community who soon started providing new functions, enhancements and fixes to the operating system. The code was a licenced program product of IBM but was free of charge and came with complete source. Gradually, what had been public started to become more and more private. By 1991, the time Linus was releasing his first Linux efforts, IBM made major parts of VM OCO and OCM Everything that Richard Stallman was advocating in Open Source was opposite to what IBM was doing Finally, after working its way through the beast that is IBM bureaucracy (and the bottom line was starting to hurt) IBM have rediscovered Open Source. VM has long been the bastard child of IBM. It is extremely efficient which means you don’t need as much hardware to run which doesn’t please those who sell the hardware. Every so often IBM attempts to kill it off but it proves more resilient. Now with Linux/390 it will again come into its own.

    10. Linux/390 Two Ports in a Storm As Linux built in popularity the general population of computer programmers and administrators became Linux literate. This is true in the S/390 world. To the VM community there was even envy as Linux’s development was how they had hoped VM to have developed until the policy of OCO and OCM crippled the community’s ability to contribute. The skill-base, the technology, and the application-base are all highly attractive to any organization that wishes to keep growing. As a long time VM’er I could see the synergies between the two operating systems. VM refers to virtual machines running their own operating systems as “guests”. Sometimes, ill-behaved guests are referred to as parasites but in Linux’s case it could be seen that, especially with source, it would be a very welcome guest. Therefore, it wasn’t a surprise that efforts at porting Linux to yet another architecture would be undertaken. This section describes two of these efforts. One done totally in the public eye, the other (by necessity for the developers who didn’t want to “scare” the rest of IBM) done as a skunk-work project within IBM.As Linux built in popularity the general population of computer programmers and administrators became Linux literate. This is true in the S/390 world. To the VM community there was even envy as Linux’s development was how they had hoped VM to have developed until the policy of OCO and OCM crippled the community’s ability to contribute. The skill-base, the technology, and the application-base are all highly attractive to any organization that wishes to keep growing. As a long time VM’er I could see the synergies between the two operating systems. VM refers to virtual machines running their own operating systems as “guests”. Sometimes, ill-behaved guests are referred to as parasites but in Linux’s case it could be seen that, especially with source, it would be a very welcome guest. Therefore, it wasn’t a surprise that efforts at porting Linux to yet another architecture would be undertaken. This section describes two of these efforts. One done totally in the public eye, the other (by necessity for the developers who didn’t want to “scare” the rest of IBM) done as a skunk-work project within IBM.

    11. i370-ibm-linux Started by Linas Vepstas Developed port of GCC & GLIBC based on work of David Pitts Basic kernel I joined in mid 1999 Developed architecture Memory management Process I/O fundamentals I first attempted a port back in 1997 but had neither the time nor the gcc-compiler skills to get very far. Fortunately, Linas Vesptas and David Pitts have such skills (and more) and were able to get the infrastructure built to enable a port to happen. I joined Linas in early 1999 having access to significant S/390 resources (2 way SMPs, 725MB memory, GBs of DASD) that I could use to help the effort We were soon joined by several others including Rob Van Der Heij from the Netherlands and Peter Schulte-Stake of Germany. Between us (and Linas was by far the guiding light and designed the key architectural constructs) we were able to get a kernel that did the basics: Memory management. Process control Primary I/O functions (device detection and limited driving) Rudimentary bottom-half handling RAMDISK handling By September we were booting the kernel and had it to the stage of invoking the first user process.I first attempted a port back in 1997 but had neither the time nor the gcc-compiler skills to get very far. Fortunately, Linas Vesptas and David Pitts have such skills (and more) and were able to get the infrastructure built to enable a port to happen. I joined Linas in early 1999 having access to significant S/390 resources (2 way SMPs, 725MB memory, GBs of DASD) that I could use to help the effort We were soon joined by several others including Rob Van Der Heij from the Netherlands and Peter Schulte-Stake of Germany. Between us (and Linas was by far the guiding light and designed the key architectural constructs) we were able to get a kernel that did the basics: Memory management. Process control Primary I/O functions (device detection and limited driving) Rudimentary bottom-half handling RAMDISK handling By September we were booting the kernel and had it to the stage of invoking the first user process.

    12. i370-ibm-linux Developed under VM and Hercules Trace facilities of VM indispensable The LINUX-VM listserver was set up to allow the world to contribute We were aware of rumors and some facts about an internal IBM project porting Linux to S/390 as well Development was primarily done under VM/ESA and some on Hercules. The trace facilities of VM were indispensable. VM has many sophisticated trace capabilities that allow you to shoot bugs with I/O, virtual memory activities, program flow and control, register and storage modification etc. It can produce these interactively or generate a printout. Most of the time we’d do things interactively but the print facility when coupled with the system map and a couple of simple scripts produced extremely useful debugging aids. The i370 was a totally public effort. Communications and diffs were published to web sites and the LINUX-VM mailing list. Amidst our gradual progress we began to hear rumors of a skunk-work project within IBM which was also porting Linux to S/390.Development was primarily done under VM/ESA and some on Hercules. The trace facilities of VM were indispensable. VM has many sophisticated trace capabilities that allow you to shoot bugs with I/O, virtual memory activities, program flow and control, register and storage modification etc. It can produce these interactively or generate a printout. Most of the time we’d do things interactively but the print facility when coupled with the system map and a couple of simple scripts produced extremely useful debugging aids. The i370 was a totally public effort. Communications and diffs were published to web sites and the LINUX-VM mailing list. Amidst our gradual progress we began to hear rumors of a skunk-work project within IBM which was also porting Linux to S/390.

    13. s390-ibm-linux Skunk-work project within IBM Kernel running by May 1999 Activity kept secret Constant rumours Published mods on December 18 Now actively working with community Rolling mods into 2.3.x IBM is an interesting organization. It has more than its fair share of Nobel prize winners, has some of the best minds in the industry, and a more than generous quota of people who are open and always willing to help. However, due to its size it also has a bureaucracy of immense proportions and a goodly number of empire builders and ultra-conservatives. This is not a surprise as any organization this large is, in fact, a microcosm of society. Thus, a project as politically sensitive and, perhaps, as radical, as this had to proceed carefully. Therefore, a project involving a small group of dedicated developers (a key factor in any successful software development) were assembled and funded to develop the port. The flip side of this secrecy was that the lessons learned by others, especially in the i370 port, were unable to be passed on nor information exchanged. There were several lessons we learned in the i370 port that we see have had to be relearned in the s390 effort. This is a classic example of why true Open Source development is so valuable. There has been some justified feeling of being under-valued by the i370 porters but if nothing else, I believe the public and published progress of the i370 port helped force IBM’s hand and on December 18 the diffs to all they key components were published. The IBM team are now in constant and public communication with the community (LINUX-VM).IBM is an interesting organization. It has more than its fair share of Nobel prize winners, has some of the best minds in the industry, and a more than generous quota of people who are open and always willing to help. However, due to its size it also has a bureaucracy of immense proportions and a goodly number of empire builders and ultra-conservatives. This is not a surprise as any organization this large is, in fact, a microcosm of society. Thus, a project as politically sensitive and, perhaps, as radical, as this had to proceed carefully. Therefore, a project involving a small group of dedicated developers (a key factor in any successful software development) were assembled and funded to develop the port. The flip side of this secrecy was that the lessons learned by others, especially in the i370 port, were unable to be passed on nor information exchanged. There were several lessons we learned in the i370 port that we see have had to be relearned in the s390 effort. This is a classic example of why true Open Source development is so valuable. There has been some justified feeling of being under-valued by the i370 porters but if nothing else, I believe the public and published progress of the i370 port helped force IBM’s hand and on December 18 the diffs to all they key components were published. The IBM team are now in constant and public communication with the community (LINUX-VM).

    14. s390-ibm-linux ASCII IEEE floating point Runs: Bare iron In an LPAR In a virtual machine IBM’s UNIX API efforts for OS/390 and VM/ESA called “Open Edition” or “UNIX System Services (USS)” used EBCDIC encoding which had the immediate effect of exponentially increasing the porting effort. The Linux/390 port is pure ASCII. Until recent times IBM had its own floating point hardware implementation that predates IEEE. It has advantages over IEEE but also has disadvantages, the most obvious and important is compatibility! Not all the new hardware has the IEEE support but the Linux/390 code incorporates software emulation (just like 80387 emulation on the Intel platform). IBM’s UNIX API efforts for OS/390 and VM/ESA called “Open Edition” or “UNIX System Services (USS)” used EBCDIC encoding which had the immediate effect of exponentially increasing the porting effort. The Linux/390 port is pure ASCII. Until recent times IBM had its own floating point hardware implementation that predates IEEE. It has advantages over IEEE but also has disadvantages, the most obvious and important is compatibility! Not all the new hardware has the IEEE support but the Linux/390 code incorporates software emulation (just like 80387 emulation on the Intel platform).

    15. Linux/390 I/O Layer

    16. I/O Layer S/390 I/O is “channelized” Work performed by channels Device eccentricities hidden from O/S Single mechanism of talking to devices DMA Interrupt-based Different than other hardware architectures, ESA/390 has defined a unified I/O access method. This gives relief to the device drivers as they do not have to deal with different bus types, polling versus interrupt processing, shared versus non-shared interrupt processing, DMA versus port I/O (PIO), and other hardware features more. However, this implies that either every single device driver needs to implement the hardware I/O attachment functionality itself, or the operating system provides for a unified method to access the hardware, providing all the functionality that every single device driver would have to provide itself. In order to build common device support for ESA/390 I/O interfaces, a functional layer was introduced that provides generic I/O access methods to the hardware. Though the ESA/390 hardware platform knows about a huge variety of different peripheral attachments like disk devices (also known as DASD), tapes, communication controllers, they can all by accessed by a well defined access method and they are presenting I/O completion a unified way: I/O interruptions. Every single device is uniquely identified to the system by a so-called subchannel, where the ESA/390 architecture allows for 64k devices to be attached. (Lung 1999) Different than other hardware architectures, ESA/390 has defined a unified I/O access method. This gives relief to the device drivers as they do not have to deal with different bus types, polling versus interrupt processing, shared versus non-shared interrupt processing, DMA versus port I/O (PIO), and other hardware features more. However, this implies that either every single device driver needs to implement the hardware I/O attachment functionality itself, or the operating system provides for a unified method to access the hardware, providing all the functionality that every single device driver would have to provide itself. In order to build common device support for ESA/390 I/O interfaces, a functional layer was introduced that provides generic I/O access methods to the hardware. Though the ESA/390 hardware platform knows about a huge variety of different peripheral attachments like disk devices (also known as DASD), tapes, communication controllers, they can all by accessed by a well defined access method and they are presenting I/O completion a unified way: I/O interruptions. Every single device is uniquely identified to the system by a so-called subchannel, where the ESA/390 architecture allows for 64k devices to be attached. (Lung 1999)

    17. I/O Layer New layer of abstraction IRQ structure used New major devices: /dev/ddxn - S/390 DASD (ECKD) /dev/mndx - VM minidisks /dev/ctcx - CTCA & LAN /dev/iucv - Network (LAN) device Dumb tty and hardware console In order not to introduce a new I/O concept to the common Linux code, Linux/390 preserves the IRQ concept and semantically maps the ESA/390 subchannels to Linux as IRQs. This allows Linux/390 to support up to 64k different IRQs, uniquely representig a single device each. (Lung 1999) There are several new devices defined for S/390: /dev/ddxn - DASD that uses the Extended Count Key Data (ECKD) geometry such as 3390. Under VM these can be subsets of a full device that Linux sess as a real (though smaller than normal) device. These minidisks can live anywhere on real DASD and can be moved from real device to real device. /dev/mndx - VM minidisks of any geometry. The minidisks may be ECKD, CKD, or FBA geometries. They appear to Linux as pure fixed block devices. As with other VM minidisks these can live anywhere and can, in fact, be VM RAMDISKS. /dev/ctcx - Channel-to-Channel adapter which is a device used to connect CPUs. Under VM these can be virtual (memory-to-memory constructs) and be used to connect virtual machines. /dev/osax - The Open Systems Adapter which provides an (Fast) Ethernet, Token Ring, FDDI, or ATM interface to a network. Currently only Ethernet and Token Ring are supported. /dev/iucv - A VM-only method of connecting virtual machines. This is basically a storage-to-storage transfer mechanism that transfers data up to 500MB/sec Support for an emulated dumb tty and the S/390 hardware console for booting Linux is provided. In order not to introduce a new I/O concept to the common Linux code, Linux/390 preserves the IRQ concept and semantically maps the ESA/390 subchannels to Linux as IRQs. This allows Linux/390 to support up to 64k different IRQs, uniquely representig a single device each. (Lung 1999) There are several new devices defined for S/390: /dev/ddxn - DASD that uses the Extended Count Key Data (ECKD) geometry such as 3390. Under VM these can be subsets of a full device that Linux sess as a real (though smaller than normal) device. These minidisks can live anywhere on real DASD and can be moved from real device to real device. /dev/mndx - VM minidisks of any geometry. The minidisks may be ECKD, CKD, or FBA geometries. They appear to Linux as pure fixed block devices. As with other VM minidisks these can live anywhere and can, in fact, be VM RAMDISKS. /dev/ctcx - Channel-to-Channel adapter which is a device used to connect CPUs. Under VM these can be virtual (memory-to-memory constructs) and be used to connect virtual machines. /dev/osax - The Open Systems Adapter which provides an (Fast) Ethernet, Token Ring, FDDI, or ATM interface to a network. Currently only Ethernet and Token Ring are supported. /dev/iucv - A VM-only method of connecting virtual machines. This is basically a storage-to-storage transfer mechanism that transfers data up to 500MB/sec Support for an emulated dumb tty and the S/390 hardware console for booting Linux is provided.

    18. Linux/390 Applications Thanks to the keeper of the Princeton University VM system, Melinda Varian, the i370 team were granted significant resources on the Princeton S/390 system that enabled us to set up a fully functioning Linux system. On this system we have been able to build and test many of the major (and not so major) packages. In addition, we have setup web pages containing resources such as tutorials, patches, and presentations to help people get their own Linux/390 systems up and running. In this section of the presentation I’ll describe some of the packages that have already been ported to Linux/390 and how a port is usually just a simple matter of running the configuration script. I’ve included some screenshots to show Linux/390 in action.Thanks to the keeper of the Princeton University VM system, Melinda Varian, the i370 team were granted significant resources on the Princeton S/390 system that enabled us to set up a fully functioning Linux system. On this system we have been able to build and test many of the major (and not so major) packages. In addition, we have setup web pages containing resources such as tutorials, patches, and presentations to help people get their own Linux/390 systems up and running. In this section of the presentation I’ll describe some of the packages that have already been ported to Linux/390 and how a port is usually just a simple matter of running the configuration script. I’ve included some screenshots to show Linux/390 in action.

    19. Applications Kernel, tools and file systems were available from Marist College “Porting” of packages commenced Porting generally consists of an update to config.sub to recognize s390-ibm-linux As soon as the IBM patches were made public a site at Marist University was opened that made binaries of the kernel, the documentation, and a couple of filesystems available to the public. Quickly people had used these resources to setup their own Linux/390 environments and began to explore its usefulness. As part of this we started to “port” their favorite Linux tools and applications. We were pleasantly surprised that “porting” generally consisted of an update to config.sub to recognize s390-ibm-linux and running the configure script. Very soon important applications such as Apache, Samba, PostgresSQL, linuxconf, sendmail, bind, SSL, and SSH were up and running. As soon as the IBM patches were made public a site at Marist University was opened that made binaries of the kernel, the documentation, and a couple of filesystems available to the public. Quickly people had used these resources to setup their own Linux/390 environments and began to explore its usefulness. As part of this we started to “port” their favorite Linux tools and applications. We were pleasantly surprised that “porting” generally consisted of an update to config.sub to recognize s390-ibm-linux and running the configure script. Very soon important applications such as Apache, Samba, PostgresSQL, linuxconf, sendmail, bind, SSL, and SSH were up and running.

    20. Applications THE 3.0 Regina 0.08h OpenSSL linuxconf 1.17r2 wxxt-1.67 Postgresql-6.5.3 Apache 1.3.9 Samba 2.0.6 sendmail 8.9.3 bind 8.2.2-p5 sshd 1.2.27 hercules 1.46 BOCHS Big Brother 1.3a Lynx 2.8.2 Emacs 20.5a The following slides show a (non-comprehensive) list of applications that are now up and running under Linux/390.The following slides show a (non-comprehensive) list of applications that are now up and running under Linux/390.

    21. Applications ncFTP 3.0b21 PGP 5.0i cron 3.0.1 PHP 3.0.14 ytalk 3.1.1 perl 5.005_3 ltxml 1.1 GIMP mySQL (in progress) X11 vnc-3.3.3r2

    22. Linux/390 in Action

    23. Linux/390 in Action There are three things of note on this screenshot: Emacs in action on an X-windows session The version shown at the bottom of the screen The results of the PostgreSQL-6.5.3 regression testThere are three things of note on this screenshot: Emacs in action on an X-windows session The version shown at the bottom of the screen The results of the PostgreSQL-6.5.3 regression test

    24. Linux/390 in Action Linuxconf is available to the system administrator to use as they could on any platform.Linuxconf is available to the system administrator to use as they could on any platform.

    25. Linux/390 in Action Samba is up and running and may be configured by swat.Samba is up and running and may be configured by swat.

    26. Linux/390 in Action This screenshot shows the contents of the /proc/cpuinfo file which shows that we have 3 processors and the vendor is IBM. Note the bogomips figures. Small aren’t they? Why? Because this instance of Linux has been capped on the Princeton University system which it shares with 300 other users including two very resource hungry OS/390 systems. Using VM we could redirect more resources to Linux should it be desired or we can constrain it even further. Most of these changes can be done dynamically without taking VM or Linux down.This screenshot shows the contents of the /proc/cpuinfo file which shows that we have 3 processors and the vendor is IBM. Note the bogomips figures. Small aren’t they? Why? Because this instance of Linux has been capped on the Princeton University system which it shares with 300 other users including two very resource hungry OS/390 systems. Using VM we could redirect more resources to Linux should it be desired or we can constrain it even further. Most of these changes can be done dynamically without taking VM or Linux down.

    27. Linux/390 in Action The things to note in the /proc/devices file is the “cpint” device which is the interface to VM/ESA (i.e. the BIOS) and the “mnd” device which is a VM virtual or mini disk (effectively a subset of a real disk which Linux sees as an wholed device).The things to note in the /proc/devices file is the “cpint” device which is the interface to VM/ESA (i.e. the BIOS) and the “mnd” device which is a VM virtual or mini disk (effectively a subset of a real disk which Linux sees as an wholed device).

    28. Linux/390 in Action

    29. Linux/390 Virtual Penguin Power As people got Linux up and running under their VM/ESA systems it quickly came clear that a whole new level of virtualization was possible. This time it was a virtual server farm which Richard Higson dubbed “MVL” for Multiple Virtual Linux and subsequently “Virtual Penguin Power”.As people got Linux up and running under their VM/ESA systems it quickly came clear that a whole new level of virtualization was possible. This time it was a virtual server farm which Richard Higson dubbed “MVL” for Multiple Virtual Linux and subsequently “Virtual Penguin Power”.

    30. Multiple Virtual Linux Instead of a box per server connected by metres of wire A virtual machine per server connected by storage sharing data at 500MB/s DASD may be shared DASD may be located 43Km away “Virtual Penguin Power” One of the exciting possibilities with Linux/390 (apart from Consider the typical “server farm”: One application per box Connected by metres of cable Dedicated DASD only Now consider a “virtual server farm”: One application per virtual machine Connected by storage that allows the sharing of data at 500MB/s Dedicated or shared DASD We’ve dubbed the possibility as the “Virtual Penguin Project”.One of the exciting possibilities with Linux/390 (apart from Consider the typical “server farm”: One application per box Connected by metres of cable Dedicated DASD only Now consider a “virtual server farm”: One application per virtual machine Connected by storage that allows the sharing of data at 500MB/s Dedicated or shared DASD We’ve dubbed the possibility as the “Virtual Penguin Project”.

    31. VPP VM is another device Linux can talk to Huge data cache Resource sharing and capping Need a new server? Just spend 5 minutes and add a new virtual machine Error recovery and reporting Under the VPP VM is another device Linux can talk to (just like talking to BIOS): /dev/cpcmd - execute VM commands and have the results returned to Linux /dev/applmon - write performance monitor data to the system VM has advanced data handling techniques. S/390 is very good at moving data. VM is able to maintain large caches of data in storage or in the caches of the DASD controllers without Linux having to worry about it. This can be tailored on a virtual machine basis. Because devices are “virtual” they can be moved around without disruption. CPUs could be added and removed simply by changing definition files. Virtual DASD can be moved from one real device to another (or can be truly virtual and exist in storage only). VM is able to differentially share the resources of the real machine to the virtual machine and even cap resource usage. For example, if a bureau service was running a virtual machine (a virtual penguin) on behalf of a customer resource levels could be defined and enforced. Say you need a new server? No need to source more hardware just define a new virtual machine with a copy of the virtual resources required. Error recovery of the real resources can be left to VM if required, it’s the choice of the system administrator. Flexibility is the catchcry.Under the VPP VM is another device Linux can talk to (just like talking to BIOS): /dev/cpcmd - execute VM commands and have the results returned to Linux /dev/applmon - write performance monitor data to the system VM has advanced data handling techniques. S/390 is very good at moving data. VM is able to maintain large caches of data in storage or in the caches of the DASD controllers without Linux having to worry about it. This can be tailored on a virtual machine basis. Because devices are “virtual” they can be moved around without disruption. CPUs could be added and removed simply by changing definition files. Virtual DASD can be moved from one real device to another (or can be truly virtual and exist in storage only). VM is able to differentially share the resources of the real machine to the virtual machine and even cap resource usage. For example, if a bureau service was running a virtual machine (a virtual penguin) on behalf of a customer resource levels could be defined and enforced. Say you need a new server? No need to source more hardware just define a new virtual machine with a copy of the virtual resources required. Error recovery of the real resources can be left to VM if required, it’s the choice of the system administrator. Flexibility is the catchcry.

    32. VPP in Action Tests conducted by David Boyes G5 processor with 2 real CPUs 2750 Linux/390 virtual machines 1000 with 4 vCPUs 500 with 2 vCPUs 250 with 8 vCPUs Booted concurrently Running Apache serving same page VM didn’t bat an eyelid David Boyes of Dimension Enterprises in Virginia has begun testing the boundaries of VPP. The box was a VM/ESA 2.3 system running in a 128M 2 CPU LPAR. A master Linux copy was built and configured NFS export for /usr and /bin. /usr and /bin were separated on to separate minidisk volumes and mounted during boot. A few lines of scripting were written to create a set of VM directory entries with a writable root partition and a small swap and /var partition and the /usr and /bin directories r/o from the master system, then copied the minidisks containing the root and swap from the master system over to the newly created disks. Some ugly Bourne shell stuff was written to mount the /usr and /bin partitions during rc.boot processing. The thing then mounts /var and /home from the master system, and you're off. There's a driver exec on the VM side that does the VM TCP manipulation. The customer wants their identity hidden at the moment, but the data can be used elsewhere. The whole complex (all 2750 images) boots in a little under 11 minutes. Rick Troth's webcat utility was used to test the WWW page retrieval. David Boyes of Dimension Enterprises in Virginia has begun testing the boundaries of VPP. The box was a VM/ESA 2.3 system running in a 128M 2 CPU LPAR. A master Linux copy was built and configured NFS export for /usr and /bin. /usr and /bin were separated on to separate minidisk volumes and mounted during boot. A few lines of scripting were written to create a set of VM directory entries with a writable root partition and a small swap and /var partition and the /usr and /bin directories r/o from the master system, then copied the minidisks containing the root and swap from the master system over to the newly created disks. Some ugly Bourne shell stuff was written to mount the /usr and /bin partitions during rc.boot processing. The thing then mounts /var and /home from the master system, and you're off. There's a driver exec on the VM side that does the VM TCP manipulation. The customer wants their identity hidden at the moment, but the data can be used elsewhere. The whole complex (all 2750 images) boots in a little under 11 minutes. Rick Troth's webcat utility was used to test the WWW page retrieval.

    33. Some Final Words

    34. Further Information http://penguinvm.princeton.edu http://linux390.marist.edu http://linas.org/linux/i370.html http://www.ibm.com/s390/vm/linux/ http://www.ibm.com/developer/opensource/ http://www.funsoft.com

    35. Trademarks Linux is a trademark of Linus Torvalds S/390, VM/ESA, OS/390, VSE/ESA, AIX are trademarks of IBM UTS is a trademark of Amdahl OSIRIS is a trademark of HDS Flex-ES is a trademark of Fundamental Software Inc.

More Related