David W. Eaton
Artronic Development
4848 E. Cactus Rd. - Suite 505-224
Scottsdale, Arizona 85254
602-953-0336
dwe@arde.com
http://www.arde.com
April 2000
If you have needed to run more than one OS on a single machine at the same time, this may offer some solutions for you. Specifically, I will discuss:
For "PC compatible" machines, the list of available operating system choices continues to expand. But in most cases, the OS alone is not why you are using a computer. It is your particular set of computer applications that are key to allowing you to be productive. If all of the applications you need are available and run reliably under a single version of the same operating system, then most likely that is the OS you will choose to use, and this presentation will have little value for you.
However, what do you do if you need to run some applications that are available only on Microsoft Windows and others that are available only on a UNIX variation such as FreeBSD or Linux? What if some applications only run on MS Windows 98 and others only on MS Windows 2000? What if some require Red Hat Linux 5.2 and others require Caldera Open Linux 2.3 or SuSE 6.3? Many people have tried to address this need with multiple machines, multi-boot machines, and emulation. Now there are some options in the form of "virtual machines".
In the past, the most common solution to the multi-OS need was to have two (or more) machines on your desk and move between them as needed. But even with good networking in place, this can become awkward. Referencing data on one machine so you can use that information on the other machine requires a physical move on your part and (usually) the use of a different keyboard. Plus, it is expensive to purchase and maintain duplicate hardware.
The emergence of multi-boot software at least enabled you to reduce the number of machines required, but you needed to wrap up everything you were doing in one environment before you could reboot in the other environment. Then you had to repeat the boot process to return to your desktop of choice once the special project task was completed--not very efficient. And if you needed to use data from one machine on the other, it had to be saved away on some drive or media that would be accessible to both operating systems.
Emulation packages such as "WABI" and bochs and non-emulators such as "WINE" have held out the promise of running Microsoft applications in a UNIX (or other) environment, but most of these have encountered problems in providing the performance and functions required to do this task well for some applications. Furthermore, such packages did not address the problem of UNIX applications running on MS Windows nor the problem of needing a particular version of your OS for certain applications and a different version for others.
VMware, Inc. has a commercial package which may offer a solution for those in this situation. Its software can be loaded and run on either Linux or MS Windows NT systems using Intel or AMD processors. It then allows you to install a number of guest "virtual machines" that you actually boot and run in a window on your host OS of choice. For example, whether your host OS is Linux or MS Windows NT, you could run virtual versions of MS Windows 3.1, Windows 98, or Windows 2000 or of FreeBSD, Red Hat Linux, SuSE Linux, or Caldera Open Linux on either one of them. All this time, your choice of host OS is available for you to use in your normal manner. Need more than two OSs? If you have the resources, that works too.
Of course, in this time of interest in the Open Source movement, a project has begun to provide a freely available virtual machine solution. Called FreeMWare, its first release was in August, 1999. Still in the "unstable, experimental development" stage, the December, 1999 release included text mode support so users could see code running inside the virtualization framework.
This presentation will take a closer look at VMware's offering from a user's perspective. It will discuss considerations encountered loading VMware, installing the guest OS, ensuring performance, and actually using this package in a real-world environment.
(Note: the author is a customer, but not an employee or sales representative of VMware, Inc.)
Since my desktop operating systems of choice are all UNIX and UNIX variants, this presentation will focus on the VMware offering which runs on top of an installed Linux host system. However, according to the VMware site information, much of what I will discuss here will pertain to VMware running on an MS Windows NT host.
The software you will need to try VMware may be downloaded from their Web site. You will want to get the install bundle which matches your host OS (Linux or MS Windows NT) plus the corresponding tools they provide for the guest operating system. You will load these tools into your guest operating system environment after it has been installed into a virtual machine. They provide better screen resolution and mouse workings, among other features. For example, without these tools, you will need to press Ctrl-Alt-Esc to retain control of your cursor so it can be moved outside the virtual machine's window to your native environment.
Since VMware does charge for its licenses, you may want to take them up on their offer of a free 30-day evaluation license. It provides all the features of VMware, so you can make a proper determination of whether this product does what you need before committing to buy. Should you decide it does, a full license may be installed easily without jostling your VMware code or your guest operating systems. (Of course, if your selected guest OS requires a license, you will need to obtain that as well.)
If you intend to use VMware while logged in under different user IDs, you will need to
be certain the VMware license may be found from each of these home directories as
<ID's home dir>/.vmware/license. This directory also contains a definition file
named preferences which you may want to duplicate.
The Linux version of the VMware package is delivered as a gzipped tar-ball, so
installation on Linux was quite simple and fairly straight forward.
Typically, I install all my layered applications into the /opt/ directory
and use the
repln
script as it is described in
Scripts for Linux and HP-UX
(InterWorks 1999)
to control access. Usually, this enables me to change easily between various
versions of the same application from a single machine or to use different versions on
multiple machines by a simple adjustment to the link /opt/vmware so it
could point to vmware-1.0.2 or VMware-1.1.2-364, etc. as
appropriate. This was almost true of VMware, but not quite, as noted below.
(If you only need to upgrade, but not revert to the older version of VMware, you should
not encounter the problems described here.)
VMware's install script (vmware-install.pl) allowed me to specify
an alternate directory for the main portions of the package:
/opt/vmware/bin for binaries and scripts,
/opt/vmware/lib for library routines, and
/opt/vmware/man and /opt/vmware/doc for the manual and
documentation pages, so all went smoothly with these.
However, when I installed my first version of VMware and it asked for the location of
the init.d scripts, I did not think to consider that it would be dropping
the real version-sensitive daemon startup script into /etc/rc.d/init.d.
Thus, when I went to upgrade to a newer version later, this script was overwritten
by the newer version. Similarly, it wanted to have a directory named
/etc/vmware in which to place configuration information. To facilitate
VMware version swapping on my system, I have replaced these specific files and
directories with links:
ln -s /opt/vmware/init.d/vmware /etc/rc.d/init.d/vmware ln -s /opt/vmware/etc /etc/vmware
VMware will install these links to ensure that its daemons get started on reboot:
ln -s /etc/rc.d/init.d/vmware /etc/rc.d/rc5.d/S90vmware ln -s /etc/rc.d/init.d/vmware /etc/rc.d/rc6.d/K08vmware
but as long as they continue to find the ultimate startup script (which they will with the link above), they will work fine.
Note that to perform a new install, you will need to remove these links, install, then move the data to a version-specific location and restore the links to have everything work properly, but it does preserve the values with the code of the same version and allow you to switch back and forth easily if needed.
What was a bit harder to locate was the fact that VMware wanted to install some modules directly into the system version specific locations. On my Caldera 2.3 these files were:
/lib/modules/2.2.10/misc/vmmon.o /lib/modules/2.2.10/misc/vmnet.o /lib/modules/2.2.10/misc/vmppuser.o
To make matters just a bit more confusing, the binaries supplied with the package
worked fine for my first install so I was not even aware they were there, but for
my next upgrade, the supplied binaries were not compatible with my kernel version.
The install script simply asked where my compiler (gcc) was, then built
and installed each one just fine, asking whether or not I wanted to overwrite the
previous versions.
Thus, to preserve all the VMware code unique to a version, you also need to copy or move these modules to a unique location (and provide any appropriate links). And since these are installed as modules at boot time, you will need to make certain to stop all VMware functions, then remove these from memory and install those for the new version before it will operate properly.
These considerations have all been reported to VMware support, but I have not received any response from them as of this writing, so I do not know if they will be addressed in future releases.
VMware refers to the operating system loaded into a virtual machine as a "guest" operating system. If you have a need and the resources, you may create several virtual machines and install a different guest OS into each. As with the license code, if you expect to use a guest OS from more than a single login ID, you will need to ensure that the permissions on the various files in the guest OS's configuration and load directory will allow appropriate access. These permissions may be adjusted after the guest OS is installed.
![[ screenshot]](Images/01-vmware1.1.2-startup_med.gif)
To load a guest OS, you first must start and configure VMware.
You will be presented with a window which includes the VMware logo and another
window offering several choices of what to do next.
The configuration wizard will walk you through the guest install. Perhaps the only
"tricky" part is answering the question about networking correctly. If you
intend to access the virtual machine from other machines (virtual or real) or access
other machines from the virtual machine, then be certain to select the "bridged"
network configuration.
It will require its own IP address (either from DHCP or a fixed address) but you will be able
to treat the virtual machine like any other machine on your network.
![[ screenshot]](Images/03-vmware-bootup_med.gif)
When you start VMware and elect to use an "existing configuration", it will
provide you with chance to select which guest machine that might be. Navigate the menu
selection until you locate the configured guests and find the file which ends in
.cfg. After selecting this, VMware will let you issue its "Power On".
At this point, you will watch a typical PC BIOS boot-up sequence, including a check of the virtual
machine's "memory" as shown in this screen shot. If your guest OS requires a boot
floppy for
installation, place it (or the first one) into the real machine's floppy drive. If it may be
installed via a bootable CD, just have that in the real machine's CD drive. The install should
progress as it would for a load on a real machine, except that as it gets to places where a
reboot would have been required (which it will several times for an NT guest install) it will
only be the virtual machine which reboots, not your host machine. Thus, you may continue with
other work on your host machine in another window while the load is in progress. In fact, if
your host machine
has virtual desktops, you may switch to a different desktop and return to check the install
progress as you wish.
To use your virtual machine, start VMware. Either use the path to the virtual configuration as an argument (or navigate to the configuration file as described above) then select "Power On". A word of caution: when the virtual machine boots, it first tries to read the floppy disk for boot instructions, then will try the virtual hard disk - much as a normal PC is likely to do. Thus, if you have a floppy in the host machine's drive, the boot sequence may encounter problems. In particular, if you have been using a floppy to control a LILO boot of either your physical host Linux machine or a virtual guest Linux machine, you may see just "LI" on the virtual screen, and LILO will halt since it will be unable to locate the boot image it is seeking on the virtual image being booted. In this case, remove the floppy, select the virtual guest window with your mouse cursor, and press Ctrl/Alt/Delete. This will cause the guest machine to reboot (not the physical host machine) and you can continue.
Once the guest OS boots up, you will be presented with its normal login screen and may continue as required:
![[NT4 Server Login Screen within VMware - screenshot]](Images/12-ntstartup-login_med.gif)
![[Caldera 2.3 Login Screen within VMware - screenshot]](Images/30-col2.3-login_med.gif)
![[NT4 running within VMware on Caldera 2.3, showing KDE dashboard - screenshot]](Images/13-nt4-with-kde-dash_med.gif)
When you are finally logged in, you will have a window on your host machine which is displaying
the normal desktop for the guest OS. Of course, all your normal host desktop functions are
still available, as can be seen in the adjacent screen shot of a Windows NT guest desktop in a window
adjacent to the host's KDE dashboard.
It is now time to install any applications you wish to use in your new guest OS. The first one should
be the special VMware tools so that you can enjoy its full function. Follow the instructions as
directed on the VMware site. If you will be testing several new applications on this guest OS, you
may want to make a copy of the recently installed disk image so that you can restore it and use it as
a common starting point for several tests. In fact, if you have sufficient resources, it is possible
to make a complete copy of the configuration directory from the host OS and then edit the
configuration files so that you can alternate between booting the clean install and the copy you are
testing. However, since MS Windows NT requires its own licensing and embeds a special install
indicator in the image, be careful not to boot both images at the same time.
I have installed and run VMware on several different machines with varying system capabilities. Some have been Intel Pentium machines and some AMD. Some have had IDE disk drives, and some SCSI drives only. My desktop at this writing was an AMD 350MHz machine with 128 mb of memory, an 8mb video card, and several gigabytes of hard drive space available to the virtual machines. Its host OS is Caldera Open Linux 2.3 and the screen is a 19 inch display running in True Color at 1600 by 1200 pixels. The guest OS is MS Windows NT 4.0 with Service Pack 3 installed. Typically, I set the screen resolution of the guest machine to True Color at 1152 by 864 or 1280 by 1024 so that I can still have other screen real estate available for other windows on the same desktop.
So that I could bring a demonstration version of VMware to the conference, I installed VMware on my laptop machine. That is an AMD 450MHz 128 mb memory, 10 gigabyte hard drive, 15 inch display machine running Red Hat Linux 6.1. Both the desktop and laptop work well, however although the laptop is faster, its display does not support the high resolution of the desktop machine.
In addition, I have tried using an HP-UX 10.20 machine as my desktop, logged into the
Linux machine and directed the X-Windows display back to the HP video. VMware will work in
this configuration, however the low color aspects of the HP video require dropping the virtual
machine screen resolution and color value. Not only does this result in a degraded display, but
VMware does not perform as well with the lower resolution virtual machine. It does seem to perform
better than vnc did when I had tried that, but it was not as responsive as other
X-Windows applications and certainly not as fast as sitting at the Linux box itself.
Even with TrueColor, when operating VMware over a 10mbps network, performance can be a bit
disappointing, though still usable.
It is on the Caldera host desktop configuration described above that the tests and screen shots for this report were made.
![[NT4 running ftp, Lynx, and MSIE5 within VMware - screenshot]](Images/14-nt4-ftp-msie5-lynx_med.gif)
Since much of my work is involved with Web servers and browsers, naturally that was something I
wanted to test. With NT Server, I was able to configure and bring up IIS to serve Web pages from a
simple directory structure. These pages were viewed by several users in Arizona as well as in other
states during the test period. At the same time, the Caldera host system was delivering test pages
from an Apache Web server running on the host machine.
For Web browsers on the Windows NT guest OS, I tried Lynx 2.8.1, Microsoft Internet Explorer (MSIE) 5, Netscape 4.6 and, and Opera 3.60. All functioned as I would expect with little (if any) detectable performance issues. The only exception was Opera, which did demonstrate some odd multi-painting of the window as a Web page was scrolled, but once scrolling stopped, the displayed page was fine. (I have not seen this behavior from Opera on a native Windows 98 machine.) This screen shot shows MSIE 5 and Lynx 2.8.1 displaying the VMware Web site. The window in the lower left is an ftp session from the Windows NT box to a Linux Machine.
When running SuSE 6.3 as the guest OS, it was running its copy of the Apache Web server running
at the same time Apache was running on the Caldera host OS. Once again, Web browsers on each OS
were able to bring up pages from the other's server with no difficulty.
![[NT4 running document and graphic applications within VMware - screenshot]](Images/15-nt4-doc-graphics_med.gif)
In this screen shot you can see a variety of document processing and graphics applications
all invoked in
various windows of a Windows NT virtual machine. While it is unlikely that anyone would use this
array of applications all at once, it does demonstrate that they were all able to be brought up and
they all did what was expected. Shown in these windows (from top left) are:
With a local printer connected to an MS Windows 98 machine and configured as a "shared"
printer, these programs in the virtual machine window were able to print to it as would be expected
in any Microsoft network. I know of people who have set up Samba and accomplished printing and file
sharing between the virtual MS Windows NT and Linux machines, but I did not try that for this report.
![[NT4 running Quicken and Excel within VMware - screenshot]](Images/16-nt4-quicken-excel_med.gif)
Financial applications sometimes have been what forced an otherwise Linux-only network to include a
Microsoft OS machine. As can be seen here, Microsoft Excel ran fine in the virtual NT window.
However, if you need to share your business records with your accountant, what may be more
significant is that Intuit's Quicken 2000 also ran in the virtual machine. This particular instance
imported a database file written with Quicken 98 and was able to continue working with it as
anticipated.
I have run TurboTax for 1998 on a virtual NT, as well.
![[SuSE6.3 desktop filemgr, Netscape, Gimp, Imagemagick within VMware - screenshot]](Images/21-suse6.3-desktop-filemgr-netscape-gimp-imagemagick_med.gif)
In addition to the MS Windows NT discussed through most of this report, I have installed
Caldera Open Linux 2.3, SuSE 6.1, and SuSE 6.3 as guest OSs for the purpose of testing and
evaluation.
The only real problem I encountered with both Caldera and with SuSE was that after
installing the special VMware tools, the X-Windows configuration wanted to start in a 1600x1200
window - my full screen size. However, when the window decorations were added, it forced the
window to be larger than the screen size and the dashboard was pushed off the bottom of the
screen. Changing the Modes line in /etc/XF86Config.vm to be:
Modes "1280x1024"adjusted them to use a window of more appropriate size.
SuSE 6.3 is shown in this screen shot with its file manager, Netscape, The Gimp, and Image
Magick all
running on the virtual desktop. This configuration seemed to perform well.
![[COL 2.3 Lynx, Netscape, Konqueror, Gimp within VMware - screenshot]](Images/32-col2.3-lynx-netscape-Konqueror-gimp_med.gif)
Caldera Open Linux 2.3 is shown in this screen shot with the VMware Web site called up in Lynx, Netscape and the KDE file manager, which can be used as a Web browser. The Gimp is startup splash screen is shown, as well.
Of these Linux variations, the SuSE 6.3 seemed to perform the best as a guest OS.
Caldera 2.3 was OK for most operations I tested, but when trying to run The Gimp on it,
it was noticeably slower than it is as a native OS. However, to be fair, VMware did not claim to
support Caldera versions later than 2.2. Thus its special tools may not have been tuned as well
for the 2.3 version.
Unfortunately, I did not perform any explicitly measurable performance tests with the OS installed on identical hardware as a guest and as a host. However, my perception as I used the various applications was that with the exception of The Gimp on Caldera 2.3, they performed at least as well as they did when executed in a native install environment. (As noted, that problem may have been caused by using an unsupported configuration.)
Obviously larger memory machines will do less swapping and thus should have better performance, particularly if you bring up a virtual machine for long periods of time and switch frequently between that and your native window tasks. With my 128mb machines, a single instantiation of a virtual machine performed very well regardless of whether I shifted to other desktops to deal with email, other work, or to invoke xv or The Gimp to capture or process the screen shots.
However, when I tried to start both Windows NT and SuSE or SuSE and Caldera each in their own virtual machines at the same time, VMware informed me I did not have sufficient local memory.
VMware may not be the solution for everyone.
One of its drawbacks is that in addition to needing a license for VMware, you must purchase valid
license for your MS Windows guest operating system.
Also, at this writing BeOS and some others were not supported either as a host or a guest OS.
Certain peripherals (such as Zip drives) are not supported within the virtual environment (although
if your host OS supports them, you may be able to transfer files to and from it via a utility such as
ftp.
MS-Win apps that load their own device drivers, or which try to access the hardware directly, are likely to have problems in the virtual environment. And any device that isn't supported by the host OS won't be available to the virtual machine, either (such as USB under Linux 2.2.x). Overall, however, from my testing, VMware provides a much faster and more stable environment than any of the emulators for "normal" applications.
For the Linux user who needs to run an occasional Microsoft based application, VMware is well worth a look. It also appears to be a good solution for someone who needs to test various configurations of an application without reloading a machine from scratch.
This presentation was prepared by Artronic Development for the 2000 InterWorks Conference. An outline and an abstract are available for your convenience. This is an HTML document located at URL "http://www.arde.com/Papers/MultiOS/paper.html".
(Select the thumbnails above to view a larger image.)
To learn more about the Web, please refer to the other papers which are also on this Web site.
(Dave Eaton has been using Linux and creating and maintaining Web sites since mid-1994.)
![[Available Papers]](Images/ToPapers.gif){kind=small}
![[ARDE Home]](Images/ToHome.gif){kind=small}
(Updated 24 JAN 2000)
![[Table of Contents]](/Images/TOC.gif)