Professor Norm Matloff
Dept. of Computer Science
University of California at Davis
Davis, CA 95616
Virtualization is hot these days. Companies can consolidate several servers onto one physical machine, can test new software without worrying about contaminating production systems, and so on.
For the casual user, though, probably the biggest use of virtualization is to run one operating system (OS) from within another. Run Windows from within Linux, Linux from within Windows, one Linux distro within another, and so on. This is the source of my interest in virtualization. As a diehard Linux fan, I'd like to be able to use Linux even when using someone else's Windows machine, without reebooting, so I wish to be able to run Linux within Windows. Some Linux users may wish to have access to certain Windows applications, and though the wine emulator may work for this, running Windows within Linux is another option.
This tutorial focues on such settings. Very little background is assumed; if you're familiar with files and directories ("folders") and have used a text editor (even Notepad), you'll be fine.
If you run OS 1 within OS 2, the latter is called the host and the former is called the guest.
Some guest OSs are not persistent, meaning that one cannot save files within them. We discuss this here.
This tutorial focuses on the following virtualization products: QEMU, VMware and VirtualBox. All are available for both Linux and Windows hosts. Here are their pros and cons from my point of view:
Obtain QEMU from the QEMU home page. For a Linux host, unpack the .tar.gz file in a directory of your choice. For a Windows host, run the self-installing .exe file. (Click here for information on installing and using the QEMU accelerator.)
There are two main programs in the package: qemu is the actual emulator, while qemu-img creates the disk images.
A typical run would be something like
qemu-img create -f qcow2 emulhda.img 2G
which says to create a hard disk image named emulhda.img of size 2G of format QCOW2. It won't actually be 2G in size initially, but has the capability of growing that large.
You may wish to create a second emulated hard drive, especially if your guest OS is not persistent; click here for details.
The first time you run the guest OS, your command line looks something like this in the case of a Linux host (a slight change for Windows hosts will be shown below):
qemu -cdrom myguest.iso -hda myhda.img -m 256 -boot d
where myguest.iso is the .iso file containing your guest OS. This command line says to boot from that file, treating myhda.img as the guest OS' hard drive, with 256M of RAM.
Except for nonpersistent OSs, your subsequent runs will have the simpler command line:
qemu -hda myhda.img -m 256
You no longer need the .iso file, as it is embedded in myhda.img.
In the case of Windows hosts, you need to specify the BIOS file, which comes with the QEMU-for-Windows package. So if you place that file, and the QEMU executables in, say c:\qemu, type
c:\qemu\qemu -L c:\qemu -cdrom myguest.iso -hda myhda.img -m 256 -boot d
for your first run, and include the same -L field in subsequent runs.
Networking: Note that only TCP/IP is supported, e.g. one cannot do ping. The default networking operation is bridge; the casual user need not know what this means.
QEMU keyboard operations:
Obtain Player from here. For Windows hosts, it will be a self-installing .exe file; just run it. For Linux hosts, it will be a .bundle file, which is actually a bash shell script; run it. Installation is the same for Workstation, but you will need a paid license number.
The two main file types are the .vmx file, which describes the virtual machine, and the .vmdk file, which is the disk image. The others, such as the .nvram file for the simulated RAM, will be created when you run the guest.
Preparing the .vmx and .vmdk files:
qemu-img create -f vmdk xyz.vmdk 2G
Then to run your guest OS, type either vmplayer or vmware to start the appropriate GUI, then click the obvious icons.
Mouse grab: When your mouse pointer is within a Player or Workstation window, it is "trapped" there; you cannot move the focus of the mouse to elsewhere in the host OS desktop simply by moving the mouse. Instead, you must hit Ctrl-Alt, which releases the mouse.
To suspend and later resume a virtual machine in Workstation:
NOTE CAREFULLY: After you have run a guest OS the first time, you no longer need the .iso file. Edit the .vmx file after that first time, to delete the entry for the .iso file.
To add a second virtual hard drive:
Some OS, typically live CDs, are not capable of saving files they create. You can create files and use them, all right, but they disappear when you exit the OS.
Not only does that present a problem with the files, it also means that one must retain the OS's .iso file, taking up space. What can be done about saving files?
Different virtualization products will have different capabilities in this regard. I tend to use the first option above, i.e. creating a second hard drive. For example, here is what I do with QEMU (it would be similar for VMware and VirtualBox):
First, I create the two emulated hard drives:
qemu-img create -f qcow2 myhda.img 2G qemu-img create -f qcow2 myhdb.img 2G
I run qemu as usual, say:
qemu -cdrom myguest.iso -hda myhda.img -hdb myhdb.img -m 256 -boot d
Again, due to the nonpersistent nature of the guest OS, we will always use the above command line, as we need to read in the .iso file each time we run. But the first time we run, we'll partition that second emulated hard drive and put a file system on it, so that we can save files there. So, once we boot up the guest OS, we open a terminal window and run the following, possibly needing to prefix the commands with sudo (with # denoting comments, not to be actually typed):
cfdisk /dev/hdb # run the partitioning program on the 2nd drive # using the arrow keys, specify New, Primary, not Bootable, using the entire # 2nd drive (remember, it's not your real drive!); write; exit cfdisk mke2fs /dev/hdb1 # lay down a file system on this partition
Each time you run this guest OS, you'll have to mount the partition, e.g. by typing the following into a terminal window:
mkdir myhdbdir sudo mount -t ext2 /dev/hdb1 myhdbdir
Your previously-saved files should now be there in the directory myhdbdir.
This assumes your guest OS is in xyz.iso and that you will name other files accordingly.
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "4"
memsize = "256"
ide0:0.present = "TRUE"
ide0:0.fileName = "xyz.vmdk"
displayName = "xyz"
checkpoint.vmState = "test.vmss"
ide0:0.redo = ""
ethernet0.generatedAddress = "00:0c:29:4b:1f:e9"
uuid.location = "56 4d 79 71 e7 5b b4 61-bd 43 7a 50 f6 4b 1f e9"
uuid.bios = "56 4d 79 71 e7 5b b4 61-bd 43 7a 50 f6 4b 1f e9"
virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "manual"
vmotion.checkpointFBSize = "16777216"
ethernet0.generatedAddressOffset = "0"
diskLib.sparseMaxFileSizeCheck = "false"
ide1:0.present = "TRUE"
ide1:0.fileName = "xyz.iso"
ide1:0.deviceType = "cdrom-image"
ethernet0.present = "TRUE"
usb.present = "TRUE"
sound.present = "TRUE"
sound.virtualDev = "es1371"
displayuName = "xyz"
guestOS = "otherlinux"
nvram = "xyz.nvram"
scsi0:0.redo = ""
ethernet0.addressType = "generated"
Many of these entries are initially unnecessary; VMware will add them for you the first time you run the guest.