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.

VMware to Buy Novell’s Linux Business?

This is very interesting indeed. VMware and Novell just announced that VMware would sell SUSE Linux Enterprise Server on VMware’s vSphere product (with full support by VMware) – and now there is a report by the Wall Street Journal that Novell’s Linux business could be bought by VMware. Talks are continuing, but this is intriguing to say the least.

The focus is on SUSE Linux Enterprise Server, but Novell’s Linux “businesses” also include GNOME and Mono; it should be interesting to see what happens next.

Novell has been through some very rough times – first WordPerfect, then Netware, then UNIXware, and now SUSE. When SCO (not The SCO Group!) was split up, what was left was a shell of its former self; I hope that does not happen to Novell.

If VMware buys Novell’s Linux business, then SUSE would join Zimbra and SpringSource in the fold.

Let’s not forget, too, that VMware is owned by the storage company EMC. This could make itself felt in superior support for EMC products in SUSE Linux.

Personally, I feel better about SUSE being in the hands of VMware than I ever did thinking about Sun (and Solaris) in the hands of Oracle. I would also be surprised if some other company got SUSE instead; with the recent cooperation between the two companies VMware is the natural choice.

There was also the rumor that Attachmate would take on some of Novell’s other businesses. Attachmate has been good to the Reflection Suite for X that I like and recommend; perhaps Attachmate could be a good match as well.

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 (a blog by Eric Gray, a VMware employee); the other comes from Jase McCarty at Jase’s Place.

Novell and VMware Team Up

VMware announced in June that Novell’s SUSE Linux Enterprise Server (SLES) will be shipped with every copy of VMware’s vSphere product. In addition, VMware sales staff will have incentives to sell SLES. During the recent sales call by Novell, they expanded on the details of the enhanced partnership.

According to VMware’s page for SLES on VMware, it also sounds as if current vSphere customers would be eligible for a supported copy of SLES as well.

This is incredible news – it means that SUSE may be able to gain some traction in the data center. I’ve been partial to SUSE in some ways ever since I found that XFS (and JFS!) had been supported in SUSE Linux for years before Red Hat did – SUSE has always supported technologies first, providing more value than Red Hat did.

I also supported SUSE Linux in the data center in the past; it has been rock solid (as is Red Hat). SUSE Linux has a lot to offer – as does OpenSUSE (which just recently introduced 11.3).

Red Hat has always done well – as it should – but SUSE has been in the shadows for too long.

It has also been noted that VMware could be a company that buys SUSE and Novell’s Linux business. VMware was bought by EMC not that long ago. Cisco also has a joint venture with EMC that includes VMware products. Is it possible that Cisco will be shipping products with SLES on them?

Converting OpenBSD 4.1 guest from VMware to VirtualBox

This turned out to be easier than it would appear, although the vmware-tools needs to be extracted from the system.

The first thing that I did was to add the virtual hard drive created by VMware to the list of hard drives that VirtualBox makes available. This is in the Virtual Disk Manager from the main menu (Ctrl-D).

VirtualBox has native support for VMDK disks, the format that VMware uses. However, the documentation suggests there are restrictions, although the documentation may be obsolete: for one, it appears that snapshots are now possible, although the documentation suggests otherwise.

Having added the disk using the Virtual Disk Manager, I then created a new virtual environment and used the disk instead of creating a new disk from scratch. The disk was picked up and used seamlessly.

However, booting the environment (predictably) had problems: the VMware root disk was /dev/sd0a, but the VirtualBox root disk was /dev/wd0a. Thus, everything was fine until /etc/fstab was read, then OpenBSD presented the option to utilize a shell to fix the problem.

At the shell, it was necessary to mount the root filesystem read-write:

# mount -o rw /dev/wd0a /

Then editing /etc/fstab to use the correct disk was all it took.

However, VMware does not use an OpenBSD package to install the software, and apparently just drops it into the environment – and not in /usr/local either. All of the BSDs fiercely recommend placing every addition to the system in /usr/local – every add-on package does, from BIND to PHP to Apache to KDE to OpenOffice – everything. So for VMware to litter across the filesystem in this manner is very bad taste – and even without a package to extract it from the filesystem properly.

However, using locate, we can find the vmware-tools (or what looks like all of them):

# locate vmw

These files and directories can then be removed, although if the disk is to be used by VMware again you may not want to. However, using a virtual environment in two different products on a regular basis sounds like a recipe for disaster.