How to create a virtual machine on Windows Server 2003

Learn how to create a virtual machine in this part of the VMware on Windows 2003 Server series.

What good is virtualization without a virtual machine?

Next in our saga, (which has so far included discussion of the parts of VMware Server, installation and configuration of Windows ont he host server, installation and configuration of VMware Server itself, configuration of IIS and SMTP), we will finally create the virtual machine.

Table of contents

  • How VMware Server works
  • Components of VMware Server and preparing the host server
  • Installing Windows and configuration tips
  • Windows security and IIS
  • SMTP and VMware Server
  • More configuration
  • Creating a virtual machine
  • Installing a guest operating system and conclusions
  • Creating a virtual machine with VMware Server is incredibly easy. First, launch the VMware Server Console by clicking on the "Start" button, click "All Programs," click "VMware," click "VMware Server," and then click "VMware Server Console."

    By the way, the installer should have created a shortcut to the VMware Server Console application on the desktop, but if it did not, go ahead and create the shortcut; this application will be used quite frequently.

    Once the VMware Server Console is loaded, click the menu item labeled "File," then click "New" and then click "Virtual Machine." There is also a key-combination to do this; it is CTRL-N. Alternatively, the big button in the middle of the VMware Server Console Home screen can be used to create a new virtual machine as well.

    A wizard will appear titled "New Virtual Machine Wizard." Click the "Next" button.

    Select the "Custom" option and click "Next."

    Select the appropriate guest operating system that this VM will run and select its version. In this case, it will be Microsoft Windows Server 2003 Standard Edition. Click "Next."

    Choose a name for the VM. This will also automatically fill in the location of the VM. Click "Next."

    Uncheck the box next to "Make this virtual machine private". This way, access to the VM will be granted based on the file permissions on the VM. Click "Next."

    This step is very important because it affects the security of every VM that will be running on this server and possibly the security of the entire computing infrastructure.

    Glossary and links

    Here you'll find every link and term mentioned throughout this series.

    As was reviewed in section II, VMware Server launches each VM in its own process. This screen is a chance to configure which user account is used to run that process. By default, a VM runs in the context of the user that powers it on. This is very, very, very unsecure.

    Suppose that this server is a member of an AD. Because the file system on this server has been configured to allow Administrators of this server access to the VMs, unless default settings have been changed in another location, that means that any member of the AD "Domain Admins" group can access the VMs with the VMware Server Console.

    If a Domain Admin were to power on a VM, that VM would be running in the security context of the Domain Admin. At the moment there is no known method of breaking out of a VM running in VMware Server, but suppose there was (and there will be at some point -- hackers are not dumb, they recognize new attack vectors when they present themselves).

    The following scenario could easily play out and a hacker could destroy an entire AD if a VM is run under the context of a privileged user. The Domain Admin "l.carroll" accesses VMware Server and powers on the VM named "jabberwocky." The VM "jabberwocky" is now being hosted by the "vmware-vmx.exe" process, and that process is running in the security context of the Domain Admin "l.carroll". The Domain Admin "l.carroll" then disconnects from the VMware Server after powering on the VM. Several hours later the VM "jabberwocky" is hacked because it was a poorly configured IIS server (the system administrator should have followed this guide!).

    It is not just any hacker that compromised the VM, but a hacker that invented a method to follow the white rabbit all the way outside the VM and into the host server's operating system. Congratulations, at this point it is necessary to change every password in the Active Directory and potentially rebuild all of the servers.

    When the hacker broke on through to the other side, the other side happened to be running in the security context of the Domain Admin "l.carroll." That means that any malcode the hacker runs, any access the hacker attempts, is run as a Domain Admin!

    That scenario is why it is very important to carefully choose what account will be used to power on a VM.

    If the server is not part of an AD, it may be tempting to just use the Local system account as the VM account. Although no AD would be compromised if a VM was hacked and exploited, the host server could be, as could all the other VMs running on the host server.

    The safest solution is to create a low-privileged service account and use that as the VM account. The only extra privileges this account should need is Full Control of the folder "e:\var\vms". Other than that, normal user privileges should suffice.

    Alternatively, if the server is a member of an AD, a single low-privilege domain user account could be used to run the VMs on all the VMware Server hosts.

    For the truly paranoid, a separate low-privileged user account should be used for every single VM. Of course, all the accounts should have separate, long, passwords as well. This way, if one account is compromised, not all of the accounts are compromised.

    Before clicking "Next," decide whether or not this VM should be powered on when the server boots. Adjust the settings appropriately and click "Next."

    Even though it may be tempting to select two virtual processors from the get go, consider this: Windows Server 2003 cannot cope with having a processor removed. Windows Server 2000 could handle this, but for what ever the reason, 2003 cannot. So, although it is trivial to add more resources (in this case a CPU) later to the VM, it will not be possible to remove the additional CPU if it is not being utilized.

    Therefore, select "One" processor and click "Next."

    Despite the fact that most servers today ship with a minimum of 1 G of memory, Windows Server 2003 will happily run on 384 M of memory. To be safe, go ahead and select 512 M. If later on the server craves more RAM, then satiate its volatile lust by increasing the amount of allocated RAM. Click "Next."

    Unless the VM needs to be on a private network or a NATd network, select "Use bridged networking." This guide will not discuss all the different types of network settings available in VMware Server, but there will be a guide sometime in the near future on advanced networking and VMware Server.

    Click "Next."

    The BusLogic adapter is there for legacy support. Select "LSI Logic" and click "Next."

    Select "Create a new virtual disk" and click "Next." Select "SCSI" and click "Next."

    Windows Server 2003 Standard installs fine in 6 G of space, so for the disk size, specify "6".

    Now the question arises about whether or not to pre-allocate the space for the virtual hard disk image. If there is 6 G free on the server, then by all means allocate the space in advance. This will increase the performance of the VM. Allocating the space in advance also means that the disk cannot be shrunk or defragmented later. Something to keep in mind.

    It is also a good idea to split the disk into 2 G files by checking the box next to that option. This will make it easier to burn the VM's disk files to a DVD if need be or even to transfer the files over the network. There is less chance for an error to occur when moving or copying smaller amounts of data.

    Click "Next."

    Name the disk file something mnemonic, like "%HOSTNAME%-system.vmdk" and click "Next."

    Congratulations, the VM has been created! Next we'll look at installing a guest operating system.

    Go back to part six Go to part eight

    Dig Deeper on VMware virtualization