Only in Star Trek do users have access to the holodeck, a virtual container and simulation environment for interacting with arbitrary objects, creatures, and environments. The average modern computer must make do with EMC's VMWare virtualization software instead, to make a similar but somewhat less all-encompassing departure from desktop reality. Although VMWare lacks the power of the Enterprise's holodeck, it does make practical, real-world use of imaginary, interactive virtualized runtime environments.
This article summarizes how to manipulate simple VMWare configuration files (.vmx) for a Windows host environment to operate Linux within a virtual arena, for validation testing or as a practical training tool.
Kernel virtualization and hardware emulation represents one of the great accomplishments in today's technology, where a conglomeration of heterogeneous platforms often coexist and even depend on one another to meet common goals or objectives. A detailed discussion of the operational differences is beyond the scope of this article. Here, our intent is to provide a basic overview of VMWare settings and properties involved in using Linux on a PC that ordinarily boots into Windows.
Beyond validation testing custom or modified ISO-based images, the VMWare virtualization environment also lends itself to streamlining daily tasks with only minor changes to the Windows environment. The VMPlayer (VMP) bundled with EMC's evaluation version of VMWorkstation (also available separately as freeware) is a lightweight playback environment that installs like any other ordinary desktop application. You can pause, restart, and recreate virtual environments on the fly simply by modifying the simple text-based configuration file that accompanies any pre-packaged VM appliance, or just create your own from scratch. An invaluable resource online for creating custom configuration files (short of using VMworkstation's own built-in tools) quickly is available online.
Many of the elements described in the configuration file are self-explanatory, and are not mentioned here (more information is readily available in the online references). Only those items pertinent to morphing a virtual environment into workable shape are covered briefly, both to describe the benefits and features of using VMs, and to encourage you to explore further the capabilities that the VMWare player or workstation suite delivers so readily.
Here's a sample configuration file we used to validate re-mastered Knoppix images:
config.version = "8"
virtualHW.version = "3"
MemAllowAutoScaleDown = "FALSE"
MemTrimRate = "-1"
uuid.location = "56 4d 06 60 63 a1 d6 85-9a 61 20 66 52 71 07 34"
uuid.bios = "56 4d 06 60 63 a1 d6 85-9a 61 20 66 52 71 07 34"
uuid.action = "create"
checkpoint.vmState = ""
displayName = "Knoppix 4.0.2CD VM"
guestOS = "other26xlinux"
memsize = "512"
ethernet0.present = "TRUE"
ethernet0.connectionType = "NAT"
ethernet0.addressType = "generated"
ethernet0.generatedAddress = "00:0c:29:71:07:34"
ethernet0.generatedAddressOffset = "0"
usb.present = "TRUE"
usb.generic.autoconnect = "FALSE"
sound.present = "FALSE"
scsi0.present = "FALSE"
floppy0.present = "FALSE"
# IDE Device Types (primary master/slave)
ide0:0.present = "TRUE"
ide0:0.fileName = "D:\ISO\KNOPPIX\KNOPPIX-4.2.0CD.iso"
ide0:0.deviceType = "cdrom-image"
ide0:0.mode = ""
ide0:0.redo = ""
ide0:0.writeThrough = "TRUE"
ide0:0.startConnected = "TRUE"
ide0:1.present = "TRUE"
ide0:1.fileName = "hda0.vmdk"
ide0:1.deviceType = "disk"
ide0:1.autodetect = "FALSE"
ide0:1.startConnected = "FALSE"
# IDE Device Types (secondary master/slave)
ide1:0.present = "FALSE"
ide1:1.present = "FALSE"
ide0:1.redo = ""
For system integration or validation testing the drive mounts and network interface parameters are the focal points here. In those directives that pertain to disk drive mount points, ide0 nomenclature indicates the first recognized IDE device, and represents the master position in an imaginary drive sequence.
The properties for each drive may be accessed using what C programmers call a "structure member access operator." It's a cinch to create boilerplate templates using this nomenclature, once you understand how each parameter influences the VMWare environment.
Installing a CD-ROM image to Virtual Disk
There are many ways you can create a virtual disk image for VM installation. You can use the VMWare workstation applications or a simple commandline utility packaged with QEMU, qemu-img.exe, to create one. The QEMU package is available from its publisher's Web site. Here a simple, single-line invocation using the qemu-img.exe image creator:
C:\> qemu-img.exe create –f vmdk hda0.vmdk 4G
You can create an image using the virtual disk format, and call it hda0.vmdk,with a capacity of four GB. Here, four gigabytes is more than adequate to install most Linux distributions and related dependencies, but is by no means the actual file size. You can create an image of any size you desire, but anything you install or modify subsequent to the creation of this image increases its on-disk size accordingly. This image becomes a placeholder in lieu of a real disk drive, where changes persist across all reboots.
Accessing CD-ROM images using the VM Manager
As part of any validation testing you might choose to perform on a given distribution, VMP can access floppy, SCSI, and CD-ROM devices using the VM manager. Apply the following configuration changes to enable a second CD-ROM drive entry, this time for the device and not just the image:
ide1:0.present = "TRUE"
ide1:0.fileName = "auto detect"
ide1:0.deviceType = "cdrom-raw"
ide1:0.autodetect = "TRUE"
ide1:0.startConnected = "TRUE"
These parameters inform the VMWare container that a CD-ROM drive is present, specified as a raw (hardware) device entry, and that it should be both automatically detected and connected at run-time. Many other options are available, especially for the deviceType parameter, but those details are covered in the VMWare documentation.
Accessing network devices within the VM Manager
Using network or Internet resources is incredibly simple, thanks to VMWare developers and their many good ideas.
Running Knoppix 4.0.2CD (the most current version as we write this how-to), you need only set the Ethernet connection type to NAT, which permits your existing LAN connection to serve as a conduit for all VM networking needs. While Knoppix operates seamlessly by default, giving a warm out-of-the-box experience, other Linux distributions and some BSD implementations may require in-house tweaking to get them going -- your mileage will undoubtedly vary. Although you won't see a listing in the default VMWare task bar entry for a Virtual Network Editor (or any of the other utilities packaged with VMP), it is accessible by pointing Windows Explorer at the VMWare install path.
Invoke vmnetcfg.exe, VMWare's graphical Virtual Network Editor, to leverage your virtual network interfaces and connection types. This is where the default 192.168.X.X network class is assigned, which you may now modify to suit your needs. Add, delete, modify, and manage a number of virtual interfaces for multiple instances of VMWare; stop, start, or restart DHCP and NAT services; or create bridged connections from one interface to another.
You can also use VMWare's own vnetsniffer.exe utility to capture data moving between the VM guest and host network interface devices, which can assist you in troubleshooting VM transactions across the Internet or LAN, or to verify VPN setups using existing hardware before committing anything to disk.
Once you've succeeded with a satisfactory build, you can redistribute your image to colleagues, co-workers, or the global community (as the half-dozen third-party applications provided through the vendor Web site6 attest). The VMPlayer/Workstation licensing scheme permits such sharing, as long as there aren't any conflicting licensing clauses within other included software. When customizing a particular Linux distribution, a quick and efficient means to verify your work is essential. Using a VM to facilitate such validation saves considerable time that might otherwise be spent on burning potentially unworkable disc images and switching between disk-drive and ramdisk contexts with repeated reboots.
About the authors: Ed Tittel is a full-time freelance writer and trainer based in Austin, Tex, who specializes in markup languages, information security, and IT certifications. Justin Korelc is a long-time Linux hacker who works with Ed, and concentrates on hardware and software security topics. Together, both contributed to a recent book on Home Theater PCs; right now, both are busy at work on a book about the Linux-based MythTV environment.
