Virtualization Tip: Migrating to SAN’s “after the fact” with SCVMM using R2’s Migrate Storage

In today’s post, I thought I would share some insight into how to effectively migrate to Storage Area Network’s (SAN) after you’ve already got an SCVMM environment up and running.  You found yourself with several Windows Server 2008 Hyper-V hosts and you were moving along with very little issues; though, you recently have noticed that downtime is unavoidable if you don’t have your backend storage running on SANs.

You will get overwhelmed when researching the issue and I just thought I would share one person’s perspective who had no SAN, lot’s of physical servers running Hyper-V, and decided to learn second, execute first.  Typical for my personality type…

Existing Environment

Prior to migrating to a SAN, each server had local drives in a RAID 5 configuration.  The volume was dedicated for Virtual Machines and Scratch directories.  Migrations between hosts utilized network transfer and was using BITS and at minimal required that the VMs were in a saved state.  The average transfer time was around 10 minutes.


Preparing for the SAN

The SAN was installed (EMC Clarion AX4-5 with two shelves) and utilizes Fiber to connect to the hosts.  The EMC Clarion is a 3U unit and is connected to all our Hyper-V servers along with our SCVMM server.

After installation, you have to utilize the NaviSphere Express software to configure your Disk Pools and volumes.  This was obviously done prior to the connection to the servers.

For our environment, we have the following configuration:

VM Source Volume – This volume has our read-only source VHDs and is utilized by using Differencing disks to never alter the actual source.  The volume is small with 1 TB usable space in a RAID 5 (optimized for read-only).

VM Storage Volume – This volume is in a RAID 10 configuration and has all the differencing disk(s) for our virtual machines.  Since using RAID 10, this is optimized for Read\Write.  This volume is ~4 TB in size and currently supports about 30 virtual machines with 53% utilization.

VM Library – This volume is large, SATA drives (1 TB each), in a RAID 10 configuration.  This is the VMM library resources share.

Decisions to make prior migration to the SAN

Prior to migrating to the SAN’s, you will need to make some decisions that are very, very important.  Those decisions are the following -

  1. Do I utilizes Windows Server 2008 R2’s Clustered Shared Volumes (CSV) to take advantage of simplified management of LUNs?
  2. If answer to number 1 is No, then you need to determine your LUN strategy to work around the 1 VM to LUN limit

The decision I made, since I could, was to run all our VMs as Highly Available and utilize CSV so that I can reduce my time in managing the physical disks and volumes in NaviSphere.  As you can see above, I created one single LUN (~4 TB) that would house all of our virtual machines.  In a later post, I will work through everything I did to get clustering up and running and how I enabled CSV’s.  For the purposes of this exercise, though, lets assume that I have a single LUN that is presented to multiple hosts running in a cluster.

Migrating to the SAN

The first thing I was excited to see was System Center Virtual Machine Manager R2’s behavior after each of the servers were a part of a cluster.  Rather than having to break down SCVMM by removing the hosts, VMM quickly realized that the hosts were now “clustered.”  (I lost for a brief moment connectivity and the hosts were in a warning state during this period.

The VMs, though, were not running at the time on the “shared storage” hence each physical host was in the cluster though not utilizing the resources of the cluster.  Prior to the release of SCVMM R2, I would have been required to rebuild my VMs and place the VHDs on the SAN.  SCVMM’s Migrate Storage feature (outlined later), though, was the magic that turned this process into a very simple migration.  Let me explain what I did…

Verifying that the shared storage drives (or mounts) are ready…

This is the first step as the process is required because the physical host where the VM lives already is required to have access to the storage.  To verify this, connect to the physical host that is currently running the VM -

  1. Open Server Manager
  2. Click Disk Management
  3. Locate the volume for the shared storage, verify it is online and initialized


Migrating a Virtual Machine (One at a time)

Because of the sensitive nature, I started off by doing each migration one-by-one as I wasn’t sure of the “outcome” but as I became more comfortable I simply kicked off the process utilizing VMM’s PowerShell interface which made the migration move much quicker.  For now, I will step through the process using the VMM Administrator’s Console -

  1. Open the SCVMM Admin Console
  2. Locate the Virtual Machine you want to migrate to the SAN (currently running on the local physical host)
  3. Right-click on the VM, select Migrate Storage
  4. Utilizing the Migrate Storage Wizard, select the CSV volume (C:\ClusterStorage) on the physical host and complete the wizardimage

To validate the the Virtual Machines are actually utilizing the CSV storage, use the Failover Cluster Admin console and under Services and Applications you will see it listed.  The part I loved about this process is that VMM was intelligent enough to realize this was a clustered shared volume and during the migration *automagically* made the Virtual Machine(s) highly available.  This was verified in the SCVMM Admin Console by doing the following:

  1. After migration completes, highlight the virtual machine in SCVMM Admin Console
  2. Right-click the VM, select properties
  3. Click Hardware configuration tab
  4. Scroll to the bottom to the Availability section, validate it lists as “High”


That was it.  As I said, after a couple of these using the manual process it is rather easy to steal the PowerShell code and customize it and poof, your VMs are highly available.

Enjoy migrating!