I received a great question about something I said in my post on the great value of Hyper-V backup - that CSV is not required for Live Migration. One reader (thanks Dan), called me on this, because all of the documentation he had seen spoke of them together - including this article: “Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2” .
Most of the documentation that I’ve seen covers CSV and Live Migration together because they both required increased network bandwidth between cluster nodes (and are new to R2). The guidance I’ve seen isn’t wrong, it’s just not clear. Mike Sterling and I are addressing some of this in the upcoming R2 update to our Hyper-V book. I posted this information already on my other blog, but wanted to “ping back” here as well.
What you do need if you are not using CSVs is to dedicated each VM to a separate LUN or cluster file system (like Sanbolic’s Melio FS). For Live Migration to work, the VM must be able to move to a new node without being associated to another virtual machine (as it would be if more than one VM were hosted on a LUN with out CSV or a CFS). For demonstration purposes, I setup a small LUN in my lab and but a single VM on it. It’s show as Drive W: in the picture top the right (there are a few other LUNs as well, including a 512GB LUN used for CSV).
I created a Windows Server 2008 R2 Enterprise Edition VM on one of the cluster nodes on the new dedicated LUN as show in the Hyper-V Manager VM “Settings” screen to the Left. I then make the VM “highly available by adding the LUN to the cluster and running through the “High Availability Wizard”. Once the VM was started and running on the cluster, I was all set – as you can se e in the Failover Clustering console image on the right.
OK, so now what. Demonstrating that you don’t need CSV is as simple as right clicking on the VM in “Services and applications and seeing what options you have… like… like LIVE MIGRATION!
Pretty cool, right? So if you can use Live Migration without a CSV, why would you bother with setting up CSVs? Because using CSVs reduces the hassles associated with storage provisioning. You don’t have to setup a separate LUN for each VM if you put all your VMs on a big CSV (or multiple CSVs). CSVs also reduce the potential disconnect period at the end of the migration, since the CSV doesn’t have to be unmounted from one host and remounted on another. THIS IS A BIG DEAL if you have a less than optimal networking setup (like in my lab). I only have two NICs on each of the hosts in this cluster – on for VMs and the other for cluster / iSCSI (a real no no! – Not enough bandwidth!). On this cluster, the time out to mount / unmount a VM on a dedicated LUN is just a bit too long, and my non-CSV Live Migrations often fail as a result! I just got a new, enterprise-class HP ProCurve switch for my lab that supports 10GB (as well as link aggregation) which will certainly improve my situation.
If CSVs make using Live Migration easier, why not use them all the time? In a post on my other blog, I mentioned the challenges with host-based backup of VMs using CSVs (DPM 2010 does a great job with this, by the way!).
You can use CSVs or dedicated LUNs for your clustered virtual machines, you just have to be aware of the trade offs.
Do you have some comparison between time LM with and without CSV?
Unfortunately I don't have any useful timing comparisons. There are a number of variable factors that can impact migration time including storage topology, storage sub-system load, even domain authentication (local versus remote DC). Any numbers I have would vary from test results in another environment.
Does this alleviate the chicken/egg scenario with CSV?
For example, if you have your Active Directory machine on CSV storage and you have 3 nodes and you take two of them offline the cluster is down. Thus the CSV is down and you cannot run/start any machines on the CSV storage.
With this, is it possible to take 2 of them down and still have access to the storage?
I know it is best practice to have a physical AD. I have been getting around this problem right now, by storing one AD machine on local storage, but this solution would allow that AD VM to move around if the storage stays up when the cluster is down.