How To Use VMware on CSL Supported Linux Computers
Overview
Using virtual machines can solve many problems for Computer Science researchers: you can run other operating systems, or other versions of operating systems, in the virtual machine, without disrupting your desktop. This can be useful for OS research, or research that requires a specific operating system but can function in the virtual environment, or if you have a need for a few applications in a different OS.
VMware Workstation is installed on all supported research Linux desktops. It is not available on the instructional workstations.
The CSL will support the VMware framework, and provide selected virtual appliances (e.g. Windows VMs for users that have linux desktops but want access to applications that only run on Windows). We are aware that there are several ways to use the VMware software in a different manner to do different things and to the extent we are able we will support the framework to support those options, but
our main goal in this effort was to allow linux users better access to Microsoft applications.
The following documentation should provide enough information to get
started using the CSL VMware installation.
Using VMware
Virtual Machines and Virtual Appliances
VMware is all about
virtual machines. A virtual machine is a collection of virtual hardware (CPU, memory, disk drive(s), keyboard, mouse, etc.) and operating systems/applications to run on that virtual hardware. Before you can run your favorite operating system or application under VMware, someone had to create the virtual hardware, (typically) install an OS on the virtual hardware, maybe install applications, patches, etc. before that virtual machine (VM) is ready for use. Fortunately, once that is done, the virtual machine can be packaged and copied at will to be used by others. A packaged virtual machine is called a
virtual appliance. In reality, a virtual appliance is nothing more than a zip archive of all the parts of a virtual machine.
Recommended Host System Configuration
VMware ultimately relies on the real resources available on the host to run virtual machines. Thus, trying to run a virtual machine on top of a real host that has insufficient capabilities may result in poor virtual machine performance and/or stability problems on the host operating system. The CSL recommends that a minimum configuration of a 2.4 GHz CPU with
at least 2 GB of memory be used for the host OS. Also, virtual machines take up significant amounts of disk space to store virtual disk images. Hosts with small
/scratch partitions may be limited in the number and size of virtual machine images that can be stored simultaneously.
Unpacking CSL-provided Virtual Appliances
To unpack a CSL-provided virtual appliance, use the
vmware-unpack command.
For example, to unpack the CSL-provided Windows 7 32-bit virtual appliance, run the command:
% /s/std/bin/vmware-unpack Windows7
This command unpacks the 32-bit Windows 7 virtual appliance (
/s/vmware/Virtual_Appliances/Windows7.tar.bz) into a virtual machine at
/scratch/ yourname /VMware/Windows7. (Run
/s/std/bin/vmware-unpack Windows7-x64 if you want 64-bit Windows 7.) This will take a
long time as it needs to unpack a few Gigabytes of files. Note that this path is on the local disk,
not in
/afs. You should never run a VM out of AFS as performance will be abysmal.
Running the Windows 7 Virtual Machine with VMware
VMware Workstation is the program you use to interact with your virtual machines. To start it, run the
vmware program. Now you're ready to interact with virtual machines (VMs) on your local host.
You need to tell VMware where to find the VM you unpacked in the previous step. Use
File ->
Open from the menu bar. The Open Virtual Machines or Teams popup will be displayed. Use the file browser to navigate to the path
/scratch/ yourname /VMware/Windows7/Windows7.vmx. The
.vmx file is the configuration file for the VM and is used as a handle to refer to the VM with various VMware utilities. When you have found the
.vmx file for your VM, click the
Open button to access the VM.
To start running your VM, click the
Power On button. Your VM will start running. Although there is a
Power Off button, it is much better to use the virtual operating system's shutdown command(s) to shut down a VM. Shutting down a VM using the
Power Off button poses the same risks to a virtual computer as it does to a real computer; lost data, corrupt disks, and frustrated users.
Once the startup process in completed, you can interact with the Windows 7 VM just as you would with any native windows 7 installation. More description of the CSL Windows 7 virtual appliance, including installed software and account information, can be found later in this HowTo.
Transferring Files Between a VM and the Host Operating System
VMware Workstation on Linux supports drag and drop functionality for file transfers. Previous versions of VMware Server installed by the CSL used a Z: drive mapped to a samba share mounted in /scratch/VMware.share. This is no longer necessary and so this share no longer exists.
You can simply use Red Hat's filebrowser (
Applications ->
System Tools ->
File Browser or simply type
nautilus & in a terminal window), nautilus to drag and drop files between your VM and your host desktop.
There are also settings for sharing a folder between your guest OS and the host. Please exercise
extreme caution if you use these settings as they can expose your host OS to viruses and/or put your data at risk. If you use these settings we recommend you restrict access only to select directories and use
read only settings if you don't require write access. These settings can be found under
VM ->
Settings,
Options tab,
Shared Folders.
Transferring Files Between a VM and Other Hosts
To transfer files between a VM and other hosts we suggest you use the
Secure FX file transfer component, which is pre-installed in the CSL Windows 7 VM.
Note however, that because of firewall restrictions, to transfer a file from a VM to a host outside of CS, you will need to first transfer the file to a CSL-supported workstation, and then transfer it from that workstation to the remote host.
Printing
To print from a VM, you will need to select the
print to file option in your application/OS. The CSL Windows 7 VM comes with a pre-installed generic postscript printer. Print to file and then drag-drop your file to your host OS.
That file can then be printed from the linux host to the CSL printer of your choice.
Read The Fine Manuals (VMware Documentation)
There is much excellent documentation for VMware products on the web. Reading the VMware manuals is the best way to get the most out of the products. The documentation can be accessed at
http://www.vmware.com/support/pubs/ws_pubs.html, or by clicking
Help ->
Contents to view the web based help system or
Help ->
User's Manual to download the VMware Workstation User's Manual pdf.
Virtual Machine General Information
You can also create your own virtual machines using VMware. We suggest that you create a separate directory under
/scratch/ yourname /VMware/ for each virtual machine. If needed, you can create virtual machines on any local partition on your computer. You
cannot run virtual machines from
/afs (e.g. anywhere under your home directory, project space under
/p/..., etc.).
CSL-provided Virtual Appliances
CSL-supported virtual appliances are stored in the directory
/s/vmware/Virtual_Appliances. You can list the contents of that directory to see what's available. The most popular appliances are also listed here, with directions for installation.
Windows 7 Enterprise
Install this virtual appliance with the command:
vmware-unpack Windows7 for 32-bit or
vmware-unpack Windows7-x64 for 64-bit. It has the following features:
- Microsoft Office 2010
- DoIT-supplied Symantec Antivirus (with automatic updates)
- Mozilla Firefox (with automatic updates)
- Adobe Reader
-
secureCRT/SecureFX remote access and file transfer client (doesn't automatically update).
- VMware tools
- Windows Update will automatically apply OS and Office updates as they become available from Microsoft
- A non-privileged account (
vmuser) with a password W1ndows7 (the second character is the number "one")
- A privileged account (
vmadmin) with a password W1ndows7 (the second character is the number "one")
Windows 7 Enterprise Activation Information
Windows 7 needs to contact DoIT's KMS server for license activation. The first time you start up your Windows 7 virtual appliance it will run setup. This takes a
very long time but is the only supported way to make sure you get a unique license key. If you clone a Windows 7 VM and run multiple Windows 7 VM's concurrently you will have
duplicate licenses which is a violation of our licensing agreement and could cause
Bad Things to happen. Therefore, if you must clone a Windows 7 VM and run it concurrently with another, you must follow our instructions to
sysprep your cloned installation in order to get a unique license key.
Using sysprep to get unique licenses on cloned Windows 7 VMs
If you clone a CSL provided Windows 7 VM and run multiple Windows 7 VM's concurrently you will have
duplicate licenses which is a violation of our licensing agreement and could cause
Bad Things to happen. Therefore, if you must clone a Windows 7 VM and run it concurrently with another, you must follow our instructions to sysprep your cloned installation in order to get a unique license key. After cloning a Windows 7 VM, do the following:
- Copy the file
/s/vmware-7.1.2/src/unattend.xml on your host OS to your Windows 7 VM's C:\Windows\System32\sysprep directory.
- Start up
cmd via the start menu Run box or via All Programs -> Accessories -> Command Prompt
-
cd \windows\system32\sysprep
-
sysprep /generalize /oobe /shutdown /unattend:C:\windows\system32\sysprep\unattend.xml
- This will build a generalized unattended "out of box" install. Essentially it will just force your VM to run setup and generate a new key on first startup. You will NOT lose programs you installed. It will take a long time and should then shut down automatically. You may clone this VM if you wish. The next time it starts up it will run setup again (takes a long time) and grab a new unique license key.
Linux - Cent OS 6 virtual machine
Install this virtual appliance with the command:
vmware-unpack CentOS6-i386 OR
vmware-unpack CentOS6-x64 depending on which version you desire (32 or 64-bit). It has the following features:
- A vanilla CentOS 6 'workstation' installation.
- VMware tools.
-
yum is configured to automatically install updates as they become available.
- root account, with a password
CentOS!!
- A non-privileged account (
vmuser) account, with a password CentOS!!
- Any time yum updates the CentOS kernel, it will be necessary to run
/usr/bin/vmware-config-tools.pl to install updated kernel drivers for the vmware-tools component.
Remote access to a running virtual machine console.
- VMware workstation has built-in VNC functionality for connecting to a VM's console remotely. This has replaced the VMware Server remote console program. VNC is disabled by default. It can be enabled on a per-VM basis. To enable VNC connections to your VM:
-
VM -> Settings, Options tab, Remote Display
- check
Enable Remote Display checkbox
- select an unused port (defaults to 5900 which might be in use if you enabled any sort of remote display for your RedHat desktop, so we suggest starting with port 5901 and incrementing for each additional running VM. You can check if a port is in use by running the commands:
netstat | grep {portnumber} e.g. to check if 5901 is in use, run netstat | grep 5901 If you get no output, the port is free for your use.)
- Enter a password if desired. It is recommended you do not use your CS password as this mechanism is insecure. The security comes from using an ssh tunnel for your VNC session (read on).
- Click
Save
- The ports used by VNC are blocked by our firewall for security, so you'll need to tunnel your VNC connections through ssh to connect to your VM through VNC. (e.g. if you set your port to 5901 then you need to setup an ssh tunnel for 5901 on your remote machine and then connect your remote vncviewer to localhost:5901). Full instructions on setting up an ssh tunnel for VNC can be found below so read on...
Establishing a secure VNC connection to your VM on Linux
After you've enabled VNC in your VM (see above), you can connect to it securely by setting up an ssh tunnel to the machine where your VM is running. e.g. if the machine running your vm is
mymachine.cs.wisc.edu and the port you specified in your VM for VNC is
5901:
ssh -L 5901:localhost:5901 {login}@mymachine.cs.wisc.edu
(replace
{login} with your login name and
mymachine with your actual machine name (the machine running vmware, not the name of your virtual machine))
Now you can connect to your VM securely through the VNC ssh tunnel:
vncviewer localhost:5901
Establishing a secure VNC connection to your VM on Windows
After you've enabled VNC in your VM (see above), you can connect to it securely by setting up an ssh tunnel to the machine where your VM is running using your favorite ssh client. e.g. This example uses SecureCRT. If the machine running your vm is
mymachine.cs.wisc.edu and the port you specified in your VM for VNC is
5901:
- Start SecureCRT on your remote windows machine.
- Create a session to login to your remote machine if you don't already have one (if you do, you may skip this step)
-
File -> Connect
-
New Session button
- Protocol:
SSH2
- Hostname:
mymachine.cs.wisc.edu
- port
-
22
- Username
-
{yourlogin}
- Session Name: whatever you want, defaults to hostname which is a reasonable name.
-
Finish
- With your session highlighted, click the
Properties icon.
- In the left-hand panel, select the
Port Forwarding text.
- On the right, click the
Add... button
- Name: something meaningful such as
VNC5901
- Under both the Local and Remote sections, type the Port:
5901
-
OK
- You can optionally add additional ports to forward if you have more than one VNC session to connect to by clicking
Add....
-
OK
-
Connect
-
Accept & Save
- You should now be logged in to mymachine.cs.wisc.edu You may ignore this login but you must remain logged in. The important thing is you now have an SSH tunnel for localhost port 5901, through a secure ssh tunnel to mymachine port 5901.
- Once you have the ssh connection and tunnel established, you can start up your favorite vncviewer and connect to
localhost:5901 (note that you are connecting to localhost not mymachine. The port will be forwarded to the correct machine by your ssh client), enter the password you specified for your VNC session (if any) and enjoy.
Mailing Lists
The CSL maintains an email list for discussion among CS department users, and for announcements regarding upgrades and other activities. We encourage anyone using VMware to subscribe to this list by sending email to
vmware-users-request@cs.wisc.edu. Put the word
subscribe in the body of the message.
Networking
VMware provides a rich networking environment for network communication between the virtual machines, the host OS, and remote hosts. The CSL deployment provides networking facilities that are tailored for most users, and can be customized for whatever research needs arise.
External Network Access
The CSL VMware deployment provides access to external hosts in the form of a NAT service accessible via the VMware device
vmnet8. If you create your own VM's (rather than using the CSL provided virtual appliances), make sure you setup the networking virtual device to be "Custom" and select /dev/vmnet8. Do
not use the built-in NAT type as it will not work. Because of the nature on networking with NAT, VMs can only provide services to other VMs on the (same) host. This is consitent with network facilities on other upsupported/crash and burn networks in the department.
In general VMs should obtain IP information via DHCP, which will result in correct configuration.
| Network Configuration - vmnet8 |
| Network Addresses | 192.168.8.0/24 |
| Netmask | 255.255.255.0 |
| Default Route | 192.168.8.1 |
| Name Server | 128.105.252.100 |
| DHCP Server | Vmware-provided, serves 192.168.8.128 through 192.168.8.254 |
| Static IPs | Yes, use addresses 192.168.8.32 through 192.168.8.127 |
| NAT | Uses Linux IPTables MASQUERADE |
| Linux Host IP | 192.168.8.1 |
Services administratively blocked include:
| smtp | port 25 - use sabe (authenticated smtp gateway) instead |
| bootps | port 67 |
| tftp | port 69 |
| portmap | port 111 |
| epmap, loc-srv | port 135 |
| netbios_ns | only to 192.168.8.0/24 |
| netbios_dgm | only to 192.168.8.0/24 |
| netbios_ssn | only to 192.168.8.0/24 |
| microsoft-ds | only to 192.168.8.0/24 |
| syslog | port 514 |
| printer, lp, lpacct | port 515, 693 |
| afs | 7000-7009 |
| misc | 593, 1964, 2049, 4444, 4545 |
Access to hosts outside of CS is blocked. You can access many
services provided by external hosts by using the CSL gateway service on
squid.cs.wisc.edu port
3128. In addition, destination network address translation will automatically redirect all port 80 (http) traffic from
vmnet8 to squid. However, because some web sites cannot use network-level redirection, we strongly encourage that you configure browsers to use the squid proxy.
squid.cs.wisc.edu provides the following proxies:
| Service | Port |
| http | 80 |
| https | 443 |
| snews | 563 |
| ftp | 21 |
| rsync | 873 |
| gopher | 70 |
| wais | 210 |
| http-mgmt | 210 |
| gss-http | 488 |
| filemaker | 591 |
| sms_update | 777 |

Please note that secure (https) connections require that you manually configure the use of
squid.cs.wisc.edu as a proxy. Secure/SSL connections can not be transparently proxied.
Private Network
There is also a private network that can be used between the VM(s) and the host OS, accessed via the VMware device vmnet1.
| Network Configuration - vmnet1 |
| Network Addresses | 192.168.1.0/24 |
| Netmask | 255.255.255.0 |
| Default Route | none |
| Name Server | none |
| DHCP Server | Vmware-provided, serves 192.168.1.128 through 192.168.1.254 |
| Static IPs | Yes, use addresses 192.168.1.32 through 192.168.1.127 |
| Linux Host IP | 192.168.1.1 |
Bridged Network
For security reasons, you cannot use the bridged network to communicate with external hosts. All packets will be dropped, and you may interfere with the host OSs ability to function correctly.
Updating VMware Tools
The CSL-supported virtual appliances come configured with a VMware component called
VMware Tools, which assists VMware to make certain functions more fluid between the host and guest OS. When the CSL upgrades the version of VMware on the host system, VMware will alert the the user that the version of VMware Tools is out of date with respect to the host environment. VMware Tools can be upgraded with the following procedure.
Update VMware Tools for RPM-based systems (i.e. CentOS)
- Start up your VM and login as root.
- Select
VM -> =Install/Reinstall or Update VMware Tools.
Update VMware Tools for Windows-based systems (i.e. Windows 7)
- Start up your VM and login as Windows Admin.
- Select
VM -> Reinstall or Update VMware Tools.
Release Notes
- VMware makes assumptions that root can write to your home directory. For this reason, it is necessary to link the directory
~/.vmware to the local disk. The CSL vmware wrapper links ~/.vmware to /scratch/ yourname /VMware/.vmware for you.
- VMware cannot run virtual machines in AFS
--
JerelMackay - 19 Apr 2011