Randall Shimizu([EMAIL PROTECTED])@Sat, Oct 22, 2005 at 02:54:19PM -0800: > There seemed to be a lot of confusion regarding the functiona > definiton of a hypervisor so I will elucidate: > > Hypervisor: (http://en.wikipedia.org/wiki/Hypervisor )A > hypervisors main function is manage different VM's. Hypersvisors > is also responsible for the instantiation and termination of a > VM. Now there is both a software and hardware based hypervisor. > VMware and IBM's DLPAR (Dynamic logical partitioning) technoogy > are both of this iteration. The hardware based hypervisor is it's > own OS. This allows the system to remain up even if the other > VM's crash. IBM"s has had hardware hypervisors ever since the > introduction of S/390.
I had to read that a couple of times. The last statement is misleading. S/390 is the previous line of mainframe systems from IBM. That is, I think, the first version that could create LPARs. That is, the hardware could be partitioned up to 15(?) ways. The technology that allows that is called: PR/SM (Processor Resource/System Manager). It is tempting to simply say that this is just a harware hypervisor by another name, but I don't think that is accurate because the main reason for its existence is to isolate the hardware resources. So, what you have is a very strictly divided system. Clearly there is some system virtualisation going on, but I don't think that's all there is to a hypervisor. I'm not sure why you would think that this hardware capability constitutes its own OS. > > DLPAR is highly advance load balancing VM technology on IBM's > Power and PPC platforms. DLPAR has the ability start or end new > VM's as the systems requirements is changing. > > VM technoogy is not a new technology at least for IBM Z-Series. > IBM"s MVS (Multiple Virtual Systems) refers to multiple VM's > running multiple instances of S/390. MVS *really* stands for "Multiple Virtual Storage". The name existed before LPAR functionality, and was first used to refer to OS/370. The S/360 was able to address a whopping 16MB of central storage (memory, in mainframe jargon). The OS/370 saw that increase to 64MB, but that was only the half of it. It also included a hardware feature that translated the address space for each of the programs that were running (there was a limit of 15 concurrent programs). Each running program actually was swapped out to DASD (hard disk) and each one "thought" it had the run of "all 16 MB", because it had its own addressable virtual storage. Hence the name. S/390 refers to hardware, while OS/390 refers to one of the IBM operating systems that runs on it. The current hardware is called z/Series, and the OS is z/OS (all 64-bit, and still called MVS most of the time). The other mainframe OS that hasn't been mentioned is z/VM. That one has a hypervisor. > But beyond all this the > S/390 can run simultaneous parallel trancations I'm not sure what you're getting at here. It sounds like you're talking about multitasking. You don't need a parallel sysplex for that. > (IBM parallel > sysplex: allows for clustered Z-series boxes) They can be kind of like clusters. Often times they are not like clusters so much. For example, all the LPARs I work on are part of some sysplex, but they remain mostly distinct. LPARs share the storage complex, and they can share processor cycles, too. Sometimes you'll see one LPAR usng 125% of it's processor cycles. This is because another LPAR in the sysplex gave some up for it to use. As far as I know, in clusters, you'd usually expect _processes_ to be shared rather than cpu cycles, so this is somewhat different. I am pretty sure this is done at a couple of different levels. Part of it may be done by JES2 (system software that controls the availability of resources and job execution--This is the software that you are talking to when you write JCL). > as well with full > rollback cability. Back to transactions. This is important in some areas of MVS software, but it isn't everywhere. IMS and CICS are two different (ubiquitous) ways to provide an application framework and the ability to connect. I'm more familiar with IMS, and it does have checkpointing plus copious logging of the transactions and all the resources and datasets (files) that were used. > So in other words a enterprise has not only > system fault tolerance, but application fault tolerance as well. > So it becomes clearer why so many forturne 500 enterprises still > run mainframes. Mainframes are much more popular than is widely known outside big business. I don't think stability is the main reason for the businesses' heavy reliance on them, though (although it is a factor). I believe it has to do with the fact mainframes have specific features that "pointy-hairs" and "bean-counters" love. Nearly every facet of mainframe system software is extremly modular, configurable, and customizable. Also, everything is logged. You think you have seen lots of logs in /var/log? You ain't seen nothing. Further, you can configure exactly what processes/jobs get what resources first at several levels. In a business where they are continually scrutinizing costs (licensing for each LPAR, CPU cycles, DASD disk space, ad nauseam) the logging, configurability and control is essential. MVS mainframes have a menu-driven user interface, a reliance on JCL, and a much less flexible end-user environment overall. On the other hand, *nix shines in its flexibility and user interface, IMO. It just wasn't developed with business in mind. Even the clusters that are being built now seem to me to be much more directed at research than business. The software that businesses rely on strongly to run their mainframes and applications are either just getting started, or are non-existent in the unix world. Just for the sake of completeness, z/VM (which I am not familiar with) started out as a skunk works project at IBM, and wasn't released until long after MVS. Besides being used as a regular OS, it provides a hypervisor and virtual machine capabilities in addition to what the hardware offers. It is the OS that is used when people set up linux server farms on a mainframe. It is also generally considered to be less stable than MVS by the folks I work with. I can't tell if that is a justifiable bias, or not. I hope that was clear, and interesting to at least one other person ;) Wade Curry syntaxman -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
