Post on 05-Dec-2014
description
Riggs 1
The Virtual Machine
Submitted by: Matthew Riggs
Submitted to: Dr. E. Durant
Date Submitted: 1 February 2006
Riggs 2
Table of Contents
Introduction........................................................................................................................3
The Beginnings of the IBM Virtual Machine...............................................................4
The Beginning of the Java Virtual Machine.................................................................5
The Portable Virtual Machine: The Java Virtual Machine.........................................7
The Multiple Workstation System: The VMware Virtual Machine..........................9
Conclusion.........................................................................................................................12
Appendix of Illustrations...................................................................................................14
References..........................................................................................................................15
Riggs 3
Introduction
The term ‘virtual machine’ represents multiple products, each developed for
different reasons and during different times. The aspect that ties these different
technologies together under one title is the same goal: to seamlessly emulate a
completely different machine or function [4]. There are two completely different
technologies under the label of ‘virtual machine’: the IBM model, and the Java
model. Both of these models were developed for a different reason and at a
different time.
Figure 1: Some technologies under the virtual machine. Each with a different use
and method of achieving them, the general theme can be seen here as the
emulation of something that is not present. The IBM model shows each client a
whole and dedicated system, the Java model shows the code a Java operating
system, and the OSI model shows a series of drives where physically only one
drive exists.
Riggs 4
The Java virtual machine enables Java code to run on nearly any machine. The
Java code only sees a completely compatible operating system to run on; the Java
platform handles the Java code to host OS translation. The IBM virtual machine
concentrates on a different form of emulation, allowing multiple users to access
their own ‘desktop’, a secure duplicate of other desktops running on the virtual
machine. These technologies are still developing, and have drawbacks compared
to other alternatives. An IBM model has a much higher resource demand than a
stand-alone system, and this can easily outweigh the gain of its ability to satisfy
multiple users. The Java virtual machine does not solve all of its portability
demands, losing to the tried-and-true method of recoding based on the targeted
platform. Virtual machines are continuously changing, and the ideas behind them
are being applied to a wide variety of fields, accomplishing a multitude of tasks
less expensively and more conveniently.
The Beginnings of the IBM Virtual Machine
The first computer to be classified as a virtual machine was built on IBM’s S/360
model 67 in 1967 [5], [6]. This S/360 model was an important step for IBM, who
was beginning to lag behind the academic community because of IBM’s strongly
held belief that faster batch processing was the correct technology to pursue [5].
MIT, who had been developing ‘time-sharing’ or multiprocessing, had begun to
turn from its nearly exclusive partnership with IBM, as IBM released the first
S/360 model without the ability to perform time-sharing [5], [6]. The S/360
model 67 was the platform on which the CP-40 ran, the first incarnation of the
virtual machine (among other important technologies). The CP-40 was developed
Riggs 5
as a research project by IBM’s Cambridge laboratory, because after the S/360/67
was built and being produced, the time-sharing aspect was being developed as
TSS in IBM’s New York State location [5], leaving the Cambridge lab to work
abstractly. The virtual machine’s (originally called pseudo machine [5]) purpose
was to provide security to each of the users of the CP-40. That there were
multiple users of the same system was an innovation in itself, although the
number of users was limited to 14, and the memory usage of each limited to
256 k [5]. Before the CP-40, a time-sharing system would have a virtual
platform, which appeared to the user to be more powerful than the system
actually was [6].
The CP-40, on the other hand, gave each user their own virtual S/360, with their
‘own’ drives and processing ability. This was accomplished using P-disks
(seamlessly managed partitions of a single physical drive), which is now
considered to be an offshoot of the virtual machines idea, called the ‘OSI’ model.
One of the most important aspects of the CP-40’s virtual machine function was
that it showed how “elegantly a virtual machine system could be built, with
really very minor hardware changes and not much software [6]”. The SP-40’s
virtual machine implementation was fully realized in the Cambridge Monitor
System, or CMS, which allowed the SP-40’s users to operate as separate and
secure S/360 platforms.
Riggs 6
The Beginning of the Java Virtual Machine
The Java Virtual Machine (JVM) has little to do with the original virtual
machine, except in the essence of the end result. The idea of the Java
programming language (the basis on which the JVM works) started in 1970 in the
mind of Bill Joy, co-founder of Sun. That idea did not come to fruition until the
1990s, when Sun began to looking into the focused development of its products
and the portability that would be required [4]. The language which the JVM runs
is Java, which was once Oak, an offshoot of C++ written by James Gosling
during the time when Bill Joy was publishing his ideas for the JVM in the paper
Further, became the basis for the JVM to run because of its simplified and
streamlined designed comparative to C++ or C. Java supplied Sun with what it
was searching for: concise code.
This was only a part of the equation to attain easy portability, as the Java code
was still platform specific (the Java code would still require OS tailoring, as in
Windows or Linux or Mac, all possessing different instruction sets). The JVM
was the end result of this need for a platform independent design. Small and
efficient, the JVM was designed as to be a virtual machine in that it provides
another layer of coding and decoding between the processor and the user. The
JVM provides two things to the Java code developed by Sun: portability, as the
JVM’s purpose is to translate the Java compiled code into platform-usable
instructions, and programming simplicity, as the code remains basic and
unchanged regardless of the platform.
Riggs 7
The Portable Virtual Machine: The Java Virtual Machine
The Java Virtual Machine has one focus: to make Java programs (and Sun’s
products) more portable. This is accomplished in a way that emulates the very
first computer systems: a virtual machine image is presented to both sides of the
computer application equation (F1) [8].
Figure 2. The JVM ‘layer’ approach. This shows how the data flows, and what
both the host operating system and the application see. The application sees a
compatible Java operating system, and the operating sees a flow of usable
instructions.
The code sees a perfectly compatible Java machine that is capable of handling
the compiled code without translational or operational errors. The platform the
code is running on also sees what it wants to see, instructions that are tailored to
the platform’s operating system so there are no misunderstandings, and no errors
to handle. The end result is extremely portable code written in Java [5]. The
Riggs 8
VMSpec, provided by Sun for use with its JVM, takes an in-depth, item-by-item
approach to explaining the operation of the Java Virtual Machine [9]. Java (the
programming language) is usually compiled into a class file, which provides the
JVM with generic coding information. “Compiled code to be executed by the
Java virtual machine is represented using a hardware- and operating system-
independent binary format, typically (but not necessarily) stored in a file, known
as the class file format [9].” The class file is simply a list of bytecodes compiled
from the original Java programming language description. The JVM then takes
these bytecodes and translates them into basic instructions. At this point the JVM
is looking at the assembly code, and similar to MIPS architectural equations, it
follows the very basic format of , so on. The JVM
knows to expect these operands based on the opcode given [8]. Although this
may seem unsafe to depend on the opcode to determine the number or existence
of operands, the Java code has already been compiled, and as such will not cause
a real-time fault as long as the content of the basic operations is sound.
At this point, the JVM can translate the basic instructions into short commands to
the operating system. From a programming flow point of view, the Java language
is set up so that the assembling of the Java code is done dynamically, at the
platform the code is to be executed on, allowing the JVM, in this case the
assembler, to tailor the assembled code to suit the operating system and there-by
create compatible code.
Riggs 9
To be appealing to consumers, the JVM needed to be compact, and this was
achieved at the cost of a few compatibility choices. An example of a noticeable
decision to preserve the brevity of the JVM (and the compiled Java code) is the
decision to use one byte long opcode [9]. “The decision to limit the Java virtual
machine opcode to a byte and to forgo data alignment within compiled code
reflects a conscious bias in favor of compactness, possibly at the cost of some
performance in naive implementations [9].”
The Multiple Workstation System: The VMware Virtual Machine
IBM’s Cambridge office developed the virtual machine, opening up a new world
of computing solutions that are still entirely viable today. Cambridge’s invention
also allowed IBM to diversify itself, an opportunity which IBM took and still
uses to its advantage. IBM moved away from the workstation side of the virtual
machine and began to concentrate on virtual servers, which were a higher-end
business commodity, not so subject to public knowledge or popularity. The
‘workstation’ virtual machine did not stop there, however, and several companies
took up the technology, adding different tweaks to it along the way.
VMware developed a virtual machine platform that isn’t standalone like the IBM
VM. The VMware model runs as an application on the host OS (called the hosted
virtual machine model [10]), allowing a less computer savvy user to create
virtual machines easily. This OS-based operation is achieved using a series of
protections that is in common use in operating systems and is based closely on
Riggs 10
the Intel IA32 architecture, which provides 4 levels of protection (see Figure 3)
[10].
Figure 3. This a protection scheme used by Intel, and is useful to explain how the
VMware virtual machine integrates itself so that it can successfully run multiple
clients.
A normal operating system will have the most sensitive operations available to it
in Level 0, such as interrupt handling [10]. When VMware is applied to this
system, it must have access to all levels of the protection scheme. This is
accomplished by 3 distinct parts, the VMware driver, the VMware monitor, and
the VMware application. The VMware driver and monitor sit in Level 0,
allowing unrestricted access to instructions. The VMware application sits in
Level 1, and acts as a go-between for the operating system, which sees it as just
another application, without any special privileges. Using this underlying
framework, virtual machines can finally be created. There is an obvious
Riggs 11
drawback to this system, and it becomes evident that the host OS approach can
greatly affect performance.
The VMware driver can access interrupt handling and other sensitive operations,
however it is unable to perform scheduling, which means that any of the client
virtual machines are not only playing second fiddle to the host OS’s concerns,
they could be interrupted during a critical section, and the OS might not realize.
This issue becomes apparent in today’s virtual machine systems during periods
of heavy I/O reliance, as the I/O system becomes a bottleneck. The VM monitor
can use the OSI model to partition the host workstation’s resources, but the I/O
waits cannot be partitioned or ignored. The worst bogging experience is during
network operations; however VMware has come to handle this, cutting down on
the performance hit the clients experience during network communications. The
VM application ‘reads’ what I/O operations each client is initiating, and
summarizes them, cutting down on the time each client requires the I/O devices.
This sounds like it would cause packet and data loss, however, as redundancy is
reduced and status checks are ignored, the VM application keeps tabs, and if the
client begins to falter, it can restore the original request for I/O use, so that the
client users are still able to complete tasks.
Another potential drawback is the protection and security aspect of the client
virtual machines, in respect to each other as well as to outside influences. This
problem was, even in the IBM CP-40’s day, handled with great care. With the
Riggs 12
VMware system, interrupts are utilized to outright stop a client from tampering
with another. The VMware monitor runs an algorithm to determine the intent of
the instruction (flagged by the driver as potentially sensitive), and either allows a
harmless one, or does not run the instruction. This approach is brute force and
unforgiving, any application that a client user is running will likely find it’s way
into error because of the VMware driver’s actions. The problem with this is that
the algorithm used to determine the intent of the client’s instruction has to be
inscrutable, to the point that it needs to understand all of the possible ways a
client to client security breach can occur. Computer security has grown in recent
years, and has become an ever changing industry. VMware (and IBM with their
virtual server application) has come to develop a kit or packet of algorithms,
which have seen updates every time a product update is produced.
ConclusionVirtual machines, ever since their invention, have come to be a widely sought-
after alternative to the workstation or single-server route. Drawbacks, as with
every choice between competing options has, still plague parts of the virtual
machine technology. As the processes and methods used to provide the
functionality of the virtual machine is refined and reworked, a sudden and
advance change in the way computers are used could occur.
An optimist could envision consumers buying or renting a share in a virtual
machine stored miles away, saving the consumer the cost of the hardware and
repair. An entrepreneur could see virtual machines being used to monitor patients
Riggs 13
in hospitals, the data waiting patiently, stored in a system until that patient was
again hooked into the system. Any who investigates the market will see the vast
potentials which are available to the virtual machine industry, and seem about
ready to appear. As it is now, the virtual machines are a smart and generally safe
alternative to the stand-alone systems popular today as personal computers. Their
value in today’s market is undeniable.
Riggs 14
Appendix of Illustrations
Figure 1…………………………………………………………………page 3
Figure 2…………………………………………………………………page 7
Figure 3…………………………………………………………………page 10
Riggs 15
References
Baratz, Adam. “Virtual Machine shootout: VMware vs. Virtual PC.” Ars Technica. 8 August 2004. arstechnica.com. 9 January 2006 <http://arstechnica.com/reviews/apps/vm.ars/1> [1]
Lindholm, Tim and Frank Yellin. “The Java Virtual Machine Specification: Second Edition.” Sun Microsystems. 1999. Sun Microsystems. 9 January 2006 <http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html> [2]
Haldar, Vivek, et al. Semantic Remote Attestation-A Directed Approach to Trusted Computing. usenix.org. 2004. Usenix. 9 January 2006 <http://www.usenix.org/events/vm04/tech/haldar/haldar.pdf> [3]
Kohlbrenner, Erik, et al. “The History of Virtual Machines.” Hyperlearning Center. 1999. cne.gmu.edu. 9 January 2006<http://www.cne.gmu.edu/itcore/virtualmachine/index.htm> [4]
Varian, Melinda. VM and the VM community: Past, Present, and Future. Princeton University. 1997. princeton.edu. 10 January 2006 <http://www.princeton.edu/~melinda/ 25paper.pdf> [5]
Van Vleck, Tom. “The IBM 360/76 and CP/CMS.” Multicians. 30 December 2005. multicians.org. 10 January 2006 <http://www.multicians.org/thvv/360-67.html> [6]
Venners, Bill. “The Lean, Mean, Virtual Machine.” JavaWorld. 2005. javaworld.com. 22 January 2006 <http://www.javaworld.com/javaworld/jw-06-1996/jw-06-vm.html> [7]
“Virtual Machines and VMware, Part I” Ziff Davis, Inc. 2005. extremetech.com. 28 January 2006 <http://www.extremetech.com/article2/0,1697,1156610,00.asp> [8]