It's 3:11 AM here and I just got my first Vmware demo environment with vSphere 4 (i.e. ESX 4.0) configured to show vMotion. Having set up both Live Migration and now the aforementioned vMotion, I can tell you that I much prefer the setup under Hyper-V. Just getting vSphere installed (pretty simple using its GUI Setup) and configured (not straightforward ... maybe it's my unfamiliarity with the server-based Vmware products, but it is not intuitive like Vmware Workstation is) took me the better part of today to figure out all of the little nuances. OK, sure, I could have probably read some docs (which I wound up referencing), but setting up clustering and then Live Migration is just easier.

I also didn't like the fact that vCenter needs a 32-bit ODBC connection to work (it uses a SQL Server backend), and it does not install the latest SQL Express version (if you choose not to use an existing instance with an appropriate DSN). That means those of you on later versions of Windows (read: Windows Server 2008 R2) will have to patch immediately. I wound up configuring vCenter Server under a Windows Server 2003 R2 VM.

As for the actual features - vMotion and Live Migration - they do essentially the same thing (migrate a virtual machine from one hypervisor host to another while keeping it up and running). They both work well.

The one major advantage of vSphere + vMotion at the moment is that I can demo it live on my laptop; my Live Migration stuff has been captured from a setup I did about a month ago when I had access to hardware. If you're wondering why, it's because the VT-x extensions that enable things like virtualization are not emulated in VMs (and if you think about it - it makes sense; virtualize a virtualized environment isn't a normal use of the technology). Both Microsoft and Vmware do not emulate VT-x. To do vSphere, it seems like Vmware does something special under the covers. I hope MS does something similar because I'd love to demo Live Migration "in the flesh".

Having said all of that, it'll be interesting to see how I get along with vSphere now that I have it set up. Since many customers of mine are invested in vSphere/ESX for their virtual environments, it's clearly in my best interests to have a good working knowledge of setting it up. I know DBAs probably won't be doing most of what I do, but this work I'm doing right now helps in conversations with the other groups (especially the guys setting up the VMs). I'm not new to Vmware - I've been using Workstation for nearly 10 years with a lot of success, and I used Vmware Workstation 7 to set up this new vSphere 4/vMotion environment.

I have yet to play with any of the other virtualization products since quite honestly, my customers really only talk about Vmware or Microsoft. The others don't come up in conversation. If you're using one of the other ones, I'm not denegrating your choice - do not take it that way. It's just that I'm not seeing it out there, much like the most common storage vendor I see at customers is EMC. There is other stuff, too - IBM, some HP, a Hitachi here and there - but EMC seems to be ubiquitous. All I care about is ensuring you have the right configuration no matter what hardware/software choices you make.

OK, off to get a few hours of shuteye and back to the grind in the AM to finish up some stuff before I head to Tokyo!

I've been talking about it for awhile, but it's finally here - my update of the old SQL Server 2000 consolidation whitepaper. It just went live less than an hour ago.

The basic info including the link to the download of the Word document can be found here:
http://msdn.microsoft.com/en-us/library/ee692366.aspx

or you can just download the Word doc from http://download.microsoft.com/download/D/B/D/DBDE7972-1EB9-470A-BA18-58849DB3EB3B/SQLServer2008Consolidation.docx.

I hope you find it useful!

The answer: 4.
1. Failover Cluster Manager
2. Move-ClusterVirtualMachineRole PowerShell cmdlet (part of the failover clustering cmdlets)
3. System Center Virtual Machine Manager 2008 R2
4. Move-VM PowerShell cmdlet (part of the SCVMM 2008 R2 cmdlets)

At the end of the day, how you perform a Live Migration is going to depend on how you like to work - GUI or command line, and then it's down to preference under those. Not everyone will deploy SCVMM, so what you get natively with Windows Server 2008 R2 in Failover Cluster Manager and its PowerShell cmdlets.  

It's been a busy month between client work, travel, playing bi-weekly with a big band, and the holidays ... as well as getting ready to go into the studio to start my first new album in 10 years in a week! First, the updates:

• Thanks to the folks at SQL Saturday in Redmond - I had a lot of fun and the audience was great. Even though I was the last session of the day, people still stuck around.
• The consolidation paper is finally in edit, and we're on track to have it out for PASS assuming no road bumps.
• It looks like I'll be speaking in Singapore in December ... more info as it gets solidified.
• Hard to believe PASS is less than a month away! Hope to see some of you in my session.
• I'll get back to the promised post on DTC very soon.

• Ben DeBow and I will be doing a 6 part series on consolidation for Penton media early next year (similar to the six I did earlier this year for SQL DBAs). Again, stay tuned for more details. It will be a lot of fun to work with Ben on this, as he also has some really great experience with some large customers who have done consolidation. Maybe if we're crazy enough we'll attempt to write a book, but don't hold your breath :)

Now for some technical content ...

Hyper-V, Virtualization, and Live Migration
I've been playing around a lot lately with Hyper-V, and I have to say I'm impressed. I'm well documented as a VMware Workstation guy, but I've had some issues with it and Windows Server 2008 R2. On a lark, I decided to dual boot my laptop with Windows Server 2008 and Windows 7 (I'm still at RC; haven't had time to upgrade to RTM and with all of my speaking coming up, I'm leaving my configuration alone!). Interestingly enough, I find that W2K8 R2 consumes a bit less in the way of resources than Windows 7. But I digress.

I set up what I usually do in VMware - a demo cluster - and it was a breeze. The Hyper-V Manager tool is very straightforward. I like the editing of VMs a bit better in VMware's tools, and the only real negative I have with Hyper-V at the moment is that you can't (or maybe I'm missing something) drag and drop from your hard drive into the VM. One nice improvement over VMware is that I can cleanly shut down a Windows guest from the management tool. So I'd say both at this point are equally as good for my purposes, and for production, I would say MS has really caught up in the virtualization race. It'll be interesting to see what happens in the next few years with the various hypervisors and where they take things.

One of the best features of W2K8 R2 and Hyper-V is Live Migration. Live Migration is the ability to take a virtual machine (which is running on a Windows failover cluster) and move it with no downtime to another node in a way that minimally impacts performance. SQL Server fully supports Live Migration. Unfortunately, what I can't do on my laptop is demo Live Migration, and it's a killer feature (and for SQL Server). The reason? You can't enable virtualization in a VM (either Hyper-V or VMware). It just isn't practical to schlep extra hardware and disks around everywhere, and I can't count on having an Internet connection everywhere (nor can I necessarily rely on being able to get to my home machines if I have it configured). As someone who talks about clustering a lot, it puts me in a difficult spot. So right now I'm doing some work in a location where someone has graciously allowed me to configure this setup using a real SAN, and I'm documenting the heck out of it (including caveats) for Live Migration and SQL Server. Whether that winds up being a whitepaper for MS, or something I do on my own, it'll get out there. It'll be a nice companion to the paper MS already has on SQL Server and Hyper-V.

iSCSI
iSCSI is becoming more prevalent both in my use of it for demos and at client sites. However, realize that there are a few "gotchas" that you really do need to take into account. I will still maintain that using more traditional disk architectures for a production SQL Server implementation that is mission critical is arguably better in many cases, but that really isn't my decision in the end. Just be aware of what iSCSI means for SQL Server. I've seen iSCSI work really well for SQL Server deployments, too, but it all boils down to planning.

1. Remember that with iSCSI, chances are you're probably using a NIC, not a dedicated iSCSI HBA (which would be better). On a cluster, you must use a dedicated NIC in addition to the Public and Private NICs; iSCSI traffic can't share either.

2. You are now dependent on your network for your I/O. Remember that SQL Server needs guaranteed writes. What happens if your network dies? Make sure your network infrastructure is robust and architected properly. This means things like dedicated networks for iSCSI so the traffic isn't going out with the rest of the network traffic, redundant switches and such, etc.

3. Using NICs means some processor overhead. Account for that in your server sizing.

4. Test, test, and test some more. Make sure you not only run tests to see what the I/O capacity is from a hardware perspective is, and then run your workload. Know where the system will be stressed out. You may even want to try some more basic tests (like a file copy - I've seen that choke some iSCSI systems) before you attempt to test your workloads. This rule also applies to standard SANs, but is even more important with iSCSI.