I spend a lot of time doing storage migrations to new
storage arrays because the company I work for sells storage arrays. It’s
actually not too difficult, and sometimes you can even do it without downtime.
Here’s a list of some of the things to check before you
start VMware’s vSphere storage vMotions. I also address how to move VMware View desktops.
The basics
In order to use storage vMotion to migrate virtual machines
(VMs) to a new array, you need to zone your ESXi servers to both arrays. I’m not going to cover that in detail in this article,
but essentially you need to make sure the hosts can see datastores from both
the old and the new array. You also need to have at least an Enterprise vSphere license; any license lower than that doesn’t offer you the ability
to do storage vMotion while the VMs are powered on. If you have all of that and
no Raw Device Mappings (RDMs), you can go ahead and just storage vMotion your
VMs to the datastores on the new array.
Steps to storage vMotion:
- Bring up vCenter using the vSphere client or the
web client. - Right-click the VM you’re planning to move and
click Migrate. - Choose to migrate to a new datastore.
- Choose the datastore on the new array you’d like
to move it to. - Click OK or Finish and watch as the task
progresses.
It’s pretty simple, albeit somewhat tedious depending on how
many VMs you have and the size of the hard disks. The question I get asked at
least twice last week is: How do you migrate VMs with raw device mappings? These
are luns that are connected directly to the VM instead of going through Virtual Machine File System (VMFS). There are two types of RDMs: physical and
virtual. Read VMware KB article 2009226 to learn about the differences between the two RDMs.
For the purpose of this article, you just
need to know that you can’t storage vMotion a physical RDM, only a virtual. You can get around this, but it
requires a reboot of the VM. I
also recommend only doing one at a time, so you don’t confuse which RDM belongs
to which VM.
Steps to convert from a physical RDM to a virtual RDM:
- Right-click the VM and click Edit Settings.
- Click the hard disk labeled Raw Device Mapping.
- Record the SCSI device it’s using, because you
will need to re-add it to that device later. You might even want to take note
of the size of the hard disk, so you can be sure you’re re-adding the right one
back later. - Remove the hard disk and delete it entirely. This
will not remove data from the hard disk — it simply deletes the pointer. - Click OK.
- After that task is complete, go back into Edit
Settings and add a hard disk. - Add an RDM, but this time choose virtual
mode. - Make sure you’re adding the correct RDM to the
original SCSI device. - Power on the VM and ensure the disk shows up
within the operating system.
After you convert it to a virtual RDM, you can storage
vMotion the VM. If you don’t change anything, it will simply remove the pointer
from the original datastore and move it to the new one. However, sometimes you
don’t want to have to deal with RDMs anymore. If the application you’re running
on that VM supports it, you can storage vMotion the RDM to a Virtual Machine
Disk format (VMDK) on one of the new datastores with no downtime. When doing a
storage vMotion, you need to follow the steps above, but instead of leaving the
format to be “same as the original,” you need to change it to either
thin or thick provisioned. After
you do that and choose a new datastore, it will convert your hard drive to a
VMDK file from an RDM.
The last caveat I’ve run into is when the environment has
VMware View (Horizon View) desktops. You should never storage vMotion linked
clone desktops. There is a rebalance feature in the View Administrator that can
be used to move the desktops to the new datastores. For more information, read
the VMware View documentation and VMware KB article 1028754.
Steps to follow to move virtual desktops:
- Ensure your end users are logged out of their
desktops. During the rebalance, you will get the option to either force them
off or have it wait to move the VM until after they choose to log off. It’s up to you how you do this, but I
recommend just getting it done so you don’t remove the old array and lose that
desktop. - Make sure your users have saved all their data
to persistent disks if necessary. - Log in to View Administrator (View Connection
Server). - Click the pool(s) you want to migrate.
- In the pool, click vCenter settings and change
the datastores to the datastores on the new array (make sure to remove the
checks next to the datastores on the old array). This will not affect the
current desktops that have been provisioned. - When you’re ready, go back into the pool and
under the View Composer drop-down box select Rebalance. - In the Rebalance wizard, choose to force users
to log off (if you like) and fill out the other options if you like. You can
leave the defaults, though. - You’ll see the desktops go into Maintenance Mode,
and then they will migrate to the new datastores. If you have them set up to
power on automatically in the pool settings, you’ll see them become available
again after they’ve finished migrating. If they only say provisioned, they are
not set up to power on automatically. You either need to change that or power
them on manually.
If you have any questions, comments, or other helpful hints
about this process, please feel free to leave them in the comments section.
Also read: Virtualizing the Enterprise, a Special Feature from TechRepublic and ZDNet