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…
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.
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.
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.
Prior to migrating to the SAN’s, you will need to make some decisions that are very, very important. Those decisions are the following -
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.
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…
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 -
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 -
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:
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.
Hi Chris, I enjoyed your writing and started me wondering if your very large CSV would also be considered good practice in a production environment? Currently I have limited the number of VM's to about 10 per CSV to not overstress the disksubsystem. This is to keep the average disk queue length low enough. I am interested in your findings with 30 VM's on one CSV.
I am testing HV and VMM and have setup the CSV. I went to migrate the storage of an exisitng VM from local disk to the CSV and received an error and I cannot find any information for this error.
VMM is unable to complete the requested file transfer. The connection to the HTTP server HVTST01.lazydays.local could not be established.
(Unknown error (0x80072ee2))
Ensure that the HTTP service and/or the agent on the machine HVTST01.lazydays.local are installed and running and that a firewall is not blocking HTTPS traffic.