Many companies have not yet begun virtualizing because of virtualization costs and required hardware. What better way to get started than by turning existing servers into virtual hosts using the free VMware ESXi hypervisor?
Almost every data center has underutilized physical servers running single applications, which makes them perfect candidates for virtualization. In this tip, we show you how to convert an existing physical server into a virtual machine, then how to install ESXi on the server hardware and load the virtual machine back onto it.
Click to enlarge.
You might wonder why you should use the free version of ESXi rather than the free VMware offers, VMware Server. There are several reasons. The first is performance. Virtual machines running on ESXi perform better; ESXi has less virtualization overhead because it is a bare-metal product without an operating system layer under it.
Another reason is licensing. If you run the Windows version of VMware Server you need to license both the host and guest operating systems. Finally, ESXi has more features and better security and management tools and is an easy migration path if you eventually choose to use paid editions of ESXi or ESX. For a detailed list of features in the ESXi free version read this feature comparison chart.
ESXi minimum requirements
So before we get to the nuts and bolts, let's discuss hardware and virtualization. A good candidate for a virtual host has minimal hardware specifications for good performance. Check the ESXi Hardware Compatibility List (HCL) to see whether your server and I/O components are listed. Even if they are not (as many older servers aren't), your server and I/O components may still be compatible with ESXi.
Number of cores. You should have at minimum a single physical multicore CPU or two or more physical single or multicore CPUs; the more CPU cores or sockets you have, the easier it is to schedule virtual machines (VMs) and the better the performance from them.
Memory and NICs. You should have at least 2 GB of memory but preferably 4 GB or more. gets used up quickly on virtual hosts. For physical network interface cards(NICs), one is OK; two are better and four or more are best. Having more NICs provides you with redundancy and more configuration options. If you have only one NIC, consider buying a multiport NIC card to add additional NICs, which are generally low cost (just ensure that the NIC is on the I/O HCL).
Storage. Most local storage devices work with ESXi other than for integrated development environment (IDE) drives. You may be able to install ESXi onto an IDE drive, but you cannot create Virtual Machine File System (VMFS) volumes on it. You should use Serial-Attached SCSI (SAS)/Serial Advanced Technology Attachment (SATA) or SCSI storage instead. If you want to use shared storage, consider the lower-cost or free Network File System (NFS) and iSCSI solutions that are available. Both NFS and iSCSI support are included in the free version of ESXi.
Converting physical servers into ESXi-based VMs
Now to get started, the first step is converting an existing physical server into a virtual machine so we can utilize the server hardware for our virtual host. To do so, you can use VMware's free physical-to-virtual (P2V) product called vCenter Converter, which will hot-clone the server into a VM. Follow the steps outlined below to complete this process.
- Download VMware Converter (we're using the
new Converter 4) and install it on a workstation that will be used to clone the physical server via
a remote conversion process. This process will hot-clone the remote server and create a new VM on a
storage device or network device on your workstation. Later on we will run Converter again to push
the image back to the new ESXi host that we create. When you run the installation program, select a
client/server installation setup type. You can install and run Converter locally on the physical
server using the local installation type and specify a network storage device mapped to the
physical server to store the VM clone file. Once you choose a setup type, you can accept all the
defaults for the installation.
- Once Converter installs, launch it to begin the conversion process. Because this is a hot clone
(which means we're cloning while the source server is running) it's best to shut down any
applications on that server; data that is changed after the process begins will not be copied. When
you launch Converter, you will get an initial screen that allows you to choose a server to log in
to. This is the server that runs the Converter server service, not the source server that is to be
converted. Because we are running Converter on a workstation with the server service installed on
it, you should chose the Connect to a Local Server option.
- Once you are logged in, click on the Convert Machine button to launch the conversion wizard.
Once the wizard loads, select the Source Type as Powered-on Machine, select A Remote Machine, and
enter the IP address or hostname of the physical server and the username and password. It is
recommended that you use a local administrator account on the server. If you click the View Source
Details link, it will connect to the server and display relevant information. Click Next once you
are done. The Converter agent will be deployed automatically to your source server.
- For the Destination Type, select VMware Workstation or other VMware Virtual Machine, and for
VMware Product select Workstation 6.5.x. Don't select VMware Infrastructure Virtual Machine yet,
because we do not have a host that we can select as a destination. Because of this, we will also
want to specify a location for the new virtual machine to a network drive that is accessible to the
source server using a Universal Naming Convention (UNC) path. We have to use a UNC path because we
are running Converter remotely instead of directly on the source server that we are converting. (If
you run Converter locally on a server, you can specify a drive letter instead of a UNC path.) This
location serves as a temporary home for the virtual machine files until we copy them back to the
ESXi host once it has been built. Click the Connect As button to enter user credentials to log in
to whichever server you specify as your UNC path. In this example, we are saving the virtual
machine to a UNC path on a Windows server. Make sure you have enough space on whatever destination
location you choose; you have the option to edit the size of a VM's drive in the next step. Click
Next when you are finished.
You can change the various hardware options for your new virtual machine at the Options screen. The first option specifies the data to copy. Here you can select which drives you want to be included and resize them. It's best to choose a smaller size for your drives right now, such as 1 GB more than the minimum size. Doing so conserves space on whatever storage location you chose in the previous step (you have the option to increase the size later on when we run Converter again to copy the VM to the new ESXi host). You can also edit the devices on your new VM; consider reducing the number of CPUs and memory if the new VM doesn't need much. You can also edit your networks and choose to shut down services that run on the host. Once you have set your options, click Next to continue.
- Review your choices at the summary screen. Go back and make any necessary changes and click
Finish to being the conversion. A task will be created, and then you can start converting your
physical server into a virtual machine from whichever location you chose. Once it's complete, you
can close Converter and shut down the physical server that you cloned. Check your chosen location
as the destination and make sure a directory has been created for your VM, and make sure that a
disk file (or .vmdk file) is present and is the size you chose.
In the next part of this series on converting physical servers into ESXi VMs, we will cover how to convert the physical host into an ESXi server.
Eric Siebert is a 25-year IT veteran with experience in programming, networking, telecom and systems administration. He is a guru-status moderator on the VMware community VMTN forums and maintains VMware-land.com, a VI3 information site.
This was first published in July 2009