Datasheet

Chapter 1: Overview of Virtualization
19
Support for legacy software and operating environments was one of the primary motivations for
virtualization when it was first introduced in an operating system by IBM in the 1960s. By running
operating systems within logical partitions (known as LPARs in mainframe - speak), customers could
upgrade to a newer operating system and newer, more powerful hardware without losing the ability to
run the existing software and associated operating system that their businesses depended on.
Using virtualization to solve legacy software problems is a simple process. It consists of installing the
appropriate legacy operating system in a virtual machine, installing the legacy software, and ensuring
that the legacy software functions correctly in the new environment. Installing and using legacy
software that is keyed to a traditionally unique hardware platform identifier such as the MAC address of
an Ethernet card is actually simplified by virtualization software such as Xen, which enables you to set
the MAC address that is associated with any virtual machine. For example, the need for occasional
access to software that only runs on older Microsoft Windows operating system releases can be met
quite nicely by creating a virtual machine on which the old version of Windows and your target software
package is installed, and using Xen ’ s built - in VNC support to enable remote connections to the virtual
machine ’ s desktop.
Of course, addressing legacy software issues through virtualization is only possible for legacy software
that runs on the same processor architecture as the virtualization software. For example, you can ’ t
support legacy software for SPARC platforms in virtualization software for x86 platforms. In this case,
you may be able to use a multi - architecture emulator such as QEMU to support the legacy operating
system. Similarly, you should make sure that your virtualization solution supports the older operating
systems. Xen is quite flexible in this respect, but many other virtualization solutions are not.
Simplified System - Level Development
A traditional solution to kernel and driver development testing, which often requires frequent reboots to
test new kernels, is to do such development in the context of traditional Linux virtual machine solutions
such as User - Mode Linux (UML). Being able to restart a virtual machine to test new kernels and drivers
is much faster and less of an interruption to the development process than rebooting a physical machine.
This approach can also provide significant advantages for low - level debugging if you are working on a
desktop system that supports virtual machines because your development environment, development
system, and the virtual machine can all coexist on one desktop platform. Virtualization solutions such as
Xen provide a similarly easy - to - use development environment.
Hypervisor - based virtualization solutions are rarely the right environment for final testing of hardware
drivers because they introduce a level of indirection that affects performance to some extent, which also
masks a level of access to the bare hardware that such drivers may require. However, virtualization is a
great development environment for higher - level drivers and system software such as networked
filesystems. Similarly, hardware drivers should be tested against hypervisor - based virtualization
solutions whenever possible to verify compatibility.
Development and testing in virtual machines is a common use of LPARs on IBM mainframes today,
where developers can work with and develop for Linux distributions running in logical partitions that
are physically hosted on a mainframe.
c01.indd 19c01.indd 19 12/14/07 3:57:25 PM12/14/07 3:57:25 PM