I just put up a way too long post on the "Windows Server Expert’s” site on how to go cheap with virtualization (post is here).
Lots of good stuff in the post about Hyper-V Server and mention of James' O’Neill’s James’ 'PowerShell Hyper-V Management library for Hyper-V.
Does anybody else think those pictures on the site are kind of scary? Here’s mine.
I was thinking of changing it a little …and had a great suggestion…but I’m far from an artist.
Should I add a hat?
I had this whole post all ready to go, then my lab took a power hit (poof!). At least I know what to write again! Anyhow, I received a great comment on the other “Windows Server Expert” blog about CSV and Live Migration. I had mentioned in a post about the value of Hyper-V backup that CSV is not required for Live Migration. One of the readers (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. The guidance I’ve seen isn’t wrong, it’s just incomplete. Mike Sterling and I are addressing some of this in our upcoming R2 update to our Hyper-V book. I’ll make it really clear:
What you do need if you ware 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!
If CSVs make using Live Migration easier, why not use them all the time? In my last post I mentioned the challenge with host-based backup of VMs using CSVs. You can use CSVs or dedicated LUNs for your clustered virtual machines, you just have to be aware of the trade offs.
-John
Happy New Year!
I’ve received several questions and comment about backing up VMs that reside on CSV volumes. In short, you can do it, but it’s tricky.
There’s a great post on the DPM Insider blog about the challenges (Here). Host-based backup of CSV-base VMs works with DPM 2010 and other tools. The trick is to tie the CSV volume to the physical cluster node where a VM is executing for the duration of a VSS snapshot and backup. As noted in Asim’s post, using a hardware provider makes the most sense (saves time!). I’ve already heard moans about the suggestion of using a hardware VSS provider.
What strikes me about all the questions is how greedy we’ve gotten with our expectations around the benefits of virtualization! If you’re using CSV (and Live Migration or even VMotion for that matter) you have already invested in shared storage. What’s the big deal with using a hardware provider? Yes it may be more expense, but if you are serious about host-base backup of highly available VMs you need to do it. Yes, I’m being a hypocrite here – my primary storage subsystem does not support hardware integrated snapshots! I know they aren’t always an option. You can still use software snapshots (with System Center DPM 2010), just be aware that it will take longer to complete, and that IO will be pinned to the cluster node being backed up for the duration of the backup. Remember that you don’t need CSV for Live Migration, it just makes storage provisioning easier. You can setup each VM on an individual LUN and not have a CSV backup challenge…it’s a trade off.
Don’t forget that you can still backup using a process or agent IN the VM! It may be somewhat old school, but nothing should stop you from deploying an agent inside your critical VMs and executing a backup. Depending on your application workload, this may be the best solution REGUARDLESS of your use of CSV / Live Migration.
What if, for example your VM is running a workload that just doesn’t work right with VSS? The backup coordination from the host (via the “Backup” Integration Services) is meaningless and must be disabled. If it is disabled, then the VM would be “saved” during a host-based backup – interrupting processing. The best alternative in a situation like this would be to use an application aware backup agent inside the VM.