« ZapThink links to mainframe blog. Harry Potter speaks | The Mainframe Blog Home | EBCDIC -vs- The World »
The Virtual Invasion
Virtualization is hot!
But don't take my word for it,
check out eWeek for November 7 (volume 22, number 44),
"The Rise of the Virtual Machines", with three articles of interest.
Confessions of a fanatic:
See my post about V12N a couple weeks back. I love VM!
It is comforting to read others affirming one's faith. Virtual machines
are way cool. We mainframers have known for decades.
But let's not sit here feeling vindicated.
There's still some confusion.
The phrase "virtual machine" is used for different things
with very different characteristics: virtual machines in the
Java sense, hardware emulators, paravirtualization (eg: Xen),
resource allocation with on-demand class response, and (my favorite)
virtual machines in the virtual memory sense. Even in the eWeek
article by Jason Brooks, there is some confusion about the abstracted
hardware layer. Let's be clear. (Then there are things called
"virtual" that do not even present a "machine", but most of those
thankfully don't claim to.) For the in-the-virtual-memory-sense
I suggest the term hypervisor.
A hypervisor is one step beyond a supervisor.
Where paravirtualization requires a polite and cooperative guest
and emulators impose performance burdens, the hypervisor makes
the underlying hardware transparent, executing guest op systems
on the physical machine until some exception calls for intervention.
VMware, MS Virtual Server, and z/VM are good examples of hypervisors.
The guest may be unable to detect the hypervisor, and in any case
requires no special re-coding.
Trying to group platforms and concepts ...
z/VM the original hypervisor, requires zSeries VMware PC hypervisor, requires INTeL or AMD and a host OS Virtual Server PC hypervisor, requires INTeL or AMD for Windows host OS FLEX-ES zSeries emulator (hosted on Linux, previously Dynix) Hercules zSeries emulator (open source, any of several host OS) BOCHS PC emulator (open source, any of several host OS) Xen paravirtualization, requires guest cooperation Virtuozzo "OS virtualization", does not present a machine JVM Java Virtual Machine, a misnomer, but popular
With BOCHS, you can run PC Linux on a SPARC running Solaris.
With Hercules, you can run mainframe Linux on an RS/6000 and AIX.
These are emulators.
With z/VM, you get multiple zSeries virtual machines
each running any desired zSeries operating system,
but you must have zSeries hardware.
With VMware, you get multiple PC virtual machines
each running any desired PC operating system,
but you must have PC hardware.
These are hypervisors, measurably more efficient than emulators.
Where it's really V12N, look for the hypervisor.
-- R;
| by sirsanta | November 17, 2005 Permalink |
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834521c8469e200e5507ddc3b8834
Listed below are links to weblogs that reference The Virtual Invasion:
Comments
I have to diagree with your definitions and comparisons of paravirutalization, hypervisors, and virtual machines.
For example, the IBM POWER4/POWER5's hypervisor paravirtualizes similar to Xen, in that it requires a modified client OS. IBM had an article (I think on developerworks) about booting PowerPC Linux on a prototype Regatta. It required changing the processor device driver and recompiling the kernel. It was a specialized client, as are AIX 5.1 and later.
Secondly, to call VMware a hypervisor is an extreme oversimplification. VMware emulates an entire x86 hardware platform. Certainly it does not emulate the entire actual processor (like VirtualPC on a Mac), it translates and passes through the native x86 instructions.
I believe the best definitions are the following:
Hypervisors fence devices and translate memory addresses. The underlying physical processor architecture is not modified in software. Hypervisors can be implemented in firmware (IBM Mainframe, IBM POWER4/POWER5), or in software (HP vPars, Xen). Yes, I consider paravirtualization solutions like vPars and Xen to be hypervisors because they are simple fencing and translating mechanisms. There is no supervising OS between a hypervisor and bare metal.
Virtual machines, on the other hand, create an entire virtual environment, and run on top of a supervising operating system.
I think the key difference is hypervisors are lighter weight, lower overhead, and allow less sharing of hardware resources. VMs are heavier weight and allow more sharing. A near perfect example of this is the emulation of networking VMware provides. The VMware ESX kernel (an OS in its own right), or the VMware GSX host, provides the low-level device driver. Then the VMware virtual machine provides an emulated device to the client OS, which uses its own compatible device driver. But even if there is no sharing, there is still a double device driver layer. The double device driver layer, and the emulated device, is what makes sharing possible. It also abstracts the underlying hardware to a level beyond a hypervisor, which is why one of the earliest uses of VMware Workstation was to run hard-coded DOS apps on Windows 2000.
Another area of sharing is VMware's ability to share memory. Hypervisors typically only fence and allocate memory.
Compare this to AIX 5.1 running on POWER4. Each client OS uses native (but well-behaved) device drivers and talks directly to underlying (but fenced) hardware.
IBM POWER5 microparitions get weird because they combine elements of both LPARs and VMs. I think Xen is working on something similar.
Again, as z/Series is a proprietary environment, only available from IBM, all clients are in essence paravirtualized. The same could be said for IBM POWER. If I go to Red Hat, I find an "IBM POWER" version, not a generic "PowerPC ISA" version.
Ultimately, paravirtualization only serves as an intermediate step. Intel VT and AMD Pacifica will make virtualization easier on x86. Standard Linux distros will support installers which simply treat a Xen environment as an install option, and copy the correct kernel modules. As AIX 5.1 supports earlier RS/6000 systems, either the AIX installer does something similar, or the code which would implement the hypervisor never needs to or is never used.
Ultimately, hypervisors and VMs will blend to a point they are not easily distinguishable.
Posted by: Mark | Nov 19, 2005 1:39:08 PM
Mark,
Thanks for the comment.
What is needed is a clear definition, which I suppose I did not provide.
Consider this: A HYPERVISOR is (as I did say) a step beyond a supervisor
and is a program that hosts a guest operating system unmodified, executing on
the underlying hardware until there is an exception (such as I/O). Both z/VM
and VMware fit that definition, so I class them together.
I unintentionally left out the POWER reference. Had I been conscious,
I would probably have left it out anyway because I was aware that it is more
PARAvirtualization and requires modification of the guest. Sure, there are
performance gains with paravirtualization, observed not only on POWER
but also on PC hardware (INTeL or AMD). The value then of full virtualization
is where modifying the guest is not possible, but it may be "heavy".
Let's say that a hypervisor performs "full virtualization". It creates one or more
virtual machines. Let's say that paravirtualization is something else, sometimes better.
-- R;
Posted by: Sir Santa | Nov 21, 2005 4:01:29 PM
Nice writeup Sir Santa! FWIW, I think you got the call right on the definitions (and like you, I've got over 20 years background in "V12N"). I think Mark's comment about the IBM POWER systems is interesting, but I think there's a key point being missed here - virtualization as we understand it typically means "software virtualization". Virtualization where the hardware does it (even via microcode) usually is described differently. As examples, there is IBM's LPAR and Amdahl's MDF, Sun's LPAR-equivalent (I forget the name), etc. Likewise emulation - the IBM 370/158 could emulate the IBM 1402 for Autocoder support back in the 1970's, but that was a hardware function, not software.
You were right to call VMware a hypervisor - while it may manipulate some instructions, it doesn't emulate them (a la BOCHS or the 158's 1402 support), and it does device fencing and virtualization (e.g., virtual disks, virtual network adapters).
Posted by: Sir Ross the Fearless | Dec 13, 2005 11:09:48 AM
The comments to this entry are closed.
