November 25, 2024, Monday, 329

Virtualization Development

From NeoWiki

(Difference between revisions)
Jump to: navigation, search
m (→References)
m (→Year 1970)
 
(One intermediate revision by one user not shown)
Line 63: Line 63:
  
 
=== Year 1960 ===
 
=== Year 1960 ===
−
;IBM CP-40|CP/CMS|History of CP/CMS|IBM System/360-67
+
 
 
In the mid 1960s, IBM's [[Cambridge Scientific Center]] developed [[IBM CP-40|CP-40]], the first version of [[CP/CMS]]. It went into production use in January 1967. From its inception, [[IBM CP-40|CP-40]] was intended to implement [[full virtualization]]. Doing so required hardware and microcode customization on a S/360-40, to provide the necessary address translation and other virtualization features. Experience on the [[IBM CP-40|CP-40]] project provided input to the development of the [[IBM System/360-67]], announced in 1965 (along with its ill-starred operating system, [[TSS/360]]). [[IBM CP-40|CP-40]] was reimplemented for the S/360-67 as CP-67, and by April 1967, both versions were in daily production use. [[CP/CMS]] was made generally available to IBM customers in source code form, as part of the unsupported [[IBM Type-III Library]], in 1968.
 
In the mid 1960s, IBM's [[Cambridge Scientific Center]] developed [[IBM CP-40|CP-40]], the first version of [[CP/CMS]]. It went into production use in January 1967. From its inception, [[IBM CP-40|CP-40]] was intended to implement [[full virtualization]]. Doing so required hardware and microcode customization on a S/360-40, to provide the necessary address translation and other virtualization features. Experience on the [[IBM CP-40|CP-40]] project provided input to the development of the [[IBM System/360-67]], announced in 1965 (along with its ill-starred operating system, [[TSS/360]]). [[IBM CP-40|CP-40]] was reimplemented for the S/360-67 as CP-67, and by April 1967, both versions were in daily production use. [[CP/CMS]] was made generally available to IBM customers in source code form, as part of the unsupported [[IBM Type-III Library]], in 1968.
  
 
=== Year 1970 ===
 
=== Year 1970 ===
−
;System/370|VM (operating system)|History of CP/CMS|hypervisor
+
 
 
IBM announced the [[System/370]] in 1970. To the disappointment of [[CP/CMS]] users – as with the [[System/360]] announcement – the series would not include [[virtual memory]]. In 1972, IBM changed direction, announcing that the option would be made available on all S/370 models, and also announcing several virtual storage operating systems, including [[VM (operating system)|VM/370]]. By the mid-1970s, [[CP/CMS]], VM, and the maverick [[VP/CSS]] were running on a numerous large IBM mainframes. By the late 80s, there were reported to be more VM licenses than [[MVS]] licenses.
 
IBM announced the [[System/370]] in 1970. To the disappointment of [[CP/CMS]] users – as with the [[System/360]] announcement – the series would not include [[virtual memory]]. In 1972, IBM changed direction, announcing that the option would be made available on all S/370 models, and also announcing several virtual storage operating systems, including [[VM (operating system)|VM/370]]. By the mid-1970s, [[CP/CMS]], VM, and the maverick [[VP/CSS]] were running on a numerous large IBM mainframes. By the late 80s, there were reported to be more VM licenses than [[MVS]] licenses.
  

Latest revision as of 16:50, 5 March 2007

Contents

Timelines

