Startup window of DOSBox 0.73 with welcome display. Note display of startup settings for SoundBlaster sound card. |
Virtual Computing May Be Key to Increased Efficiency
Using virtual machine software to consolidate multiple virtual servers onto one physical server can serve several practical purposes
Currently, one of the many hot topics in computing is virtual computers. If you look at any of the computer trade journals, you are almost guaranteed to find at least one article discussing how to “virtualize” your data center and how it will allow you to utilize your server hardware oh so much more efficiently. Truth be told, it’s not all hype.
However, this is yet another field where you have to be very careful to make sure everyone is using the same definition for the terms, and that you have carefully considered all the implications. And sad to say, this wouldn’t be the first time that a vendor has redefined what they call their technology to try and catch the popular wave.
First, virtual machines are nothing new (well, at least not in computer terms). If you have been using an application written in Java, you have been using a virtual machine. For that matter, if you have been running any applications written in one of Microsoft’s .Net languages, you have been using a virtual machine. As originally defined, a virtual machine is “an efficient, isolated duplicate of a real machine,”1 though in current usage no physical analog of this logical computer need exist. In this context, a Java virtual machine is what is referred to as a “process virtual machine.” When an application is launched, a virtual machine is created to run that single process and is closed when the process concludes. Because it adds an additional layer of software between the application and the computer hardware, it adds additional overhead to the system, reducing its efficiency. The justifying reason for this is that the virtual machine provides a platform-independent environment for the execution of the program.
To put this example into more understandable terms, the Java program itself cannot be run directly on any standard computer because it will not understand its commands. What the Java virtual machine does is read in the Java program commands and translate them into native commands- allowing the computer it is running on to speak the same language and therefore understand those commands. This is the reason Java can be referred to as a portable language. In theory, one could take the same Java program and run it on any computer, no matter what its native command set. The reality is that it is only portable between computers and operating systems for which a Java virtual machine application has been written. This virtual machine is what is referred to as an abstraction layer between the operating system and the Java application. It deals with the differences in how to access files and hardware for that particular system so the Java program doesn’t have to.
The other kind of virtual machines are called “system virtual machines.” With a system virtual machine, an entirely different instance of an operating system is sharing all of the underlying physical machine hardware. These additional instances can run the same, or different, operating systems. The software that handles the juggling between these different operating system instances is frequently referred to as a hypervisor, though you will occasionally see it referred to as a virtual machine monitor.
Hypervisors capable of running directly on the host computer are referred to as “native virtual machines.” If the hypervisor runs on top of another operating system, it is referred to as a “hosted virtual machine.” You will sometimes see these referred to as Type 1 and Type 2 virtual machines.
In a Type 2 system, the hypervisor’s operating system is called the host operating system. All the instances the hypervisor’s operating system is handling are referred to as guest operating systems. Depending on the machine architecture that a specific guest operating system was designed for, it may be able to execute natively on the host processor, or it may require the hypervisor emulate another processor architecture. This is referred to as “full virtualization” of the hardware and, while the execution is not as efficient as native execution, it does allow much more flexibility in terms of the operating systems that can be supported.
While it is true that virtual systems can be very complex, particularly those designed for computers or operating systems not specifically for virtualization, there are those that like to exaggerate this complexity, like how the old west medicine man used their mumbo-jumbo to sell snake oil.
System virtual machines can take many forms; not all of them are designed to perform ground breaking research or simplify server management. In fact, the sole purpose of one is to play games. DOSBox and DOSBox Portable are designed specifically to emulate an Intel 286/386 microprocessor in both real and protected modes, along with all of the supporting hardware of a pre-Windows PC. This design is specific so that many of the old DOS games that are incompatible with the current CMD emulator in Windows can be run on this version. This includes detailed emulation of hardware such as the SoundBlaster sound card and the common graphic modes of the time (Tandy/Hercules/CGA/EGA/VGA/VESA).
Virtual computers designed to emulate state of the art systems are naturally, uh… somewhat more complex. The configuration process of the initial versions of these virtual machines reflected that complexity. However, as newer versions of these programs were released, the actual configuration process became much simpler. To create a virtual machine using the EasyVMX.com Web site’s Super Simple Virtual Machine Builder, you only need to answer four questions. This is augmented by all of the tutorials and other support documents, both written and video that can now be found on the Web.
While there are multiple commercial virtual machine applications available, there are also a number of free virtual machine implementations out there, at least for non-commercial use, which you can use to gain familiarity with the technology. Two of the more popular ones appear to be VirtualBox and VMware.
VirtualBox is Open Source Software originally developed in partnership with Sun Microsystems and now with Oracle. The current stable release is version 3.1.6, with a major upgrade, version 3.2.0, available in Beta 1. It is a full “virtualizer” for x86 hardware and is available in versions hosted by Windows, OS X, Linux and Solaris operating systems. Supported guest operating systems include many versions of Windows (including Windows 98), Linux, Solaris, OpenBSD, DOS, OS/2, Haiku, Syllable, ReactOS and SkyOS, though some versions also require VT-x or AMD-V hardware virtualization support. The binary versions include support for virtual USB Controllers, Remote Desktop Protocol (RDP) support, and USB over RDP support. RDP support allows you to use a virtual machine as an RDP server, so an application running in the virtual machine appears to run on a remote PC using a RDP client, which is also known as Desktop Virtualization (think Citrix).
VMware currently has the largest market share of any virtual machine system and runs under MS Windows and Linux. Guest operating systems supported include various versions of Microsoft Windows, MS-DOS, Linux, OS/2, OS X, FreeBSD, NetWare and Solaris.
As mentioned before, using EasyVMX.com can make setting up your new virtual machine an experience approaching easy in terms of difficulty.
Running VirtualBox or VMware on your local computer is more than just a parlor trick or an example of doing something just because you can. This capability serves several practical purposes. First, it does allow you to run multiple operating systems, so than you can run applications that will not run on your native host operating system. Secondly, it allows you to use your virtual machine to safely test downloaded apps or to surf unexplored regions of the Web. If either results in a maul ware infection, you just delete that virtual machine and create a new one, with no permanent harm done to your system. Believe, me, this is a much less aggravating issue than having to reformat your hard drive after an infection and reinstall and reconfigure all of your applications from scratch.
While using virtual machine software to consolidate multiple virtual servers onto one physical server can definitely allow you to utilize your existing hardware servers more efficiently, there are potential downsides to take into consideration.
First, virtualization does generate overhead processes that must be subtracted from the native capability of the server. If the guest operating system can run natively on the physical processor of the hardware server, the virtual server may run at about 80 percent of the native server’s capacity. If the virtualization software must emulate the instruction set of another machine architecture, this utilization may drop considerably. With multiple virtual machines running on the physical server, making its capabilities are shared between them, the virtual server capabilities drop even more.
However, I find the degree of contingency planning that goes into “virtualizing” a server much more concerning. Yes, you can use existing hardware more efficiently by having every physical server run multiple virtual machines. However, if you don’t include the appropriate software and carefully craft your contingency plans for application fail over, if that one physical server fails, then all of the virtual servers hosted in it fail as well. In some instances, instead of having just one system go down, you may have a half dozen or more virtual systems go down. I can tell you from experience that this is not a fun situation. So, do explore the capabilities of virtual computers and server virtualization, but make sure you ask those worst case questions, and that your implementation group has good answers for them. If you get anything other than a calm reasoned response back, well, you may find that Westworld isn’t just an old movie…
John Joyce is the LIMS manager for Virginia’s State Division of Consolidated Laboratory Services. He may be contacted at [email protected].