Moving a VMware ESXi 4.0 Guest From One Host to Another

To move an ESXi 4.0 guest is not all that hard – but you must be aware of several things along the way. Taken one step at a time, it won’t be difficult. In this discussion, we assume that you are moving from one ESXi 4.0 host to another – both with the same architecture. (Anything other than that gets much more complicated.)

First, make sure there are no snapshots. Snapshots are not compatible with this process and must be eliminated altogether.

Then, shut down the guest system. We don’t want the guest changing as it is copied across.

The next step is to copy the guest files from the original host to the destination host. This is the longest step considering you probably have gigabytes of data to transfer. This is also done from the ESXi command line.

I would normally use rsync but it doesn’t exist on an ESXi 4.0 system; use scp to copy the files. Your files for the guest should be located in /vmfs/volumes/datastoreX/guest/ where datastoreX is the data store containing the guest and guest is the name of the guest host. If you renamed the host in one of the GUIs such as VSphere Client, then this will reflect the original name.

Make a directory in the remote host (using the ESXi command line interface) in one of the data stores, and then use commands like these from the original host:

cd /vmfs/volumes/datastoreX/guest
scp * remotehost:/vmfs/volumes/datastoreY/guest/

This will copy the files to the remote host.

However, copying is not enough. Log into the remote host and go to the place you copied the files to. Check over the file ending in .vmx for any references to disks that must be changed. Convert remote host paths to local disk paths – you will probably need to know the long hexadecimal path for any paths, so list that before you start editing. If you execute a cd command to the directory containing the guest host, the long path will be in the prompt.

Next you must register the host so the system knows about it. Use this command at the command line to do this:

vim-cmd solo/registervm /vmfs/volumes/datastoreY/guest/guest.vmx

Now, to get the host started: start the host from VSphere Client. The client will give you a question to answer about where the guest came from. Click on the guest’s Summary tab and select I copied it. (which should be the default) and click Ok.

The guest will start up – and discover that the MAC address of its network interface has changed. For Linux, this means a new ethernet interface, and the configuration of the old interface is ignored: that means that there will be no network connectivity. Enter the console and change the old configuration from eth0 to eth1 (or whatever is appropriate; find out with ifconfig -a). This change varies by which Linux distribution you use; for Ubuntu, the configuration is in /etc/network/interfaces.

While you don’t have to reboot, it doesn’t hurt to do so after this change – and it tests the system in a clean reboot. The system should start up cleanly.

Now don’t forget to remove the original. Using the VSphere Client, right-click on the host and select Delete from Disk. This will remove the guest host entirely from the system and delete all of its files. If you want to retain the files, instead select Remove from Inventory which essentially unregisters the host, so that the system is not managing it – but the disk files remain.

Installing an ISO for Use in VMware ESXi 4

Having a CDROM available for use in a VMware ESXi server can be very useful. However, what if there is no way to get the CDROM into the host? Better yet, what if you just want to avoid the hassle of having to go back and forth inserting and pulling CDROMs?

There is a way to get the ISO onto the VMware ESXi server and make it available to a virtual machine. First, you have to put the ISO on the server itself. Secondly, you have to make the ISO available to the host. That’s it.

First step: copy the ISO to the ESXi server. You could do this with scp (if you’ve activated ssh) or by creating the ISO on the fly from the original disk. You could also use scp on the ESXi server to copy an ISO into the server without activating ssh.

The best destination would probably be a directory in the datastore you set up during installation of the ESXi server. If the datastore is datastore1, then the location for ISOs could be /vmfs/volumes/datastore1/ISO Images/. You’ll have to create the directory ISO Images yourself. Note that “datastore1” (or whatever your datastore name is) is not used by VMware ESXi, but translates to a hex string: so don’t be alarmed when you see it instead of the datastore name you expect.

Lastly, make the ISO available to the virtual machine. Using vSphere Client, you can get to the appropriate place (“Edit Settings”) in a number of ways. Right click on the virtual machine in the list of machines (either on the tree to the left, or on the list in the Virtual Machines tab) and select “Edit Settings”. Alternatively, click on the virtual machine on the left, then click on the Summary tab – and on that tab, click on “Edit Settings”.

In Edit Settings, click on the CD/DVD Drive 1 entry and then click the button for Datastore ISO File (on the right). If you click on browse – then on the drop-down menu at the top, look for “Datastores” (at the bottom). Your datastores will be shown when you click on Datastores, then the directory you created will be in the datastore you used earlier. Select the ISO you want and click Open – then OK.

Once the CDROM is chosen, you can then install from it, or use it in any way you like from the virtual machine. Don’t forget: this is just like putting a new CDROM into the machine – so whatever your OS needs to have happen, you have to do it after “putting the CDROM” into the drive.

Administrator Experiences with VMware and SUSE Linux

Recently, VMware announced a partnership with Novell in which they would support Novel SUSE Linux Enterprise Server (SLES) directly on VMware vSphere. Neil over at VirtuallyNil wrote about his experiences with SLES and VMware ESXI. Unfortunately, he had some problems with VMware’s additions to SLES.

To enhance the experience with virtual machines, virtual environment managers add tools to the guest environments – and VMware is no different. For SLES there are tools available that permit advanced operations directly from the virtual machine manager. With ESXI, these are available for SLES 10 and SLES 11 – but not SLES 11 SP1.

This means that you either build your own SLES 11 SP1 tools or you cannot upgrade your SLES 11 to the most recent patch level. This is unfortunate.

I have experienced this before with an application that required a particular version of Red Hat Linux (7.1 if I remember rightly) even though that version of Red Hat was no longer supported by Red Hat itself.

Also, Neil points out two other sites that have images of people’s direct experiences with the new VMware-supported SLES. One first look comes from vcritical.com (a blog by Eric Gray, a VMware employee); the other comes from Jase McCarty at Jase’s Place.