Note: This timeline is missing data for important historical systems, including: Atlas Computer (Manchester), GE 645, Burroughs B5000

  • 1964
  • 1965
  • 1966
    • IBM ships the S/360-67 computer in June 1966
    • IBM begins work on CP-67, a reimplementation of CP-40 for the S/360-67.
  • 1967
    • CP-40 (January) and CP-67 (April) go into production time-sharing use.
  • 1968
  • 1970
    • IBM System/370 announced (June) – without virtual memory.
    • Work begins on CP-370, a complete reimplementation of CP-67, for use on the System/370 series.
  • 1971
  • 1972
    • Announcement of virtual memory added to System/370 series.
    • VM/370 announced – and running on announcement date. VM/370 includes the ability to run VM under VM (previously implemented both at IBM and at user sites under CP/CMS, but not made part of standard releases).
  • 1973
    • First shipment of announced virtual memory S/370 models (April: -158, May: -168).
  • 1974-1998
    • [ongoing history of VM family and VP/CSS.]
  • 1988
    • SoftPC 1.0 for Sun was introduced in 1988 by Insignia Solutions [1]
    • SoftPC appears in its first version for Apple Macintosh. These versions (Sun and Macintosh) have only support for DOS.
  • 1997
  • 1998
    • October 26, 1998, VMWare filed for a patent on their techniques, which is granted as U.S. Patent 6,397,242 [2]
  • 1999
    • February 8, 1999, VMware introduced VMware Virtual Platform for the Intel IA-32 architecture.
  • 2000
  • 2001
    • June, Connectix launchs its first version of Virtual PC for Windows.[3]
    • July, VMWare created the first x86 server virtualization product.[4]
  • 2003
    • February 18, 2003, Microsoft acquired virtualization technologies (Virtual PC and unreleased product called "Virtual Server") from Connectix Corporation. [5]
    • Late 2003, EMC acquired VMware for $635 million.
    • Late 2003, VERITAS acquired Ejascent for $59 million.
    • November 10, 2003 Microsoft releases Microsoft Virtual PC, which is machine-level virtualization technology, to ease the transition to Windows XP.
  • 2005
  • 2006
  • 2007
    • January 15, 2007 InnoTek released VirtualBox Open Source Edition (OSE), the first professional PC virtualization solution released as open source under the GNU General Public License (GPL).

Year 1960

In the mid 1960s, IBM's Cambridge Scientific Center developed CP-40, the first version of CP/CMS. It went into production use in January 1967. From its inception, CP-40 was intended to implement full virtualization. Doing so required hardware and microcode customization on a S/360-40, to provide the necessary address translation and other virtualization features. Experience on the CP-40 project provided input to the development of the IBM System/360-67, announced in 1965 (along with its ill-starred operating system, TSS/360). CP-40 was reimplemented for the S/360-67 as CP-67, and by April 1967, both versions were in daily production use. CP/CMS was made generally available to IBM customers in source code form, as part of the unsupported IBM Type-III Library, in 1968.

Year 1970

IBM announced the System/370 in 1970. To the disappointment of CP/CMS users – as with the System/360 announcement – the series would not include virtual memory. In 1972, IBM changed direction, announcing that the option would be made available on all S/370 models, and also announcing several virtual storage operating systems, including VM/370. By the mid-1970s, CP/CMS, VM, and the maverick VP/CSS were running on a numerous large IBM mainframes. By the late 80s, there were reported to be more VM licenses than MVS licenses.

Year 1999

Virtualization Technology

On February 8, 1999, VMware introduced the first x86 virtualization product, "VMware Virtual Platform", based on earlier research by its founders at Stanford University.

Year 2005

Free desktop virtualization

Previously, a substantial licensing fee was required for the use of VMWare's Workstation product. VMWare decided to provide high quality virtualization technology to everyone for free. They omitted the ability to create virtual machines and did not distribute the acceleration tools that come with VMWare workstation. This early corporate play to encourage consumer applications of virtualization went largely unnoticed.

Year 2006

This year Virtualization has a new level of playing field in Application Virtualization and Application Streaming.

Overview

