Manage Learn to apply best practices and optimize your operations.

ESX-to-ESXi migration: Making the case for your customers

Now that VMware is phasing ESX out, an ESX-to-ESXi migration can benefit both you and your customers. Find out how to convince them that ESXi migration is a worthwhile process.

When VMware announced the vSphere 4.1 release in August, it included news that the next major vSphere release (5.0)...

will include only ESXi and ESX will no longer be a part of the product. ESX’s end of life means that solution providers should plan on migrating their customers to ESXi sooner rather than later.

If customers wait until vSphere 5.0 is released, they will be dealing with an architecture and version change at the same time, which can make the transition much more complicated. But the most challenging part of the migration might be dealing with the mental roadblocks that customers have about making move from ESX to ESXi. It may take some convincing to overcome these obstacles, but it is ultimately in their best interest.

ESXi has steadily improved over the years and is now mostly equal with ESX when it comes to features and management. But many customers still use ESX over ESXi because they are more comfortable with it.  Another reason is that the transition to ESXi can be time-consuming because the management of ESXi is a bit different then ESX.

The first thing solution providers need to tackle is the feature disparity between ESX and ESXi. For a long time ESXi was missing some key features such as boot from storage area network, scriptable installs and Active Directory integration. With the release of vSphere 4.1VMware made ESXi features on par with ESX.

Another issue with customers is that both ESX and ESXi are equipped with management consoles that are different from each other, which affects management techniques. ESX has a full Linux operating system running in its service console, which gives customers more options and flexibility for configuration and troubleshooting tasks. On the other hand, ESXi has a limited POSIX-based operating system that has a smaller subset of commands compared to ESX.

Additionally, the ESXi management console was hidden and not officially supported by VMware. That has changed with vSphere 4.1. The ESXi management console is now more accessible and VMware fully supports it.  Although it’s not as powerful as the ESX Service Console, the ESXi management console still functions well enough for most customers’ purposes. The vSphere command-line interface (CLI) and the VMware Management Assistant (vMA) also provide a decent alternative to the ESX Service Console. VMware has improved both features in vSphere 4.1 to allow for better management of ESXi hosts.

Keys to ESXi upgrade: Patching and deployment
There are also some clear advantages to using ESXi that can make the migration from ESX more compelling. Perhaps the biggest benefit is the way ESXi is packaged and deployed. Each new version of ESXi is delivered as a single image file that completely replaces the previous version. The result of this is patching becomes much simpler with ESXi because your customers no longer have to worry about patch dependencies and installing patches in a specific order.

Patching becomes much simpler with ESXi, and the management console code in ESXi is much smaller than ESX’s full Red Hat Service Console. Rolling back to a prior version in ESXi is also a breeze because the previous version is automatically saved in a backup partition, so it can easily be reverted to if needed.

Another reason to migrate to ESXi is that it has a small disk footprint. That means it can be installed on USB flash drives used to boot from and run ESXi. As a result, ESXi hosts can be deployed quickly.It also eliminates the need for local hard disks in your customer’s hosts, which can help reduce their purchasing cost.

The ESXi installation process is also much simpler than ESX, which reduces deployment times for new hosts. ESXi also boots much quicker than ESX, which helps your customer’s hosts to get back in action faster in the event that a host fails or needs to be restarted.

Have your ESXi migration plan ready
Once you have customer buy-in to migrate their hosts from ESX to ESXi, make sure you take time to develop a plan before starting the migration. Your first task is to educate your customers on the differences between ESX and ESXi, especially about host management methods. Familiarize them with the vSphere CLI, vMA, Tech Support Mode and the Direct Console User Interface.

Next, audit each ESX host before  migration to see if there are any agents or scripts that rely on the ESX Service Console, especially the backup applications or hardware monitoring utilities. Because ESXi has a smaller management console, you can’t run these agents or scripts within it, so alternative solutions are required. Check with vendors to make sure they have products that support ESXi. If your customers are running older versions of software, you may need to upgrade them to newer ones.

VMware has been pushing everyone toward using application programming interfaces and software development kits, and most vendors have updated their software accordingly. For hardware agents, most of these are slipstreamed into ESXi through server customizations in the oem.tgz file that is located on ESXi’s main disk partition. The typical way to get this is to download ESXi from the server manufacturer’s website because the installable ESXi on VMware’s website only contains standard Common Information Model providers. If you use Perl scripts running inside the Service Console, consider using PowerShell or leveraging the vSphere CLI or vMA instead.

If your customers are using scripted installations to automate ESX host deployment, the method for ESXi is similar and involves using Preboot eXecution Environment booting from a network interface card (NIC). Just load the install image from a repository and run a kickstart script to customize the installation. You can use host profiles to customize host configurations, but they may be somewhat limited and less robust than scripting. Use scripted installs in conjunction with host profiles for best results.

Performing the upgrade
Once you are ready to upgrade your customer’s existing ESX hosts to ESXi, you need to plan how you will perform the upgrade. Unfortunately there isn’t an easy upgrade path from ESX to ESXi because you need to install ESXi fresh over your existing ESX installation. This means that any local disk partitions and virtual machine file system (VMFS) volumes will be overwritten during the ESXi installation.

If your customers have virtual machines on local VMFS volumes, your  first step will be to migrate them to other hosts or storage devices using cold migration or Storage vMotion. Once the host is upgraded, you can then move them back.

After completing the pre-upgrade steps, the actual upgrade from ESX to ESXi is fairly straightforward. Boot from the ESXi install media, answer the few prompts, and reboot when it is finished. But remember that this also wipes out all of the host specific settings that will need to be reconfigured after ESXi is installed.

Unfortunately there is no way to back up the settings on the old ESX host and restore them on the new ESXi host, so you need to document the settings-- such as vSwitch configurations, security, DNS/time, advanced settings and power management--so they can be reconfigured afterward.  If you’re upgrading a small number of hosts with simple configurations, this won’t be too difficult. But if your customer has many hosts with complex configuration settings, this can be difficult and time consuming.

Help automate the process
There are a few things you can do to help automate and ease this process. First, consider using host profiles if your customer has Enterprise Plus licenses. Many of the settings can be defined within the host profile, and you can simply apply it to the newly built ESXi host to update its configuration.

Distributed vSwitches are another Enterprise Plus feature that use centrally managed vSwitches in vCenter Server, which can be attached to any host. Once a new ESXi host is built, just assign its physical NICs to the existing dvSwitch port group configurations, and it’s all set. You can also develop scripts using kickStart or PowerShell that can help run and automatically configure hosts a specific way. Finally you can use third party tools or scripts that can document a host’s configuration to use as a reference that will help you reconfigure a host afterward.

Focus on the advantages that ESXi provides compared to ESX and help your customers adjust to the management changes to make the transition as easy as possible. Once your customers gain experience using ESXi, they should become comfortable with it and never look back at ESX.

About the expert
Eric Siebert is a 25-year IT veteran whose primary focus is VMware virtualization and Windows server administration. He is one of the 300 vExperts named by VMware Inc. for 2009. He is the author of the book
VI3 Implementation and Administration and a frequent TechTarget contributor. In addition, he maintains vSphere-land.com, a VMware information site.

This was last published in April 2011

Dig Deeper on Virtualization Technology and Services

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

MicroscopeUK

SearchCloudProvider

SearchSecurity

SearchStorage

SearchNetworking

SearchCloudComputing

SearchDataManagement

SearchBusinessAnalytics

Close