posted

0 Comments

In my last post I mentioned the requirement to upgrade vCenter in preparation for migrating  to ESXi.  In this post I will discuss the storage considerations related to an ESXi migration.

Before you shutdown an ESX hosts in preparation to migrate it to ESXi you need to evacuate the VMs off the host.  The steps to do this vary depending on where the VMs are stored and what their availability requirements are.  There are three places where VMs can be stored:  (1) on the boot disk, (2) on local disks, or (3) on shared storage.  Let’s discuss the considerations for each.

VMs on Boot Disk Datastores
Every ESX host has at least one VMFS partitions on its boot disk.  Before you migrate a host to ESXi it is important to identify any VMs or templates stored on this datastore.  The ESXi install will re-partition the boot disk and in the process any VMs or templates not relocated will be lost.  As such prior to shutting the host down you need to either move these VMs and templates to another datastore (preferably a shared datastore) or back them up so they can be restored after the migration.   As backup and restore is pretty self explanatory I’m only going to cover the steps to relocate the files to a new datastore.  There are a couple different ways to do this:

Moving Active VMs off the boot disk datastore(s)
If you want to avoid VM downtime the best way to move VMs off the boot disk is by using Storage vMotion.  Storage vMotion allows you to migrate the VM’s disk files to a different datastore while the VM is running.  Assuming you move the files to a shared datastore you can then use vMotion to migrate the running VM to another host and keep it running during the ESXi migration.   Note that both vMotion and Storage vMotion are licensed vCenter features.  Fortunately, if your vSphere license doesn’t include these features you can use the 60-day trial license provided with vCenter 4.1.

Moving inactive VMs off the boot disk datastore(s)
If it’s okay to power off the VM another option is to do a cold migration.  With a cold migration you first shut the VM down and then copy its disk files to a different datastore.  Once the files have been copied, and again assuming you copied them to a shared datastore, you can then register the VM on a separate host and power it on.   There is no special licensing required to perform a cold VM migration.

A note about templates
Templates are VM that have been converted into a template in order to facilitate deploying new VMs.  To move templates you first need to convert the template back to a regular VM, then migrate the files (using either Storage vMotion or Cold Migration), and then convert it back to a template. 

Migration-options

Figure 1 – VM Migration Options

VMs on Local Disk Datastores
Unlike with VMs on the boot disk you have a choice on whether or not to move VMs and templates off any local datastores.   During the ESXi installation local disks with existing datastores are ignored and will not be reformatted.  However, you do need to consider the impact the host downtime will have on your VMs as the VMs and templates on local datastores will not be accessible while the host is being migrated.  If you want to keep the VMs running or ensure templates remain accessible while you migrate the host, you will need to move them off the host’s local datastores.  Again, you can use a combination of Storage vMotion and vMotion to do this, or if downtime is not an issue use cold migration.  

One important thing to be aware of if you choose to leave VMs on local datastores is that you will need to manually re-register them following the ESXi migration.  When ESXi is installed the host level registrations for the local VMs will be lost and the VMs will appear in vCenter as “ghosted”.  To clean this up you will need to remove the ghosted entries from inside vCenter and manually re-register each VM by browsing into the VM’s directory on the local datastore and right clicking on the VMX file to add it back to the host’s inventory.

VMs on Shared Storage Datastores
VMs on shared datastores are the easiest to manage because they don’t require any special handling.  The only consideration necessary in the case of VMs on shared datastores is if the VM is active on the host to be migrated you will need to shut it down or vMotion it to another host.
 
Summary
During the ESXi migration, when you install ESXi, the boot disk will be re-formatted to include destroying any VMs and templates on it.  As such it’s important that prior to migrating to ESXi you move the VMs and templates off the boot disk, preferably to a shared datastore.  Evacuating the VMs and templates can be done with no VM downtime using a combination of Storage vMotion and vMotion.  If downtime is not a concern you can also use cold migration. 

In addition to evacuating VMs and templates off the boot disk, you also need to give consideration to VMs and templates stored on local datastores.  The ESXi migration requires shutting the host down, which will require powering off any VMs running on local datastores.  While the host is powered down the VMs and templates will not be accessible until after the ESXi migration is complete.  To ensure VMs and templates  remain running and accessible during the ESXi migration it is recommended that they also be migrated to a shared datastore. 

VMs on shared storage are already readily accessible by multiple hosts and therefore don’t require any special consideration.  VMs on shared storage can simply be vMotioned to another host and remain running and accessible during the ESXi migration.

About the Author

Kyle Gleed

Kyle Gleed is a Group Manager within VMware’s Integrated Systems Business Unit (ISBU) where he leads a team focused on the adoption and deployment of the solutions and capabilities of the Software-Defined Data Center. Follow Kyle on twitter @Kyle_Gleed