As an overview, there are three levels of Software Virtualizations:

  • At the Hardware Level , the VMs can run multiple guest OSes. This is best used for testing and training that require networking interoperability between more than one OSes, since not only the guest OS can be different than the host OS, it can run as many guest OS as long as there is enough CPU, RAM and HDD space.
  • At the Operating System Level, it can only virtualize one OS: the guest OS is the host OS. This is similar to having many terminal server sessions without locking down the desktop. Thus, this is the best of both world, having the speed of a TS session with the benefit of a full access to the desktop as virtual machine, where the user can still control the quotas for CPU, RAM and HDD. Similar to the hardware level, this is still consider a Server Virtualization where each guest OS has its own IP address, so it can be used for networking applications such as for web hosting.
  • At the Application Level, it is running on the Host OS directly, without any guest OS, which can be in a locked down desktop, including in a terminal server session. This is called Application Virtualization or Desktop Virtualization, which virtualizes the front-end, whereas Server Virtualization virtualizes the back-end. Now, Application Streaming refers to delivering applications directly onto the desktop and runing them locally. Traditionally in terminal server computing, the applications are running on the server, not locally, and streaming the screenshots onto the desktop.

Application virtualization

Application Virtualization solutions such as Thinstall, Softricity, and Trigence attempt to separate application specific files and settings from the host operating system, thus allowing them to run in more-or-less isolated sandboxes without installation and without the memory and disk overhead of full machine virtualization. Application Virtualization is tightly tied to the host OS and thus does not translate to other operating systems or hardware. Thinstall and Softricity are Intel Windows centric, while Trigence supports Linux and Solaris. Unlike machine virtualization, Application virtualization does not use code emulation or translation so CPU related benchmarks run with no changes, though fileystem benchmarks may experience some performance degradation. On Windows, Thinstall and Softricity essentially work by intercepting filesystem and registry requests by an application and redirecting those requests to a preinstalled isolated sandbox, thus allowing the application to run without installation or changes to the local PC. Though Thinstall and Softricity both began independent development around 1998, behind the scenes Thinstall and Softricity are implemented using different techniques:

  • Thinstall works by packaging an application into a single EXE which includes the runtime plus the application data files and registry. Thinstall’s runtime is loaded by Windows as a normal Windows application, from there the runtime replaces the Windows loader, filesystem, and registry for the target application and presents a merged image of the host PC as if the application had been previously installed. Thinstall replaces all related API functions for the host application, for example the ReadFile API supplied to the application must pass through Thinstall before it reaches the operating system. If the application is reading a virtual file, Thinstall handles the request itself otherwise the request will be passed on to the operating system. Because Thinstall is implemented in user-mode without device drivers and it does not have a client that is preinstalled, applications can run directly from USB Flash or network shares without previously needing elevated security privileges.
  • Softricity (acquired by Microsoft) operates on a similar principle using device drivers to intercept file request in ring0 at a level closer to the operating system. Softricity installs a client in Administrator mode which can then be accessed by restricted users on the machine. An advantage of virtualizing at the kernel level is the Windows Loader (responsible for loading EXE and DLL files) does not need to be reimplemented and greater application compatibility can be achieved with less work (Softricity claims to support most major applications). A disadvantage for ring0 implementation is it requires elevated security privileges to be installed and crashes or security defects can occur system wide rather than being isolated to a specific application.

Because Application Virtualization runs all application code natively, it can only provide security guarantees as strong as the host OS is able to provide. Unlike full machine virtualization, Application virtualization solutions currently do not work with device drivers and other code that runs at ring0 such as virus scanners. These special applications must be installed normally on the host PC in order to function.

Managed runtimes

Another technique sometimes referred to as virtualization, is portable byte code execution using a standard portable native runtime (aka Managed Runtimes). The two most popular solutions today include Java and .NET. These solutions both use a process called JIT (Just in time) compilation to translate code from a fictional portable machine language into the local processor’s native code. This allows applications to be compiled for a single architecture and then run on many different machines. Beyond machine portable applications, an additional advantage to this technique includes strong security guarantees. Because all native application code is generated by the controlling environment, it can be checked for correctness (possible security exploits) prior to execution. Programs must be originally designed for the environment in question or manually rewritten and recompiled to work for these new environments. For example, one cannot automatically convert or run a Windows / Linux native app on .NET or Java. Because portable runtimes try to present a common API for applications for a wide variety of hardware, applications are less able to take advantage of OS specific features. Portable application environments also have higher memory and CPU overheads than optimized native applications, but these overheads are much smaller compared with full machine virtualization. Portable Byte Code environments such as Java have become very popular on the server where a wide variety of hardware exist and the set of OS-specific APIs required is standard across most Unix and Windows flavors. Another popular feature among managed runtimes is garbage collection, which automatically detects unused data and reclaims it without the developer having to explicitly invoke free operations.

Neutral view of application virtualization

Given the industry-biased in the past, to be more neutral, there are also two other ways to look at the Application Level:

  • The first type is application packagers (Thinstall, Softricity) whereas the other is application compilers (Java and Dot Net). Because it is a packager, it can be used to stream applications without modifying the source code, where as the later can only be used to compile the source code.
  • Another way to look at is through the Hypervisor point of view. The first one is "hypervisor" in user mode, where as the other is "hypervisor" in runtime mode. The hypervisor was put in quotation, because both of them have similar behavior in that it intercept system calls in different mode: user mode and runtime mode. The user mode intercepts the system calls from the runtime mode before going to kernel mode. The real hypervisor only need to intercept the system call using hypercall in kernel mode. Hopefully, once Windows have a Hypervisor, Virtual machine monitor, there may even be no need for JRE and CLR. Moreover, in Linux case, maybe the JRE can be modified to run on top of the Hypervisor as a loadable kernel module running in kernel mode, instead of the having the legacy runtime turtling around, running really slowly, in user mode. Now, if it were running on top of the Linux Hypervisor directly, then it should be called Java OS, not just another runtime mode JIT.
  • Mendel Rosenblum[1] called the runtime mode as High-level language virtual machines in August 2004. However, at that time, the first type, intercepting system calls in user mode, was irresponsible and unthinkable, so he didn't mention it on his article. Hence, Application Streaming was still mysterious in 2004[2]. Now, when the JVM, no longer High-level language virtual machines, becomes Java OS running on Linux Hypervisor, then Java Applications will have a new level of playing field, just as Windows Applications already has with Softricity.
  • In summary, the first one is virtualizing the Binary Code so that it can be installed once and run anywhere, whereas the other is virtualizing the Source Code using Byte code or Managed code so that it can be written once and run anywhere. Both of them are actually partial solution to portability problem: application portability and source code portability. Maybe it is time to combine the two problems into one complete solution at the hypervisor level in the kernel mode.

Further development

However, the mysterious Application Streaming will soon become very popular, because Microsoft had just bought Softricity on July 17, 2006. Because of this, Traditional Rich Windows Applications will have a new level of playing field with the Web Applications and the Java Applications with respect to the ease of distributions (i.e. no more setup required, just click and run). Soon the frowned-upon will become the cheered-upon as every JRE and CLR will just be running virtually on the user mode without kernel mode drivers being installed and updated such that there can even be multiple versions of JRE and CLR in HDD as well as in RAM.

Nevertheless, this frowned and cheered-upon Rootkit technique such as filter driver[3] maybe made obsolete once the Linux Hypervisor is integrated into the Linux Kernel and the Window Server Virtualization integrates the Windows Hypervisor with the Windows Kernel. This may take a while as the Linux Hypervisor are still waiting for the Xen Hypervisor and VMware Hypervisor to be fully compatible with each other as Oracle impatiently pounding at the door to let the Hypervisor come into the Linux Kernel so that it can full steam ahead with its Grid Computing life. Meanwhile, Microsoft have made their choice to be fully compatible with the Xen Hypervisor [6]. IBM, of course, doesn't just sit idle as it is working with VMware for the x86 servers, and possibly helping Xen to move from x86 into IBM's power using the open source rHype. Now, to make the Hypervisor party to become a full house, Intel's Vanderpool and AMD's Pacifica are hoping to ease and speed up paravirtualization so that guest OS can be run unmodified.


See also

External links


Cite error: <ref> tags exist, but no <references/> tag was found
Retrieved from "http://7thgen.info/wiki/Virtualization_Development"